标签：
人月神话中第一章就提到了The Tar Pit ,在焦油坑种挣扎并且体验快乐并苦恼的编程过程，人月神话的开始就在讨论超级项目的合作与分工的矛盾以及内部模块的复杂交织。作者是IBM OS/360项目的项目经理和主要负责人，IBM/360所犯的错误以及给我们的启示成就了这本书，本书的目的是为身处焦油坑里的软件工作人员提供一点帮助和引导。依作者的观点，“人月神话”的出现和工程进度的不合理安排有很大关系，因此合理工程化体系的建立很有必要，盲目的软件生产心理和人员协调中存在的问题导致了软件工业的巨大失败率，这确实给了后继的软件开发人员很鲜明的指引。
由于事先不重视项目估计和规划，以及对项目的进行的掌握没有很大的信心，项目经理们在不合理项目估算和计划上面吃了不少苦头，这直接影响到最后的测试和交付。作者指出，一个很严重的问题是，我们总是假设人和月可以互换，这给工程带来了很大的隐患，主观地认为进度和工作量的等价，因此，当项目遇到问题时，比如不能按时交付，经理们最直接的想法就是增加人力。这是一个愚蠢的想法，作者认为其中增加的人力资源会被随之增加的信息交流开销和已进行工作的部分返工抵消甚至更糟。这也是所谓的火上浇油，此外，在监督管理上的欠缺和盲目乐观常常导致较晚的错误发现和随之而来的巨大错误损失。
年轻的编程人员都有乐观主义，总是相信自己的代码是肯定能运行的。所谓的估计和预协调往往建立在乐观主义的基础上，并且由于盲目自信，导致最后的完成与初期预计出入悬殊，隐藏着巨大的危险和经济损失。而现实往往不是乐观，在项目的进展过程中会存在各种不可预知的问题，并且这些问题的解决并不是单纯靠工作量的增加能得以缓解的。在这个时候对人月的盲目观念就会是项目经理犯下更严重的错误，项目经理就会为项目增加人员，然而增加人员反而导致项目进度越来越慢，导致在焦油坑中越陷越深。在投入了更多的人力的时候，经理发现项目进度反而更慢他就会投入更多的人力，这种恶行循环导致项目的失败和成本与进度的巨大反差。
Harlen Mills 指出，应该仍以团队划分的机制来进行分工，即大型项目的构建不能脱离人力，但是每个承担具体任务的团队宜建立外科手术式的体系。就我对这种体系的理解，贵族精英化的统领和具体实现的民主和创新会有一种比较好的效果，在许多大型工程项目中均有普遍性，在软件工程中尤为突出。这种不可预测的开发过程越具有完整性越会有较好的开发成绩，过度交织和缺乏统一划定往往会造成巨大的结构复杂性和错误率，导致难以预计的损失和难以挽回的失败。这样，沟通的成本就会降低，实现人员也会有的放矢，发挥出其工作范围内的创造性，同时，要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界限，系统架构师——即“外科手术医生”必须一丝不苟地专注于体系结构。
概念完整性——很抽象的一个词汇，我的理解是，在宏观上可以整合，符合统一限定的规则并且思路上是连贯的，这就需要一个统一的协调机制，使不同模块的工作人员都能按照连贯的方式去协调工作并完善对接。书中说到“概念完整性要求设计必须由一个人，或者非常少数互有默契的人来实现”。这一点和外科手术式的队伍理念上一致，这同水平分割的论坛式团队组织相比，效率自然大大提高，这主要体现在它所代表的垂直分割所具有的人员沟通上的优势和相比之下在概念完整性上的明显优势。
第二个系统的危险性在于画蛇添足，由于有了第一个系统的经验，设计师对此类系统充满信心，同时，在对新系统的构思中，就会想着如何去润色和完善已有功能并且加入“额外的装饰”，这一点俗称“画蛇添足”。这就好比是促狭的进化路线，在某些方面发展地很好，令人大为称赞，但是却没有顾及到普遍的发展要求，不知不觉走进了一个误区，成为了“最后的最优秀的恐龙”。这一点往往成为了软件开发的阴云，这令我想起了曾经芬兰以及世界最著名的移动电话生产商——诺基亚，在发展如此迅速的电子行业中，在旧的体系中越做越好，精益求精；诚然，在通话手机和功能机上，他们达到了没有人能超越的水平，但是智能机迅速抢占的市场份额却没有给他们警示，依然沉浸在之前的成功中——这就好比是“第一个系统”。虽然，就我的理解，这个比喻不是特别恰当，但是却在一定程度上反映出了部分的事实和其中的危机。
手册和形式化的说明，会在一定程度上缓解开发和测试乃至维护上的棘手问题，这使整个开发有一个理解上的标准并且在交流和日常会议中以予贯彻和统一。测试人员和实现人员要有充分的沟通，以保证测试的标准性和完整性，在不同的方面都达成就手册说明的较为一致的理解。整本书在前面强调了文档和交流组织的重要性，即时这样的完成要花费代码实现的约三倍成本，但还是利大于弊的，特别在大型软件中，这是开发推进和后续开发的重要支撑。在后几章中，具体说明了其实现意义和实现指引，在人员组织上投入了大量笔墨，足以体现其重要性；任务的划分和人员的匹配与协调，是好的管理者应该认识到的，在软件工程的不同方面都有其意义。合理的解决方案应该是平衡和激励，依据工作的特点进行安排，以取得尽可能好的开发效果。
当然，这是我所认为的本书的核心理念和启示，在其中找到了一个落脚点进行阐释，也揉入了我对软件工程的理解，水平有限，望大家多指正。
2016年6月20日 于武昌珞珈山
符祖昊
标签：
原文地址：http://www.cnblogs.com/fuzuhao/p/5602136.html
