个人博客作业
快速阅读《构建之法》后提出的问题
1.单元测试是否必须要快？
-
第二章开始时提到了一个好的单元测试的标准。作者认为，单元测试应该准确、快速地保证程序基本模块的正确性，我对这一点表示肯定。但接下来的一个描述让我有些疑惑，具体如下
单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）
快，才能保持效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。
我认为不是任何软件的单元测试都符合“快，才能保持效率”的。比如我们在大二学习OO时写的多线程电梯，由于有各种时间上的规定，人坐电梯不可能太快；涉及机器学习的测试，面对极其庞大的数据量，测试速度也不可能有多快。但是，不能因此而说这样的单元测试就没有效率，不是一个好的测试。亦或许是作者此处说的“单元测试”与平时理解的“测试”有所差异？
2.goto是否符合代码设计规范？
-
在4.3.2节中，作者提出
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
而著名的计算机科学家Dijkstra在他的论文《Go To Statement Considered Harmful》（Go to有害论）中的原文如下
More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages.
他提出，goto语句有着“灾难性”的影响，应当从“高级”编程语言中取消。现代则普遍认为goto语句会降低代码的可读性，破坏程序的“结构化”，带来编程的混乱，并且容易出错。我认为这句话一定有它存在的作用，我们应该尽量避免使用goto，取而代之用if-else语句实现，增强代码的可读性。
3.关于4.5节结对编程
-
在这一节，作者认为
在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。
在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一堆程序员中各方面水平较高的那一位。
同时指出了三点结对编程的好处。我认为这只是对结对编程的一种积极的构想，并不全面。假设这对程序员一开始可以平等互补地工作，但某一天两人突然产生了一种不可见的矛盾，比如程序员A认为他在开发过程中贡献比B大，变得骄傲自大，B又不服A······这样的结对编程就会适得其反，没有真正实现结对的目的，这样的情况应该不在少数。
4.如何发现用户背后的动机？
-
在10.1节中，作者以网络漫画为例，并指出
光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机！不能光根据用户的语言就匆忙做决定。
言外之意就是我们要推测出用户的更深层次的需求。但现实是，许多用户就如漫画里面一样，有时候就希望开发者可以照猫画虎，对于自己需求的形容也往往不够专业，不能完全让开发者理解。就像前段时间网上流传的一个事例，某酷似甲方的人员打电话说道：“你先这样，然后再这样，接着再这样，最后再这样，很简单吧？”也就是说，一些用户很难沟通，我们很难找到他们背后的动机，就连他本身想干什么都搞不清。这种情况，我们是否应该直接按照用户的表面语言或行动进行开发，或是有什么发现其背后动机的更好办法？
5.技术创新是否是关键？
- 在16.1.6节中，作者认为“技术的创新是关键”是一种迷思，并举了商业模式的创新，用户体验的创新，生态系统的创新的例子。我认为这样的推理并不是很完备，只能说明除过技术创新，还有很多其他创新的方式，可以印证“创新不只存在于技术”。说到创新的关键，我依然认为是技术。
“软件”和“软件工程”这些词汇是如何出现的——何时、何地、何人？
- 软件（Software）——1958年由贝尔实验室的著名统计学家John Tukey 提出，发表在论文《The teaching of concrete mathematics》
- 软件工程（Software Engineering）——由Margaret Hamilton在阿波罗11号设计的过程中提出的
软件工程发展的过程中有趣的冷知识和故事
-
电脑病毒的设计初衷并非是造成损害。
史上第一款电脑病毒，是由防御技术专家Fred Cohen亲手设计出来的。他创造电脑病毒的目的仅仅是为了证明程序对电脑感染的可行性，从未希望借此对电脑造成任何危害。但这款程序却能够对电脑进行感染，并且能通过软盘等移动介质在不同计算机之间进行传播，因而命名为病毒。后来，他又创造出一种主动式电脑病毒，主要目的是帮助电脑用户找到未受感染可执行文件。
目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
Microsoft TFS
优点：
- 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
- 能有效实现 SCRUM能与 VS 无缝接合。
缺点：
- 搭建、维护tfs比较复杂，硬件要求也比较高。
- 整个系统是用 asp 实现的，用浏览器访问相当慢。
Git
优点：
- 适合分布式开发，强调个体。
- 公共服务器压力和数据量都不会太大。
- 速度快、灵活。
- 任意两个开发者之间可以很容易的解决冲突。
- 离线工作。
缺点：
- 学习成本高，学起来很有难度。
- Git版本库需要频繁的手动维护。
Trac
优点：
- 非常灵活，可以随心所欲控制可以和SVN集成。
缺点：
- 功能不是很强大。
Bugzilla
优点：
- 免费，有中文版支持。
缺点：
- 快速搜索结果不准确。只能管理缺陷。
Apple XCode
优点：
- 编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：
- 更新版本后，某个插件可能会失效。
Mercurial（Hg）
优点：
- 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。
- 可以一键完全恢复到历史版本的某一个切面。
- 封装好。相比git，hg很少暴露一些实现内的细节。
- 照顾svn的迁移用户。
- hg的pull更多的时候可以让你避免创建分支。
- hg的版本库不需要维护。
缺点：
- 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。
版本管理软件实践
Git
上图是一个简单的git仓库初始化，添加一个.md文件并提交，可以看出这个版本的id为100644
git初学时有些困难，因为需要手动输入许多命令，并且这些命令不太容易记住，使用git进行基础操作的上手所需时间不是太长。但如果想用git实现更多功能，就要记住更多的命令，学起来确实有困难。
git的功能非常强大，与github或gitlab配合使用时效果更佳，对于项目管理十分高效。唯一令我感到困扰的是，有时不小心有一步操作错误，就会带来非常多的麻烦，比如不能push或pull，提交错分支······
Mercurial(Hg)
第一次使用，上图确认了hg安装成功，下面进行尝试
根据上面的基本命令提示，发现好像和git很相似
执行init后也会出现一个.hg文件，之后进行添加，提交操作，感觉和git差异不是很大。但是，这仅局限于基础操作。上网搜索了一下，hg的功能比git少太多，具体可参考 git和hg相互比较，各自的优缺点都是什么？