读《人月神话》之感受

                      中国科学技术大学软件      朱秀秀           原创作品转载请注明出处

  自暑假以来，就认识到这本书几乎成了软件行业不可或缺的一碗鸡汤，不过在我刚一看到“神话”两个字，两眼顿时放光，觉得闲暇之余还可以看看神话之类的小说，煞是惬意，可是暑假档期排得实在是不能再满了，于是乎，决定开学之后再看吧。

    暑假的课程紧锣密鼓的进行着，一天，两天、、、。只能说从来没有如此充实的度过长达一个月的起早贪黑的学习生活，好在这段难忘的时间终究还是离我而去，几场考试过后，向往已久的研究生生活开始了。

    于是在老师的再次提醒下，《人月神话》终究还是进入了我的眼帘，刚开始看，感觉跟我对软件尤其是编程的认识还是基本相符的，越往后看，越觉得我之前对软件的认识彻底被颠覆了，以前觉得写一个程序，只要能跑，达到我想要的结果，就万事大吉了，现在，我觉得写一个程序，就像上帝在创建一个小型社会一样，这个“小型社会”随着运行的次数多了，用到的人越来越多，其中暴漏出来的矛盾也会越来越严重，就像一个社会的发展，刚开始是农业社会，自给自足，人们相安无事，这就像程序的初期，只要能运行，很少有人会关心其中是否有潜在的bugs，但是随着人们欲望的膨胀—对计算机越来越依赖的本性（实际上是为了减少成本，对于个人来说可以节省更多的时间去做其他事情），就会不由自主的使程序复杂化，这就难免会引入越来越多的bugs,这个阶段就像是工业社会阶段的发展，为了追求发展，也不可避免的会引起越来越多的问题—空气污染，水土流失、、、。

    就像孕育婴儿一样，它们的生母—程序员同样需要健康的心理和良好的情绪，只有这样，孕育出来的程序缺陷才会比较少，生命周期才会比较长。要时刻注意，程序不是“产品”，他更不是“项目”，他只是组装“产品”或“项目”中必不可少的一组零件。

    之前，我一直以为，当个项目经理挺简单的：每天早上开个小会，催促一下大家的进度，其他结构神马的当然就由架构师全权负责喽，没想到细细品味这本书之后，又再次让我大跌眼镜，有多大的权利就意味着你应当承担多大的责任，尤其是作者提到的“人月”问题，彻底让我醉了，多亏了那个生动的例子：一个女人生孩子要十个月，十个女人生孩子还是要十个月。以前我认为，就像毛爷爷说的：“人多力量大”，再大的项目，只要有足够的人手还怕完不成吗，现在一想到“错误的设定项目周期是最大的错误，项目的发起、评审和预估都需要项目经理的精心考虑和思量 “还心有余悸。作为一个项目经理，如果不能摆脱我之前传统的认识的束缚，就会在项目周期不断缩短的诱惑下，投入更多的人力，以至于有可能使事情变得更糟，进入一个万劫不复的恶性循环中。

    就像社会的核心是人类一样，软件这个”小型社会“的核心终究也是我们人类（只不过是其中的少数），之前我认为一个项目中的重头戏应该就是密密麻麻的代码以及对他们夜以继日地调试，更让我吃惊的是：所有软件活动的根本任务竟然是——打造由抽象软件实体构成的复杂概念结构，我一直以为最关键的使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言竟然只是跑龙套的。当我认识到人是软件行业的主角的时候，我顿时感觉天空变亮了一些，我们的前景好像没有那么压力山大，细细品味之后，我认识到：一个好的项目必须依附于一个出色的团队，而一个出色的团队绝对离不开最出色的人员，在以前，我相信”三个臭皮匠，赛过诸葛亮“，但在软件行业，放眼望去，那些卓越的产品虽然出自于众人之手，但源泉绝对来自最优秀的设计人员。

    这就给我们一个提示，就像牛顿所说的：站在巨人的肩膀之上。我们可以通过遵循优秀而不是拙劣的实践，来得到良好的设计。优秀的设计是可以传授的。程序员的周围往往是最出色的人员，因此我们可以学习到良好的实践。这种策略，很像我们小学的时候，老师把那些模范作业展示给我们看，别忘了模范的作用可是不可小觑的。像软件工程研究所SEI等新机构的出现都是为了把我们的实践从不足提升到更高的水平。其正确性是勿庸置疑的。

    与此同时，贯穿于我们软件设计始终的是：致力于获得和维护概念的完整性，只要遵循了这一条，将会省去很多令人抓狂的问题。这个目标的实现就依靠团队的建设了，在这方面，作者竟然把我们熟悉的外科手术队伍引进软件行业，为此，把项目中的每一个角色与外科手术队伍中的每一个角色一一对应，这样，每个人的任务就一目了然了，同时，软件队伍中的每一个人员必须竭尽全力地配合外科医生——首席程序员，把项目完成的尽量漂亮。

    团队建设完成了，相应的对团队的管理一直以来是软件工程行业的一个热点话题，管理人员一蹴而就的想法是造成这种趋势的源头，为此，这本书教育我们应该用“微生物理论”代替“巨无霸理论”让我们知道进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力，才有了我们今天的软件工程。这就像俗话说的“没有规矩，不成方圆”，我们的社会必须有规章制度才能有条不紊，同样程序这个小型社会的诞生成长也需要”规章制度“，那就是实现他的团队尤其是管理人员和架构师所必须遵循的软件设计原则。

    人与人之间解决矛盾最有效的方法就是要及时沟通，相应的团队管理中最重要的也是要做到队员之间及时沟通。

    这本书中有很多我喜欢的至理名言，不过这一句让我印象最深：虽然没有通天大道，但是路就在脚下。

    在开发一件产品时，一定要做到仔细地进行市场调研，避免开发已上市的产品。在这个时代，概念设计人员是稀缺人才，一旦有了新概念，一定要在市场调研之后再进行开发，因为即使你开发出了更好的产品，如果有相同功能的先驱，开发的也还行的话，那么推广开来将会很难，所以我们一定要认识到市场调研的重要性。

    我之前因为学的都是硬件，所以很想找一个软件和硬件的契合点，然而我却发现：软件和硬件的一个很大的区别在于前者是诸多不同元素实体的集合，即使有相同的部分我们也会想办法，将其合并成一个可供调用的子程序。我觉得这一点是软件设计中优于硬件设计的地方，只要稍加修改，就可以直接调用，当然实现重用性没有那么简单。

    软件的生母是——不同的人，而不是上帝，所以就铸就了他不遵循自然科学中的规律：一定存在着简化的解释。在软件开发中，唯一不变的是变化本身。简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化。软件的客观存在不具有空间的形体特征。因此，没有已有的表达方式，就像陆地海洋有地图、硅片有膜片图、计算机有电路图一样。当我们试图用图形来描述软件结构时，我们发现它不仅仅包含一个，而是很多相互关联、重叠在一起的图形。

    勿庸置疑，软件生产率、可靠性和简洁性上最有力的突破是使用高级语言编程。大多数观察者相信开发生产率至少提高了五倍，同时可靠性、简洁性和理解程度也大为提高。高级语言最可能实现的是提供所有编程人员在抽象程序中能想到的要素。可以肯定的是，我们思考数据结构、数据类型和操作的速度稳固提高，不过是以非常缓慢的速度。另外，程序开发方法越来越接近用户的复杂度。然而，对于较少使用那些复杂深奥语言要素的用户，高级语言在某种程度上增加而不是减少了脑力劳动上的负担。这一点我深有感触，以前用汇编语言写代码的时候，很少有需要考虑那么久的语句实现。统一编程环境也使生产率提高了5倍，这一点我们在软件开发的过程中也要时刻注意。

    银弹似乎出现了？ 然而Ada仍然不是消灭软件生产率怪兽的银弹。毕竟，它只是另一种高级语言，这类语言出现最大的回报来自出现时的冲击，它通过使用更加抽象的语句来开发，降低了机器的次要复杂度。一旦这些难题被解决，就只剩下非常少的问题，解决剩余部分的获益必然也要少一些。必须仔细地区别两个不同的概念:抽象数据类型和层次化类型，后者也被称为类（class）。抽象数据类型的概念是指对象类型应该通过一个名称、一系列合适的值和操作来定义，而不是理应被隐藏的存储结构。这一点颠覆了之前我对面向对象编程的认识。

    它们的出现都消除了开发过程中的非本质困难，允许设计人员表达自己设计的内在特性，而不需要表达大量句法上的内容，这些内容并没有添加什么新的信息。对于抽象数据类型和层次化类型，它们都是解决了高级别的次要困难和允许采用较高层次的表现形式来表达设计。
    不过，这些提高仅仅能消除所有设计表达上的次要困难。软件的内在问题是设计的复杂度，上述方法并没有对它有任何的促进。除非我们现在的编程语言中，不必要的低层次类型说明占据了软件产品设计90％，面向对象编程才能带来数量级上的提高。对面向对象编程这颗“银弹”，我觉得夸大了面向对象编程的威力。
    随着多媒体技术的发展，多媒体也应用于软件开发。然而——软件开发上的困难是决定说什么，而不是如何说。表达的简化仅仅能提供少量的促进作用。

   之前一直听说专家系统，也搜了很多关于他的解释，但仍然处于懵懂状态。现在， 终于揭开了专家系统的真面目  ：专家系统是包含归纳推论引擎和规则基础的程序，它接收输入数据和假设条件，通过从基础规则推导逻辑结果，提出结论和建议，向用户展示前因后果，并解释最终的结果。推论引擎除了处理推理逻辑以外，通常还包括复杂逻辑或者概率数据和规则。

    认识到这种系统的能力不是来自某种前所未有的推导机制，而是来自非常丰富的知识积累基础，所以更加精确地反映了现实世界。这种技术提供的最重要进步是具体应用的复杂性与程序本身相分离，这是很大的一个进步。

    专家系统最强有力的贡献是给缺乏经验的开发人员提供服务，用最优秀开发者的经验和知识积累为他们提供了指导。这是非常大的贡献。最优秀和一般的软件工程实践之间的差距是非常大的，可能比其他工程领域中的差距都要大，一种传播优秀实践的工具特别重要。再一次让我对优秀开发者的产生无限兴趣。
    还有一些实现自动编程的论断，我支持作者的观点：自动编程总是成为一种热情，使用现在并不可用的更高级语言编程的热情。因为大多数情况下所给出的技术说明本质上是问题的解决方法，而不是问题自身。当然也不排除存在少数特例。，例如：数据发生器的开发技术就非常实用，并经常地用于排序程序中。一个很受欢迎的主题是图形化和可视化编程，计算机图形在软件设计上的应用，如同文中提出的，流程图是一种非常差劲软件结构表达方法程序验证。这使我之前对流程图熟练使用人员的崇拜感顿时荡然无存了。现代编程的许多工作是测试和修复bug。那些期待有可能出现银弹，能够在系统设计级别、源代码级别消除bug，可以在大量工作被投入到实现和测试之前，通过采用证实设计正确性的“深奥”策略，彻底提高软件的生产率和产品的可靠性的开发者，我觉得应该还有很漫长的路要走，至于能否走到路的尽头，亦或是成功的实现这个期望，目前前我觉得希望很渺茫。

    当我们向更好的编程开发环境开发中投入时，我们可以期待得到多少回报呢？人们的本能反应是首先着手解决高回报的问题。随着工作站的处理能力和内存容量的稳固和快速提高，我们能期望在软件领域取得多大的收获呢？现在的运算速度已经可以完全满足程序编制和文档书写的需要。编译还需要一些提高，即使在现在的机器运算速度下，程序开发人员的思考活动已然成为日常工作的主要活动。

    山重水复疑无路，柳暗花明又一村。当我们必须考虑那些解决软件上必要困难的活动——准确地表达复杂概念结构时，幸运地发现，其中的一些非常有希望。购买和自行开发。构建软件最可能的彻底解决方案是不开发任何软件。这一点是我从来没有过的认识。  

    需求精炼和快速原型。开发软件系统的过程中，最困难的部分是确切地决定搭建什么样的系统。概念性工作中，没有其他任何一个部分比确定详细的技术需求更加困难，详细的需求包括了所有的人机界面、与机器和其他软件系统的接口。需求工作对系统的影响比其他任何一个部分的失误都大，当然纠正需求的困难也比其他任何一个部分要大。因此，软件开发人员为客户所承担的最重要的职能是不断重复地抽取和细化产品的需求。事实上，客户不知道他们自己需要什么。复杂的软件系统往往是活动的、变化的系统。活动的动态部分是很难想象的。所以，在计划任何软件活动时，要让客户和设计人员之间进行多次广泛的交流沟通，并将其作为系统定义的一种方式。这一点有种醍醐灌顶的感觉：终了解了老师上课说的原始化模型有助于需求挖掘和系统设计。因此，现在的技术中最有希望的，并且解决了软件的根本而非次要问题的技术，是开发作为迭代需求过程的一部分——快速原型化系统的方法和工具。
    软件系统的快速原型对重要的系统界面进行模拟，并演示待开发系统的主要功能。原型不必受到相同硬件速度、规模或者成本约束的限制。原型通常展示了应用程序的功能主线，但不处理任何如无效输入、退出清除等异常情况。原型的目的是明确实际的概念结构，从而客户可以测试一致性和可用性。增量开发——增长，而非搭建系统，正如作者所说，。一瞬间，我的整个软件开发流程的视野也开阔了，这一点就像自然界中的生物，研究一下生物的复杂性，而不是人们的僵硬工作。我们会发现它们的复杂程度令我们敬畏。光是大脑本身，就比任何对它的描述都要复杂，比任何的模拟仿真都要强大，它的多样性、自我保护和自我更新能力异常丰富和有力。其中的秘密就是逐步发育成长，而不是一次性搭建。

    最让我瞠目结舌的一点就是：卓越和一般之间的差异竟然接近于一个数量级。

    最后，为了让自己能够安心的学习软件知识，最重要的是能够脚踏实地的锻炼编写代码的能力，我在心中默念：软件行业真的没有“银弹”！！！