人月神话读书笔记（二）

人月神话读书笔记（二）

不妨用书中引用的一句话开个头：

我能召唤遥远的精灵。
那又怎么样，我也可以，谁都可以，问题是你真的召唤的时候，它们会来吗?
​ ——莎士比亚

整体部分这章讲的是如何得到整体的可运行高质量软件。高质量的小程序很容易实现，因为小程序的逻辑没有那么庞杂，工程量也不大，人们很容易就能把事情考虑得较为周到。但一旦到了整体的大的程序，问题就回凸显出来。书中介绍了以下三种方法。虽然我觉得讲得很有道理，但也清楚地知道我自己的团队项目做不到这样。

消除bug的设计

之所以谈消除Bug的设计，就让我们更加意识到质量是设计出来的，而不是测试出来的。书中提到的许许多多的失败都是因为未竟的设计，因为产品中有未精确定义的地方。这要求我们在需求和设计阶段要保持高质量，减少缺陷泄漏。对于需求要有详细的需求规格说明书，对于设计我们提倡的是从顶向下逐步求精的设计，而这里面最重要的就是结构化的设计方法和思路，不论是面向结构和面向对象其实都要遵守结构化的设计方法。在需求规格说明书完成后要尽快提交给测试小组编写测试用例，测试小组需要Review需求以确认需求完整，无歧义和可测试。

其实很想吐槽这次的结对作业。UI组和Core组结合起来其实相当于一个小项目了。但由于API没有设计好，对于核心的要求也没有定义好，导致了很多麻烦的事情：

• 比如Core设计中很多要求原始文档里并没有说明，大家根据自己的理解实现得差不多时突然规定了某些细节，导致很多代码不得不删改甚至重来。而同学们的代码往往工程性并没有那么强，每一个功能模块之间的耦合度还是很高，因此小的改动往往会带来许多bug，从而不得不在各个模块里找问题，花费的时间也许就很多。
• 又或者是Core和UI的API接口，直接没有定义。导致对接的时候UI组的设计思路往往和Core提供的接口完全不符。本来设想只需要调用接口就能测试，现实则是UI组往往需要修改自己的代码甚至修改界面，以适应一个Core组的接口。因此往往测试一组就磨掉一个晚上。

以上问题皆是未竟的设计所带来的，对时间和效率的影响确实非常大。因此团队项目中绝对应该避免这里出现的错误，也许需要在小组讨论时提一下。（绝对应该避免但我清楚避免不了。。）

构建单元测试

敏捷开发往往很讲究单元测试，先编写单元测试用例再开发代码，足见单元测试在敏捷软件开发中的重要地位，它不仅仅起到了测试的作用，更重要的是通过测试用例的编写喜欢需求和完善设计思路。

然而现实很残酷，我不知道如何设计单元测试，小组内也没有人知道。我也不知道单元测试到底能给效率带来多大的提升，是否值得多花点人时去学习和设计？但单纯从知识和设计，或者开发的角度而言，单元测试在团队项中也是必不可少的。

系统集成调试

对于每一个单元，如果测试没有问题，那么就可以做集成测试了。

对于大型软件系统，产品集成和集成测试具有重要的地位，为了系统的有计划的降低系统集成调试的困难性我们需要采取多种方法和措施：

• 首先对于单个构建必须经过充分的单元测试，否则单元测试的问题将遗留到集成测试阶段导致问题复杂化；
• 其次是搭建充分的测试平台，测试平台往往需要编写测试代码，特别是还可能开发各种伪构件来验证数据集成的正确性。
• 最后是在集成期间要严格控制变更，最好是阶段化的定期变更。

这里其实也有在结对编程里体现出来。在UI和Core组各自认为自己做的东西都没有问题时，一次对接测试就能重新带着大家发现好几个错误和不足。Core和UI在开发逻辑上就有不一样的地方，因此各自设计时肯定存在考虑片面之处。这是系统集成调试就显得尤为重要了。