人月神话》(三)"/>
杀不死的人狼——我读《人月神话》(三)
<<==上一节
=====
三、《人月神话》是预言了未来还是控制了未来? ===== 事实是:我们现在的很多工程知识,——无论是从书上看到的,还是从实践中体验到的——大多未曾脱离《人月神话》之所言。 我在开篇中说《人月神话》“是一本可怕的书”。然而我认为真正的可怕之处在于:如今只要论及工程(且不要让人认为是离经叛道),那么所讲述的一定是 Brooks 的这样的经验以及由此推出的观点,或者在不违背这些经验和观点上的一些具体的实作方法!我们全然不顾书中所言是现象,还是本质的推论,或者只是现象归结的一个(未必正确的)答案。尽管这些答案大多数时候都如同预期地出现在你的现实工程中:原文 | 基本含义 | 现实 |
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义,所以每条说明都必须重复所有的基本要素,所以所有文字都要相互一致。这往往使手册读起来枯燥乏味,但是精确比生动更加重要。(P46) | 重复所有基本要素,以便于单个的特性可能会被抽离出来进行讨论。 | RUP中的文档规范 |
将来的规格说明同时包括形式化和记叙性定义两种方式。(P46) | 用形式化来精确定义,用记叙性定义来补充说明。 | UML |
使用实现来作为一种定义的方式有一些优点……(但)可能更加过度地规定了外部功能。(P47) | 陈述实现并不是设计中规定外部功能的方法。 | UserCase不应指示或暗示实现的方法。 |
对软件系统的体系结构师而言,存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法,而非语义时,它特别有用……(P48) | 寻求一种描述功能而不涉及实现的方法,来协助架构师陈述它们的设计。 | Interface |
项目工作手册不是独立的一篇文档,它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分……(P54) | 项目工作手册应当有组织、有结构地陈述项目各个方面的细节。 | RUP中的文档规范 |
笨拙的文字归档工作确保了所有变更会被阅读,这正是工作手册要达到的目的。(P56) | 确保变更不会丢失。 | 需求管理系统或任务管理系统 |
是因为控制序更加复杂,所以需要更多的人员?或者因为它们被分派了过多的人员,所以要求有更多的模块?是因为复杂程度非常高,还是分配较多的人员,导致花费了更长的时间?没有人可以确定……(P64) | 随时关注生产率并控制它。 | 项目管理软件 |
但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金……(P75) | 以书面化的形式来制定计划,并且确保一些要素的准确性。 | 项目管理软件 |
试验性的系统必须被构建然后丢弃……(P77) | 做一个原型并准备好扔掉它。 | 原型过程 |
目标上的一些变化无可避免,事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免,而且设计策略和技术上的变化也不可避免……(P77) | 为变化而做出设计。 | 延长设计和迭代的周期。风险评估。 |
流程图是被吹捧得最过分的一种程序文档。事实上,很多程序甚至不需要流程图,很少有程序需要一页纸以上的流程图。 (P107) | 编程的结果产生流程图(以供讨论和分析),而不是对照着流程图进行编程。 | 代码回顾(review)与重构 |
试图把信息放在不同的文件中,并努力维持它们之间的同步,是一种非常费力不讨好的事情……(P108) | 文档应该与代码同步。 | 代码文档化。 |
没有银弹(P114) | 所有曾被认为是银弹的东西都被无情地否定了。 |
- 他做出了正确的判断;
- 你主观地跟从了他对未来的设定。
原Brooks所述相同的例子 | 不同的例子 | 注 |
UML | AP:可以工作的软件重于求全责备的文档。 | 注1 |
Interface | ||
RUP | ||
需求管理系统/任务系统 | 代码走查,结对编程。 AP :人和交互重于过程和工具。 AP :客户合作重于合同谈判。 | |
项目管理软件 | ||
质量管理/评估和工程化测量 | ||
User Case要尽可能避免指示或暗示实现的方法 | 测试驱动从一开始就规定表现是什么,以及如何确认它。 | |
原型过程 | 迭代过程 | 注2 |
延长设计和迭代的周期 | 缩短周期使得变化来不及发生。 | |
编程的结果产生流程图(以供讨论和分析),而不是对照着流程图进行编程。 | 不强调具体代码实现方法的、设计过程中的流程图例。例如时序图。 | 注3 |
代码文档化。 | 通过工具来使代码与文档同步维护。 | |
所有曾被认为是银弹的东西都无情地否定了。 | 我们还是有成功的工程实践的。 |
- 目标的本质:是大型工程,是系统项目,而不是程序
- 个体的本质:是私利性的
- Brooks 认为构建“独立小型程序”与“编程系统产品”是不同的问题。
- Brooks的经验源自对IBM 360等大型项目的实践与分析;
- Brooks所述的工程是要得到编程系统产品;
- Brooks认为编程系统产品的工作量可能是独立小型程序的9倍(在实现大致相同功能的情况下)。
下一节==>>
更多推荐
杀不死的人狼——我读《人月神话》(三)
发布评论