用了将近一周的时间，终于把人月神话读完了。本想着今天把读书笔记全部发完，但是老师要求每天都要发表博客，所以我决定分三天发表。我看的是40周年中文纪念版。相比于原版增加了一些作者根据今天软件工程管理现状添加的一些新的观点与评论，看看哪些过时了，哪些依然有效。
人月神话在开头有一句荷兰谚语：Een schip op het strand is een baken in zee.[A ship on the beach is a lighthouse to the sea.] ----DUTCH PROVERB.意思是：岸上的船儿，如同海上的灯塔，无法移动。刚开始我感觉这句话牛头不对马嘴的，它想表达什么，岸上的船没用吗，那为什么还把它比喻成海上的灯塔。就这样我带着满腹的疑问与好奇开始读这本书。
第一章讲的是焦油坑，焦油坑是作者用来形容大型系统开发的一个概念。史前时代，恐龙、猛犸象、剑齿虎这些大型食肉动物碰到焦油坑也是没有办法挣脱的，而且越用力就越容易被沉入坑底。这种场景就像极了我们平时写程序时的尴尬，很多问题堆积到一块，以至于太过复杂，不知道从哪里下手。现在想到王建民老师的教导，对解决焦油坑真是恰到好处。老师说的很对分而治之，把大的问题分为一个个小的问题逐个解决，前台后台分开写，DAO层SERVERLATE层在分开写，一个工程的开发也是这样。同时作者也在本章中也总结了编程的乐趣——创造全新的事物，并且该事物对他人是有用的；而且在创造的过程中你需要不断地进行学习，从而获得持续学习的乐趣等等。这些快乐不仅满足了我们内心身处进行创建的渴望，而且还唤醒每个人内心的情感。任何事物带来快乐的同时，不可避免有着随之而来地苦恼，于编程而言——追求完美。对我来说，在软件开发中我的乐趣在于：1、开发对其他人有用的东西的乐趣/2、面对不重复的任务，不断学习的乐趣。烦恼就是有时候真的不会不会编程。
第二章讲的是人月神话。对于这个我有自己的远一点理解，因为王老师经常让我们极限测试，在规定的时间内编完程序，这真是一种挑战。人月神话虽然强调的不是这个，但是也有一点涉及时间的概念。对于软件项目进度的估算往往会根据项目的紧急程度而得出过于乐观的结果，这一方面是因为所有的编程人员都是乐观主义者，我们往往会认为“这次肯定能运行”或者是“我已经找出了最后一个bug”，另一方面则来源于市场的压力，这种情况在国内环境更甚。我们对于进度估算的第一个错误假设就是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。而这个假设往往是一厢情愿的，对于创造性工作来说，创造者常常是在实现过程中，才发现在构思设计时候的不完整性和不一致性，从而反馈到的构思设计上，处理这种问题的时间和复杂程度会随着项目的结构以及任务的大小而呈现非线性增加的关系。所以对于大型软件项目来说，“一切都将运作良好”就是一件概率非常小的事情了。在软件项目中我们往往用人月这个指标在衡量项目的工作量。但是人月这个指标实际上是一个危险的带有欺骗性的神话。它暗示着人员数量和时间是可以互相替换的。只有在将任务分解给参与人员后他们之间不需要互相交流的情况下，人数和时间才是可以互换的。在实际软件项目中，只要项目具有一定规模，不论是设计、开发、测试、部署各个阶段都会有分解任务给不同人员，而且这些阶段本身也属于一种任务的分解，在不同人员间分解任务就不可避免的引发额外的沟通成本——培训和相互沟通。因为软件开发本质上是一项系统工作——错综复杂的关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。简单来说就是，3个人要干3个月的事情不是说安排9个人就能1个月干完了。而且，在进度落后的项目中增加人手的做法，往往只会使进度更加落后。这就是去除了神话色彩的人月。
2018-03-08
作为一本计算机编程项目管理类的书刊，此书书名就毫不留情地指出“用人月作为衡量一项工作的规模是一个危险
和带有欺骗性的神话”。这里向读者传达了这个重要的概念，在估计和进度安排中使用的工作量单位：人月。但实
际上，人数和时间的互换是近乎不可能的，因为编程项目的任务不能分解给互相毫无交流的参与人员们（关系如
下图所示）。
在本书开头部分，作者讨论了编程从业者的职业乐趣和苦恼，并且以精妙地将编程比喻为焦油坑，编程团队比喻
为外科手术队伍，围绕着软件开发中的各大障碍和误区，展开了对编程团队管理方法的讨论。总结为以下几点：
- 系统测试的进度安排。系统测试是最难完成暗示完成的部分，而这种拖延的二次成本却是巨大的。
- 空泛的估算。任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。
- 重复产生的进度灾难。通过增派人手来完成任务的方式往往事半功倍。
然后，作者以结构师的角度进行分析，阐述正确的做法来保持产品系统的概念一致性和编程人员的正确实践，这也
是此书关于概念一致性的核心理论。主要在于：
- 创造性活动上的专制性统治但也要求结构师与建筑人员的仔细交流。
- 文档化的规格说明以及一系列保证编程实现人员理解决策的手段
接下来，作者以巴比伦塔建造失败、各个先例的数据的案例来具体分析了大型编程项目中的交流与组织架构，强调
了编程中程序空间与计算机产品文档的重要性。
- 巴比伦塔项目的失败原因主要在于缺乏交流以及交流的结果即组织。团队交流、项目手册及组织架构重要。
- 整项工作的的估算绝不能仅依靠对编码部分的估计，尤其是小型独立程序的数据本就不适合编程系统项目。
- 编程产品的实验性工厂为提高产量和缺乏保护环境下运作提供宝贵经验。
- 开发过程中专业工具的使用，以及通用工具的开发分配资源对生产率的影响深刻。
最后，本书介绍了一些对于软件整体部分bug的减少有效的一些理论措施，如自顶向下设计、结构性编程、高级别表
达方式等，好的结构设计可以避免很多小错误。
这本书给我留下的最深刻、最重要的观点便是它对人员与月数的关系的描述。它强调少而精的团队，是因为在关系错
综复杂的任务之中，人员交流时间的变多、交流效率的变低会使开发进度延长。我在实验室常常有相同的体会，处于
项目边缘的成员们往往很难入手，而在不自觉的等待与观望或费时费力的交流之中让时间悄悄溜走。
正是由于这个矛盾的出现，人员与时间的调控，尤其是在大型的复杂编程项目之中，显得尤为重要。如何把一系列程
序设计和构建成系统，如何把程序或者系统设计成健壮的、经过测试的、文档化的、可支持的产品，如何维持对大量
的复杂性的控制，将成为软件工程这个“焦油坑”中持续存在的问题，而IT领域的飞速发展更是督促着我们不断地学习新
工具的最佳使用。
另一个令人惊叹的观点就在于，结构师交互准则与机制中提到的开发第二个系统的画蛇添足——倾向于过分设计。这里
提到，当他们在设计第三到第四个系统时，先前的经验就会互相印证，并且为了避免第二个系统的画蛇添足，他们应坚
持至少拥有两个以上系统开发经验的结构师的决策。这提醒了我们，现代软件工程中经验十分重要，一类系统中通用特
性的判断，以及系统之间的差异会帮助我们识别出经验中不够用的部分，并且可以成为一种积累。
总而言之，为了避免可怕的进度偏离，一个优秀的整体架构以及里程碑式的报告举足轻重，等到项目进行之后临时的增
援只会大大地扰乱我们的“人月”计划。