再读人月神话，共鸣依旧

《人月神话》作者Brooks博士来自美国北卡，图灵奖得主，美国国家科学院院士，致力于计算机体系结构、操作系统和软件工程的研究。1975年，弗雷德·布鲁克斯结合自身在IBM公司System/360中的项目管理和软件工程的经验，写下了这本人月神话，至今仍畅销不衰，影响深远。

《人月神话》是本常看常新的书，会发现目前的项目和50年前的项目，二者遇到的问题似曾相识，书中详细论述了软件工程项目作为一种创造性的艺术产物，其高复杂性和可变性是无法预测的，未来也不会有更厉害的“银弹”去让现在的开发效能提升一个数量级，即使现在出现了越来越多的高级语言，高级框架，研发效能devops去使我们写代码越来越简单，bug越来越少，但软件开发的瓶颈一直都不是技术。

结合自身的经历和本书的一些观点，简单汇总为以下几节，权当读书笔记。

1. 估算乐观主义

每个月月初，刚刚拿到这个月的迭代需求的时候，往往是我们最自信，最乐观的时候，我们拉开excel，一边感叹功能的简单，一边迅速估算每个模块开发+自测+联调需要多少人天，有的甚至估算到小时，然后拉个会评审一下工作量，哇塞，至少能提前个5天交付，完全不慌，但干到月末突然发现搞不完了，要延期了，这种情况比比皆是。

我们太乐观了，总觉得一切都会按预想的来，一切都会很顺利，殊不知我们的构思是有限的，总会有bug产生，这部分你是没法估算的；开发的需求你以为理解了，但搞到最后其实已经偏离了要求，这部分你是无法估算的；最后我们为了进度，放弃了写回归用例，我们如同打地鼠一般，认为我解决了最后一个bug，但新的bug又冒了出来，这部分你是无法估算的；高优先级的无关琐碎的工作，会议，疾病，事假，团队有人离职等，这部分你是无法估算的，我们其实每天在不知不觉的开发中，进度都在一点点的落后。随着每次的延期，项目经理就会放弃估算，直接采用死线驱动开发（deadline -driver dev），到了deadline一定要发布，我们开始内卷，开始疯狂加班，最后带着我们82天的调休假和疲惫的身体提桶跑路。

其次用人月+人天这种作为衡量一项工作的规模是非常危险和具有欺骗性的，它暗示着人员的数量和时间是可以相互替换的，任务是没有次序上的限制的，且不需要开发人员沟通交流的。随着人手的增多，沟通成本也会越来越多，甚至会比之前更加缓慢。

有一些缓解办法，也仅仅是缓解：

• 你不能等到所有软件开发完了再测试，应该在任何一行代码或者可以带来结果的内容就执行测试，不为系统测试安排足够的时间，简直是一场灾难
• 好一点的团队都是以特性迭代为一个单元，相关的人员坐在一块，减少沟通成本
• 不要随意使用新的不稳定的，或者未经考验的开源组件，用的时候很爽，但后面可能会花费更多的时间修复它
• 要有一定的回归保障的，一步一步前进，TDD
• 小需求+小团队。要有一个准则，为每一个小功能分配一个值，每次改进，功能x不超过m字节的内存和n微妙，某为公司要求一次重构不能超过功能代码总量的5%~10%
• 看板backlog，燃尽图/波特图/甘特图等效能工具及时准确更新，暴露风险，不要快到deadline才去摇人，及时反馈问题，越快调整增删需求越好，要学会减法，然后在第二次迭代前要做复盘

2. 沟通的深渊

在过去几十年，大型系统开发就犹如一个焦油坑，他们中大多数可以开发出可运行的系统，不过只有非常少数的项目可以满足目标，时间进度和预算的要求。表面上看起来没有任何一个单独的问题会导致困难，但是他们相互纠缠起来，团队的行动就会越来越慢。

对其他人依赖是非常痛苦的事情，你依赖的其他人的程序，如果他们程序设计的不合理，实现拙劣且发布不完整，甚至没有测试用例，或者糟糕的文档记录，这都会导致我们花在沟通和研究的时间成倍增加。

团队间的沟通也很麻烦，人越多，相互之间交流情况更加糟糕，当召开会议去进行协商遇到的某个问题时，经常会遇到的场景是20人开会，1人在讲，2人在听，其余所有人都在刷手机。

反观大型编程项目该如何交流？

可视化信息发射流，类似于看板的大屏，但大屏东西不要太多，太多的信息也会眼花。主要以下几点：电话+会议+企业wiki文档（类似confluence）

开发人员需求不理解的问题，可以随时找架构师和其他相关团队开发做一个电话澄清，很有必要做一个澄清的日志留存。

我们把会议分成两种，一种是周例会，每周半天的会议，任何人可以在会前提出建议，然后在会上大家进行讨论，重点是创新而不仅仅是结论，大家可以发散很多解决方案，然后把少数解决方案传递给架构师，详细地记录到书面的变更记录中。接着会对详设做出决策，实现人员会仔细地针对优缺点进行讨论，如果不能达到共识，由首席架构师决定，另一种是半年会，目的是解决慢慢堆积起来的周会解决不了的问题，一般会持续2周。

企业wiki文档要记录哪些东西呢？

团队介绍，新人培训，项目迭代（目的，上线文档，FAQ，进度，外部规格说明，接口说明，技术规范，详设，概设，内部说明和评审，会议纪要）

3. 测试驱动，一如往前

自动化测试，分层测试，单元测试，开发要遵循测试。

