这本书绝对称得上在软件工程领域的著作，作为软件开发人员，低头敲代码赶项目时，也要抬头看一看。在软件工程领域中，还存在很多代码解决不了的问题。
先借鉴百度百科的话，等整书读完了，再自己总结。
《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。在《人月神话（英文版）》中，既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。《人月神话(英文版)》适合任何软件开发行业的从业人员阅读，对软件开发人员、软件项目经理、系统分析师更是必读之作。
第一章——焦油坑
以焦油坑为例，类比了软件开发团队，在产品开发过程中一般都会出现的问题。经过数月开发，产品可以线上运行，但效果却和最初立项时目标甚远，不能满足需求。即使开发团队再挣扎，加班也好，加人也好，都无法解决问题，像陷在焦油坑里，越挣扎陷得越深。
以笔者自身经历：去年，我一直在参与公司的平台项目，经过一年的开发，产品功能很全，单独线上运行没问题。可它却背离的初衷-其它产品线能力共享，开箱即用。结果产品线都没有办法使用，为达目的又投入了大量人力，可效果微乎其微。
编程的快乐
1.创造事物的快乐，从无到有。
2.成果能给他人带来帮助，乐于分享。
3.多个程序组个一个系统，并以精妙的方式运行，增加成就感
4.持续学习的快乐
5.易于驾驭的介质(电脑)
编程的烦恼
1.由他人设定目标，供给资源，提供信息
2.开发依赖其他开发人员
3.寻找琐碎的bug是一件重复性的劳动
4.产品在即将完成时，却显得有些过时
第二章——人月神话
在软件项目中，缺乏合理的进度安排是造成项目延期的最主要原因，它比其它所有因素加起来的影响还要大。现在我们可能感受不深，看完下面作者的解读，才恍然大悟。不得不佩服作者的功力。
作者总结的原因我简单概括下：
- 对技术缺乏有效的研究，产生一种不真实的设想——一切都将运作良好。每一项任务仅仅花费它所“应该”花费的时间。编程人员通过非常纯粹的思维活动来开发程序，期待在实现过程中不会碰到困难。
（实际在开发中，往往会遇到很多问题，在实现细节环节最为明显，即便是相似的业务，可能还会遇到坑） - 以谬误的思考方式，在估计和进度安排中使用工作量单位：人月
书作者总结了四种关于人数和时间的转换关系曲线,自己又简单的化了下增加理解
IMG_3633.JPG
从图中可以清晰的看到，人月跟任务类型有着密切的关系。所以用人月来评估开发的工时，是不准确的。加人≠加生产力 - 系统测试的进度安排常常是编程中最不合理的部分。由于开发者的乐观主意，通常实际出现的缺陷数量要比预料的多得多。根据自身的开发经验，在系统测试中暴漏的问题都太好排查和解决，要花费更多的时间。
- 空乏的估算，缺少数据的支持，完全凭软件经理的直觉。为了满足客户期望的日期而造成不合理的进度安排，在软件工程领域最为普遍。（ps：天天加班加班，好像就是这么来的 - - ||）
- 重复产生的进度灾难。当一个软件项目落后于进度时，最普遍的做法就是加派人手。作者引用了Brooks法则，还印证这个不合理的做法。向进度落后的项目加派人手，只会是进度更加落后。
第三章——外壳手术队伍
近期更新
