《人月神话》之浅析

来源:互联网 发布:广电网络电视怎么按啊 编辑:程序博客网 时间:2024/04/29 07:45

《人月神话》之浅析

“中国科学技术大学软件学院”+ 李 宁 + “原创作品版权所有转载请注明出处”

 印象里,第一次接触软件工程,是在大四的时候,当时我们专业选修一门课叫做“GIS设计与实现”,因为大学时候学的最多的还是测绘方面的知识,所以对软件方面可谓是一知半解,更别提深入的了解了。微笑记得很清楚,书中给的例子也都是地学方面的知识,还有一个地区地籍管理信息系统的详细设计,因此以为也许软件工程只能在这些方面利用。

在融入软件工程的几个月中,觉得还是挺有意思的,从最开始的对代码一无所知,到渐渐的可以看懂一些代码,尽管自己还编写不出个比较规范和具有良好风格的代码,但是一切都在学习中。

《人月神话》是第一次上孟宁老师的高级软件工程这门课程时,老师在课堂上推荐大家课外选读的几本书之一。既然是老师建议大家选读的课外读物,应该都是和软件相关的,但是最初我可不是这么认为的。初次听到“人月神话”这几个字眼,我的理解就是很字面的,因为从小就对太空比较充满好奇,因此,觉得这本书里应该介绍的是关于人类探索宇宙的内容。然而,在我读了这本书的前几页后,就发现我的想法完全是不正确的,人,指的的是参与项目的人员,而月,指的是时间。

Frederick P. Brooks 的这本《人月神话》属于软件工程书类中的神品。因为在软件工程发展的40余年中,Jackson曾哀叹软件行业普遍缺乏专业性,而充满了业余人员。然而我们的Frederick P. Brooks却对这些现实中严峻而复杂的问题做了深入的讨论。

书中主要是系统的介绍了如何管理一个大型的计算机编程项目,它和管理其他行业的一个大型项目很相似,但是又有很大的差别,也许这些差别是项目经理们都难以猜测的。可能,我在阅读了一遍之后也没有看透笔者的意思,因为这本书主要面向的是软件工程的职业经理,而我作为一名出入门的软件工程的新生,要领悟到前辈的苦心,估计还是要花费一段时间的熬苦的。

作者在每个章节都会给出一个很有意思的引入,有把大型系统开发比作焦油坑,然后就是巨兽门在焦油坑中垂死挣扎,然而却没有任何的猛兽可以摆脱这种束缚,最终都沉到了坑底。这就好比是项目中的一个个的困难,每个人都很难看到问题的本质,那我们就先要去了解问题吧。在这个过程中,系统开发的从业者既会有苦恼也会有很多的乐趣,然而,对于很多人来说,是乐趣大于苦恼的。所以这本书就会引着大家来度过这个纠结的焦油坑。

“人月神话”告诉我们,在软件项目中,要有合理的进度安排,才可以时项目不滞后。Frederick P. Brooks认为用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话,因为软件开发实际上就是一个系统工作,沟通和交流的工作量非常大,会很消费节省下来的个人时间,因此会延长时间进度。

“外科手术队伍”给我们的启示是,让我们能够解决在有意义的进度安排内创建大型的系统。这里,我们就需要完备而且专业的人员分工,从而来保证每个部分的概念完整性得到彻底的提高。

“大教堂是艺术史上无与伦比的成就。它的原则既不乏味也不混乱.... ....真正达到了风格上的极致,完成这件作品的艺术家们,完全领悟和吸收了以往的成功经验,也完全掌握了他们那个时代的技术,而且在应用的时候做到了恰如其分,却不轻率,也绝不花哨。”。在计算机系统设计中,概念的完整性也无疑是很重要的,尽管它们通常是不需要花费几个世纪时间来构建,Frederick P. Brooks认为,在系统世纪中概念完整性应该是最重要考虑的因素,也就是说,为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统。

在系统的设计过程中,又要有什么样的机制和准则来约束结构师的创造热情呢,这就需要结构师和建筑人员之间彻底、谨慎、和谐的交流。在项目经理已经拥有行事规范、富有经验的结构师和编程人员后,他就需要文档化的规格说明,即手册来确保每个人都能理解并实现架构师的决策。在项目中设立测试小组也是使得设计决策得以贯彻执行的必要手段。

书中Frederick P. Brooks引用了巴别塔的教训,来告诉我们这些从业人员,在项目的实施过程中交流的重要性,交流和交流的结果--组织,都是一个工程项目成功的关键。

“实践是最好的老师,但是,如果不能从实践中学到东西,再多的实践也没有用。”
           ——《可怜的理查年鉴》

 

编程人员由于缺乏空间而在绞尽脑汁,但是他们往往能从自己的代码中挣脱出来,回顾、分析实际情况,仔细思考程序的数据,最终获得非常好的结果。尽管如此的进行着项目的各方面的实施,但是依旧不可忽视了一些管理方面的工作,每份文档的准备工作是集中考虑,并使各种讨论意见明朗化,如果不这样的话,往往会使项目处于无休止的混乱状态。

一个个项目就如前所述的在进行着,然而在项目中往往会出现一些问题,使得我们不得不改变最初的计划,所以就需要有变更计划系统,来减少变更引起的错误。

随着我们对软件工程的了解逐渐加深,所有的这些观点和想法都会引起各种的是与非,那么观点的支持与否又会是怎么个状况呢?经历了一阵阵的纷争后,我们仍然推断出,软件系统可能是人类创造中最错综复杂的事物(从不同类型的组成部分的数量的角度出发);还有,软件工程的焦油坑在将来很长一段时间内仍然会使人们举步维艰,无法自拔。

人类在进步,科技在发展,软件工程这个焦油坑也会在将来的很长一段时间内继续让人们举步维艰,无法自发。今天,软件工程的一些特殊问题依然存在,包括如何把一系列程序设计构建成系统;如何把程序或者系统设计构建成健壮的、经过测试的、文档化的、可支持的产品;如何维持对大量的复杂性的控制等等。

软件系统可能是人类创造中最错综复杂的事物,只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。

 

0 0