在系统联调测试时，使用已经完好的，经过单测调试的组件，要比那些全部开发完都没有做过测试，寄希望于系统联调去发现bug解决bug的情况，要节省更多的时间。一般我们会有一个缺陷跟踪平台，如果发现一个缺陷可以记录在里面，当测试人员发现它还没有修复的时候，可以忽略他们，将注意力集中在新出现的问题上。

我们的程序需要根据功能理解进行拆分，然后进行测试驱动开发，敏捷因为迭代目标小，周期快，会让我们快速意识到产品是否符合客户预期。程序的易用性是发展的最终目标，比如说我们经常会有代码扫描工具扫描代码的复杂度，如果一个类很大看不懂，我们就要拆分它，直到看懂为止。

我们必须要拥有完整的测试用例，在添加了每一个新构件，都要重新回归测试一下，并确定一个里程碑，里程碑的选择只有一个，那就是一个百分百完成的事件（测试通过了所有测试用例，可以交付产品的节点）

经验显示，一个需求的开发的时间安排是这样的，1/3计划，1/6做编码，1/4单元+组件+系统测试，1/4端到端系统测试测试。

4. 文档在手，天下我有

不同用户需要不同级别的文档。

有的时候我们是为了应付而去写文档，里面只提供了很少的总结性的内容，就像是描绘了树木，形容了树皮但却没有一幅森林的图案。

一般开发一个需求的文档可以如下设计：

1. 目的：主要的功能是什么？开发程序的原因是什么？
2. 环境：程序运行在什么样的机器，硬件配置和操作系统上？
3. 范围：输入的有效范围是什么？允许显示的合法输出范围是什么？
4. 实现功能和使用的算法，包括流程图或子系统的结构体，数据流图，对所有文件规划的解释
   ​
5. 输入，输出的格式
6. 操作指令：包括控制台及输出内容中正常和异常结束的行为
7. 运行时间：解决特定规模问题所需要的时间？
8. 验证程序：除了的程序的使用方法，还必须附带一些程序正确运行的证明，小demo初始设计到发布之间，各个修改的讨论归档​
9. 仔细的市场调研，避免开发已上市的产品
10. 在获取和制定软件需求时，做个poc
11. 选项：用户的功能选项有哪些？如何在选项之间进行挑选？

5. 神秘的特战队

优秀程序员和较差的程序员之间的差距生产效率平均10：1，运行速度和空间上具有5：1的惊人差异。小而精的团队比300团队的普通人强得多，但一个大型项目，小团队也要干很久，这就产生了矛盾。一个理想的团队是，这个需求完全由这个特性团队承担，不存在利益差别，有锅一起抗，一拥而上的开发方法是高成本的，速度缓慢地，不充分的，系统设计应该是由一个或最多两人思考的产物。每个特性团队都能自闭环，前台，后台，测试，运维，发布。

1. 外科医生：首席程序员，亲自设计功能和性能技术，测试说明书，需要极高的天分，应用数学，业务数据处理或其他方面的大量系统和应用知识
2. 副手：外科医生的后备，作为设计的思考着，讨论着和评估人员，外科医生和他沟通设计，但不受到他的建议的限制
3. 管理员：充当与组织中其他管理机构的接口，敏捷教练在做这个，保姆式服务，一个管理员可以为两个团队服务
4. 编辑：根据外科医生的手稿，进行分析和重组，书写文档，提供各种参考信息和书目，对多个文档进行维护
5. 程序员：安安心心写代码
6. 测试人员：对整个工作进行测试，给架构师提供性能参考，要求测试需要知道开发使用的技术框架，设计测试数据的问题，负责计划测试的步骤和为测试搭建测试环境
7. 语言专家：技术大牛，通常一个大牛可以配好几个团队，类似公司的讲师
8. 工具维护人员：运维，维护系统平台，devops流水线平台， 测开，维护测试平台

大型项目的每一个部分都由这样的一个团队解决，类似外科手术队伍，以win7 team为例，共计5000万行代码：

• Applets and Gadgets （小程序和边栏应用）
• Assistance and Support Technologies （协助和支持技术）
• Core User Experience （核心用户体验）
• Customer Engineering and Telemetry （用户工程和遥测）
• Deployment and Component Platform? （部署和组件平台）
• Desktop Graphics （桌面图形）
• Devices and Media （设备和媒体）
• Devices and Storage （设备和存储）
• Documents and Printing （文档和打印）
• Engineering System and Tools （工程系统和工具）
• File System （文件系统）
• Find and Organize （查找与组织）
• Fundamentals （基础）
• Internet Explorer （包括IE8 down-level）
• International （国际化）
• Kernel & VM （内核与虚拟机）
• Media Center （媒体中心）
• Networking – Core （网络 – 核心）
• Networking – Enterprise （网络 – 企业）
• Networking – Wireless （网络 – 无线）
• Security （安全）
• User Interface Platform （用户界面平台）
• Windows App Platform （Windows 应用平台）

6. 写在最后

现如今我们有大量的框架套用，几天就能开发出一个产品，但这些如同批量生产的“口水歌”一般，慢慢就会被用户遗忘，软件开发者最终交付物不应该是产品，而应该是用户满意度。

写代码不难，难的是idea，是那些具有创意的产品。

Reference

https://book.douban.com/subject/26358448/

https://www.bilibili.com/video/BV18S4y1r77u/?share_source=copy_web&vd_source=d9138e00853f78efe2b9a3c791fb961b

https://www.zhihu.com/question/2173