《人月神话•40周年中文纪念版》读书笔记

发表于 2019-12-30 分类于随笔本文字数： 1.3k 阅读时长 ≈ 1 分钟

这是一篇拖欠了很久的读书笔记，今年烙饼师送了我两本书，之前答应他要写读书笔记来着，结果一直拖延到现在，马上2019过去了，赶紧补上(光速逃😆

说实话，书里讲的有些东西我还无法理解，大概是欠缺经验导致的。就记录下感受比较深的几点吧:

1、效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。受限于每个人的水平、能力，处理同一件事时花费的时间是不同的。一个小组中最好的和最差的表现在生产率上平均为10：1；在编程速度和空间上具有5：1的惊人差异，这一点在实际工作中是比较容易表现出来的。

2、10人编程团队。将一个大型项目进行拆分，每个部分由一个团队解决。由首席程序员来完成问题的分解，其他人给与他所需要的支持，以提高效率和生产率。当遇到观点不一致时，由首席程序员来进行统一。

团队成员应该以尽可能多的方式进行相互之间的交流，增强成员之间对项目的理解，比如非正式地进行简要技术陈述的常规项目会议、共享的项目手册等。

1、文档的规格说明风格必须清晰、完整和准确，一个好的开发文档或使用手册能够给开发人员、用户等带来更好的使用体验。像在工作中对外提供一个工具，写好使用文档是极其必要的，比如要考虑到系统兼容、锁定组件依赖版本等问题，必要时还需要进行裸机部署测试，保证对方在拿到文档后，按照步骤操作能够跑起来。

2、手册的实时更新是非常关键的，它能确保信息能够到达所有需要它的人手中，可以作为一种沟通渠道，让需要他的人知道项目目前所处的状态，某一处起到了什么作用，作了何种修改和调整，变更的重要性等。

3、想起之前交流的时候，有同学说一些公司或者部门会有一个Wiki系统，用来记录业务点、知识点等，也是一种优秀的总结方式，这样遇到问题可以去Wiki查找，有新人报道时也能省下很多时间。

4、流程图。一图胜千言，当流程图绘制在一张图上时，能非常优雅的显示程序的判断流向，但分成几张时会大打折扣，整体结构的概观会被严重破坏。

1、开发人员必须设置软件系统规模的目标，控制规模，考虑减小规模的方法，最大化资源利用率，减少不必要的资源占用，大概就像做算法题时找最优解一样吧。

2、开发公共单元，每个项目要有能用于队列、搜索、散列和排序的例程或者宏库。对于每项功能，库至少应该有两个程序实现: 运行速度较快和短小精炼的。这一点的话，不知道有多少公司或者团队可以做到…

1、剔除BUG的设计，系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配是大多数致命或难以察觉的BUG的主要来源。细致的功能定义、仔细的规格说明、规范化的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量。

2、构件单元调试，工作中测试越及时越完整，就能更早消灭隐患。平时我们要求写的单元测试其实就蛮重要的，但是如果没有一个完整的测试流程、测试平台，基本忙起来的时候全靠开发人员自觉了，有的当时观察下结果没有异常就上线了，等到好几天以后才发现问题。我想很多人都有类似的经历吧。

目前就这些了吧，我觉得等经历更丰富一些，再来读会有更深的感受吧~

滴、打卡完毕！😃