大概花了三天的休息时间看完了这本书。这本书的来头基本上每个程序员都知道，不多赘述。这里只谈第一遍初读完，比较个人的理解与感受。
第一，人月神话，为什么被认为是神话，是因为人与月实际上是不能相互转换的，至少不是线性的。如果是线性的，那一个复杂的大项目只要无脑加人就行了。例如如果估计一个项目的工作量是1000人月，即一个人开发需要1000个月完成，那么把人加到1000人，一个月就能完成了么？显然不可能。
实际上，当一个项目足够复杂，并且不断遇到开发问题时，粗暴的加开发资源可能不仅不会加快开发进度，反而会拖慢。首先不断遇到开发问题的项目本身就存在问题，这可能是项目的初期设计存在问题、组织结构造成的矛盾、残缺或不规范的文档、实现的质量问题等，这些问题并不能因为开发资源的变多而解决或改善。另一方面，新的开发人员的加入意味着需要额外的人力和时间进行培训。而人员的变多，意味着交流成本也在变高。
我至今还未参与过这样的项目中，我们甚至还会说玩笑话：“没有什么需求是加人不能做的，如果不能，那就加两个”。不过我们隔壁组似乎遇到了这样的问题。不断推迟的上线时间，以及不断暴露出来的问题，使得这个组不停的在加人，不止从外面招新人加入，还通过“活水”从公司别的组抽调人手。虽说糟糕的情况在改善，但开发进度却也没有因为开发人员的变多而明显的加快。某次开会的时候，问了一下这个组的人，他苦笑一句：“每天花在code review 上的时间大大增加了。”
第二，概念完整性的重要性。易用性是一款软件的重要目标。当一款软件的功能足够强大但理解成本过高，使得用户不得不花费大量的时间去学习时，软件在推广和售卖上必定就会遇到问题。举一个简单的例子，如果一款画图软件，在选择某个图层时键盘的“R”键表示删除，而在选择图层中的某个元素时，需要使用“ctrl”+“R”才能完成删除动作，这就意味着同样的删除动作，用户需要学习并记忆两次以上。
易用性的测量标准并不是简单这一单一的标准，而是功能与理解上复杂程度的比值。在满足用户足够多的需求的同时，降低用户的理解难度，甚至用户可以举一反三的去完成某些任务，才是易用性的表现。也就是说软件的每个部分的同类功能上有相同的使用方法，在完成每个任务的流程上有相似的路径。因此，易用性实际上需要设计的一致性和概念的完整性。
软件开发可以分为三个部分：体系结构设计（architecture）、实现设计（implementation）、具体实现（realization）。概念的完整性要求设计必须由一个人或小部分理念一致、沟通紧密的人的来实现。体系结构的设计指的是完整和详细的用户接口说明，是用户要完成自己全部工作所需参考的全部手册。这跟具体实现不一样，体系结构陈述的是发生了什么，而实现描述的是如何实现。
将体系结构设计与后两者区分开来可能会被人误解说禁锢了实现者的创造力，但实际上实现者的创造力可以在实现设计或具体实现上进行体现。这样的区分可以加快整体的开发进度，在严格按照体系结构设计的实现中，各个部分的开发者只需要关心自身实现部分的逻辑就可以了。
第三，进度的把控非常重要。现在的互联网公司中一般都会有“里程碑”或者敏捷计划等来作为进度把控的手段。进度的把控有点薛定谔，谁也无法保证在预定的时间点上是否能完成既定的目标。但一份具体的、特定的、可度量的进度计划可以在开发过程中作为一个参照物，来防范“突然”的项目拖延。在实际工作中，我们不免会因为身体不适、业务外的琐碎工作、实现时遇到未预见的难题造成开发时长估计不足等原因造成半天或者一天的进度拖延。但当这种进度滞后多次发生，却没有被足够警惕时，就可能会“祸起萧墙”，造成最终项目结果的拖延。
那么，怎样的一份进度计划是合理的呢? 程序员往往是乐观主义者，在定制进度计划上，往往以“没有遇到什么问题”的心态在估算时间，这显然是不正确的。在业务组的时候，我们会简单的在乐观估计的时间上乘以一个常数来作为预计完成任务的时间。在以一周或两周为周期的敏捷开发中或许是一个不错的方法，但在一个开发人月几十或几百以上的项目中，这种粗暴的估算方法就不适用了。
书中提到了使用 PERT（Program/Project Evaluation and Review Technique） 来协助制定一份进度计划。构建PERT图，需要明确四个概念：
1） 事件（Events）表示主要活动结束的点；
2）活动（Activities）表示从一个事件到另一个事件之间的过程；
3）松弛事件（Slack time）表示不影响完工前提下可能被推迟完成的最大事件；
4）关键路径（Critical Path）是PERT网络中花费时间最长的事件和活动的序列。
当一个事件和活动位于关键路径上时，其工作滞后就会影响最终的完成日期。
“银色子弹”是《人月神话》中争议性比较大的章节，其中提到的AI技术在这几年也发展的十分火热，这部分内容只能粗浅的从他人的结论上获得理解，所以这里就不讲了。
《人月神话》确实是一本非常值得一看的一本书，特别是对已经从业几年的开发者来说。
