读《The Mythical Man-Month》有感

读《The Mythical Man-Month》有感

-- 陈凯飞

一读起这本书，我就开始被这本书的内容深深吸引了。一本三十五年前的书，现在读起来还是觉得眼前一亮。第一次接触Man-Month的概念，因为以前没有接触太多量化的软件工程的概念。也是第一次看到一个软件工程项目的靠谱的但是出乎意料的任务和时间分配的比例，test的时间分配居然高达1/2并且细化成component test and early system test 和system test, all components in hand。第一次意识到对于一个软件工程的项目，并不是人越多就越好，二是人太多只会让效率降低，因为communication的消耗是随着人数急剧增长的。

对于一个软件工程任务的分配，书中提出一个Surical Team的模型。该模型将组内人员分配成surgeon, copilot, administrator, editor, secretary, program clerk, toolsmith, tester, language lawyer, 并且给出了他们的交流模式（communication pattern）。我认为有一个细化的并且科学的分工对于一个软件工程的队伍是极其重要的，否则任务的分配将变得极其混乱。我们在这次的软件工程课程上就使用了经典的分工模式：PM，designer，programer和tester，各司其职，效果和效率都非常好。

对于程序架构师和程序编写者，书中提出他们需要概念上的统一，并且互相考虑。有一个我印象很深的就是，程序架构好之后，如果程序编写者要求对其中某些部分提出修改，架构师应该尽量修改。因为有些东西设计起来很容易，但是实现起来却需要大量的工作，而这些东西只有程序编写者才可以发现。所以我觉得架构师和程序员应该大体上分开工作，但是要保持交流，对整个程序的概念上保持一致。

在程序架构师设计的时候，一定要经常和程序员以及用户保持沟通，调整和改变自己的设计。另外，第一版的设计一般都很简单，但是当第一版的设计结束后，架构师一定要当心增加太多的内容在第二版的设计上。因为第二版的设计一旦出错，将对很大程度得影响后面的所有的工作。而增加很多内容则容易导致出错。所以第二版的设计一定加到好处，完成值得完成的功能就可以。

程序设计者写文档也有很多需要注意的。需要非常严谨的定义和描述，也不能过于枯燥无味。在做定义的时候，Formal definitions 和English prose只能使用其一。 同时他们需要定期和组内的人员开会，以更新设计的需求。

沟通的重要性在软件工程领域是不言而喻的。一个团队需要通过开会，文档等手段进行沟通，并且定期相互交换更新信息。如果沟通很好，每个人就只需要做好自己分内的拿手事。

 

总而言之，软件工程开发是一个很复杂也很有琢磨价值的东西，Brooks的经验历经几十年不衰，自然有他的原因。我想这本书里说阐述的，多半就是软件工程的本质的概况吧。