物理量纲失效了-论《人月神话》

转自知乎2016-06-19  https://zhuanlan.zhihu.com/p/21381297

《人月神话》这本书的作者，是美国人弗雷德里克，布鲁克斯，第一批计算机专业博士。所设计的-STRETCH与ibm/360系统是计算机史上的著名设计。并在《人月神话》一书中，探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。

本书的主要思想，归纳起来主要是以下几点：
1.“人月”的工作量，完全并不是想象中的指标，随着“人”的成倍增加，并不代表着“月”的减少，甚至可能是“月”的增加。进度无论如何不可能被压缩到3/4以内。
2.架构师是最重要的，以确保概念的完整性，合理的切分工作，制定接口。行政领导应当尊重架构师的权威。
3.不存在一个神奇的方法或技术“银弹”，实现数量级以上的程序员的工作效率的提升。

作为一名客户与需求方。我对书中所描写的种种，深表同意。“人月”这一量纲，总会给我们一种错觉，那就是只要10人*1月=1人*10月。然而，这完全是一个错误。

我自认为是一名还算合格的需求方，需求明确，没有变更，然而，外界条件总是迫使我们一改再改。就拿我目前正在负责的某数据分析系统项目为例吧，目前是6月中旬，系统开发的截止时间是9月底，还有3个半月。

开发方反馈：数据接口A存在问题。原因是数据接口侧表示7月底要上新的数据格式，目前格式的数据仅供参考。而且7月底这个时间点有风险（该项工作由外部因素决定，无法改变）
我只能要求开发方同步进行两套方案的开发：即老数据接口的对接，以及新数据格式的对接（依照规范文档—我相信大家都知道规范文档和实际数据的差距能有多大）
同样是此项目的系统建设需求，我和开发方多次沟通，5月份开了5次当面会，但我自觉已经写的非常清楚的需求文档，依旧会有N多需要澄清的需求点。既包括厂家未正确理解我的需求的情况；也包括实际协调的困难，当然也包括开发方不给力的情况。

然后，我们最常说的一句话是:”一期时间比较紧张，因此，这个需求放到二期吧“。如果你也看了”人月神话“，相信你们明白我在说什么。那就是”开发第二个系统所引起的后果“—将在第一个系统中因为小心谨慎或预算原因所未添加的功能全部加入。鉴于此，我计划从现在就开始起草第二期的需求文档，并评估其必要性。
我相信看完“人月神话”对我是有益的，就从这个项目开始发挥作用。尽管我不是一个真正意义上的项目经理或者架构师。

接下来，说说书中所说到的另一个重点：银弹。
作者认为主要时间，在于软件所固有的概念的复杂性。而目前并没有发现较好的抽象化描述这些复杂性的办法。作者认同时间效率确实提升了，但更多节省的，是原来的次要时间，包括系统硬件能力提升所节约的等待时间；统一编译环境与高级程序语言所节约的底层编译时间以及软件复杂度。如果拿C、PYTHON等高级语言与汇编相比，我相信结果是更加显而易见的。
然而，程序员所构思的主要时间，依旧没有看到能够明显减少的情况。那就是构思软件的抽象化框架与设计。作者认为，必须期待的是，类似物理学家的“不等式”那样的从更高纬度进行描述的方法，我们才有可能减少固有概念的复杂性。

应该说，尽管我只写过几个简单的脚本，我依旧深刻的感受到了软件概念中所蕴含的那种不确定性与复杂性。输入编码与字符类型的不确定性，URL请求结果是否成功，是否完整的不确定性；数组溢出的不确定性；监听任务吊死的冲突可能；调试环境与工作环境的不一致性。 以上种种，仅仅是一个程序所面临的最初级的困难。面对当前的复杂的网络与应用场景，甚至以及安全方面的需求。思考，构思，并最终转变为代码，需要的复杂性超过一般的想象。
作者在书中说到“测试的时间至少需要整个开发流程时间的一半”。我对此深表赞同。测试与调试是程序开发的主要主题。

人月神话一书最早成于1975年，当时C语言刚刚出现。大量的程序还是基于汇编进行开发。因此作者对高级程序语言，面向对象编程，层次化编程模块等技术寄予了很高的期望。从40年后的今天来看，尽管随着各种开发工具和“轮子”的成熟，程序员的单位时间产出效率不断提高，但是软件的功能复杂度与需求复杂度也日益增加。以至于开发工作依旧和40年前并没有太大的差别。人月神话依旧只是一个“神话”。
也许我们可以期待的“神话”，只能是智能AI的诞生了吧。

后记：看书很舒适，很happy，写笔记真的很不舒适，进入了“强迫区”，不过，这也是一种提升自己的能力的机会。不管是系统性审视阅读的文章，还是对相关知识的思考。
所以，目前的todolist累计到了《美的历程》《解忧杂货铺》两本。但不知道什么时候会真的动笔。

来源：dotdotyy