读完《人月神话》这本书，让我对软件行业这个整体进行了思考。其实我们每一位开发者哪怕从事软件开发数年，一直陷在编程开发技术积累这一个坑里面，而实际上编程只占软件开发周期的1/6，沉迷于编程开发只会局限我们的视野。
我有一个不算严谨的比喻，如果说古希腊诸神和英雄创造了古希腊的历史，那么《人月神话》里的“人”便是诸神和英雄，“人”通过“人月”这个利器为软件行业贡献年华。而古希腊诸神最终走向了灭亡，正如以人月衡量一项工作的规模是一个带有危险和欺骗性的神话。
本书作者brooks作为IBM的360系统的项目经理，被称作是“IBM360系统之父”，并凭此获取美国国家技术奖，《人月神话》作为其经典之作，也在业内被广为推崇。下面就章节顺序依次写出我的读后感。
开篇直点中心论点：软件产品的关键是维持产品自身的概念完整性。以焦油坑为比喻：即使你足够强大，也无法摆脱束缚而沉到坑底。很多大小型系统都是这样的一个焦油坑，各种问题纠结在一起。编程就是一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
编程系统产品（9）=编程系统（3）X编程产品（3），也即是说当这两项任务结合到一起时工作量和难度并不是简单的加减，这就要求必须有合理的时间进度，缺乏合理的时间进度是造成项目滞后的最主要原因。那么是否可以用人月来衡量工作的规模进而依此为单位来安排时间进度呢？答案在上面已经提到过了，是不可以的，其根本原因在于人员数量和时间不可以相互替换和转化。唯一使用情况是当前任务可分解且人员之间无需交流，否则任何一个条件不满足都会大大的加大任务的复杂度。
Brooks关于软件任务进度安排有这样一个理论：计划占1/3，编码占1/6,构件测试和早期系统测试占1/4，系统测试和完成所有构件占1/4。并且brooks提出了自己的法则，brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。这个观点无疑是正确的，软件开发本质上是一件系统工作，是错综复杂关系下的一种实践和沟通，新增人员加大的上手和沟通成本是巨大的，项目越大，开发周期越长，成本越大，所以以新增人员的方式弥补进度是得不偿失与弥补不了的。
外科手术队伍
Brooks有一个很形象的比喻，把软件开发团队比作是外科手术队伍。好的程序员与差的程序员效率相差10倍，这是个很夸张的数字，所以一个队伍中必须有一个好的程序员充充当首席程序员（外科医生），与外科医生需要一堆帮手一样，首席程序员需要一个副手，需要管理员丶编辑丶普通程序员丶工具维护员等，以这样的小规模团队维护软件的概念完整性，当个团队扩建时，可以对首席程序员的帮手继续往下分解职位。
Brooks在本书中尤其强调手册的重要性，手册中的规格说明风格必须清晰丶完整和准确，他必须在仔细定义规定什么的同时，定义未规定什么。在定义方式的选择上，必须以其中一种为标准，另一种作为辅助，并照此明确的进行划分。正应一句古老的言语，“绝不要携带两个时钟出海，带一个或三个。”
聚沙成塔，集腋成裘
软件产品开发过程中无法避免的会出现问题，当尖锐的问题被提出时，抛开问题不谈是一种及其愚蠢的办法。沟通是必要的，实际上我们可以通过定期的会议和大会把问题拿到板面上来，像周例会和年度大会就是一种非常有效的方式，这一点我在之前公司实习的时候深有体会，这不光能解决公司产品积累的问题，而且还能发现自己本身存在的一些问题。往往系统的奔溃都是因为一系列的小问题的堆集造成的。
不变只是愿望，变化才是永恒
项目中唯一不变的就是变化本身，当遇到变化时，普遍的做法是选择一种方法试试看，如果失败了，没关系，再试试别的。对于一个广泛使用的产品，维护总成本通常是开发成本的40%甚至更多，且用户越多，所发现的错误也越多。维护中的一个基本问题——缺陷修复总会以20%-50%的几率引入新的bug，所以整个过程是前进两步，后退一步。
Brooks有一个观点：系统软件开发是较少混乱度的过程，所以它本身是出于亚稳态的。软件维护是提高混乱度的过程，即使是最熟练的软件维护工程师，也只是放缓了系统退化到非稳态的进程。这个观点我相信绝大多数从事软件管理人员是支持的。
巧匠因为他的工具而出名
再牛逼的程序员都依赖于其工具。我的老师在课上讲过这样一个故事：某开源网站上的大神级别的程序员去参加google面试，google面试有一个很奇怪的要求，给你一张白纸，在上面手写一个算法。没了好用的工具没了代码提示，该大神竟然没写出能用的算法，进而被google拒绝。但能因此说该大神徒有虚名吗？事实上，我们大部分程序员在习惯使用了自己的ide后换其他ide也是极度不适应的，每个人都有对自己来说效率最高的一套工具，为什么要强求使用其他工具呢，最适合的才是最好的。在被google拒绝后，该大神被苹果以重金聘请了。
祸起萧墙
带来坏消息的人不受欢迎
一天一天的进度落后是难以识别丶不容易防范和难以弥补的，长期下来会造成难以承受的负担，最终导致项目的失败。必须制定有效的计划来防范这种祸根。第一个步骤是制定进度表，进度表上的每件事都是里程碑，里程碑的原则是具体的丶特定的丶可度量的事件。但是项目出现的问题通常是利益相关的，如何揭开毯子下面的污垢呢，brooks提出一种是减少角色冲突和鼓励状态共享，另一种是猛的拉开地毯。
另外一面
不了解就无法真正拥有，作为项目的管理者，必须对项目整体有一个清晰的认识才能准确把握项目的进度丶项目存在的问题，我们不能只看到项目的表面而忽视项目下的千疮百孔，例如facebook这样的项目下面都是成堆的bug。这就体现的文档的重要性，必须认识到文档是必不少的，但是文档本身又是一种负担，还必须在能体现项目的同时充分减轻文档的分量。
没有银弹
这可能是brooks最经典的语录了，乃至于以及称为业界内通用语句了。Brooks认为没有任何技术或管理上的进展，能够独立的许诺十年内使生产率丶可靠性或简洁性获得数量级上的进步。事实证明也确实这样，软件技术日新月异，技术方案层出不穷，但是永远没有最好的方案，工程师们只能基于已有的技术选择最合适的方案，我把它叫做麻醉弹（暂时的解决方案）。或许没有银弹的另一层意思是没有银弹，只有麻醉弹。