书名很有意思,说是人月神话,其实是想说人月没有神话。
沟通与培训是无法忽视的成本
当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助(图2.2)。无论多
少个母亲,孕育一个生命都需要十个月。由于调试、测试的次序特性,许多软件都具有这种
特征。
除非人与人之间的工作是相互独立的,否则培训是线性增加、人之间的沟通是指数级增加。
经验法则
- 1/3 计划
- 1/6 编码
- 1/4 构件测试和早期系统测试
- 1/4 系统测试,所有的构件已完成
这部分我的确问题很大,最开始差不多80%都在写代码,然后20%思考。现在是60%写,20%文档加思考,20%测试。还是不够。
概念一致性
- 欧洲绝大多数教堂,建设周期经常需要跨越几个世纪,而每一代接手的总想展示自己的价值与思考,所以你经常在教堂上看见风格的糅杂。
- 与之对应的是,法国城市兰斯(Reims)在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。设计的一致性和那些独到之处一样,同样让人们赞叹和喜悦。风格的一致和完整性来自8 代拥有自我约束和牺牲精神的建筑师们,他们每一个人牺牲了自己的一些创意,以获得纯粹的设计。
- 软件开发也要经历多次迭代,概念的一致性也是最重要的。
概念的完整性
- 使用这些工具是有代价的:软件外部描述的规模大小是计算机系统本身说明的十倍。用户会发现寻找一个特定功能是很容易的,但相应却有太多的选择,要记住太多的选项和格式。
- 只有当这些功能说明节约下来的时间,比用在学习、记忆和搜索手册上的时间要少时, 易用性才会得到提高。
- 由于目标是易用性,功能与理解上复杂程度的比值才是系统设计的最终测试标准。单 是功能本身或者易于使用都无法成为一个好的设计评判标准
全方面的预算
- 在开发程序的时候,不仅要考虑程序本身。
- 还需要考虑
- 运行程序所需要的门槛和各种成本
- 理解程序所耗费的时间和理解门槛
自上而下,逐步细化
- 顶层定义(高层抽象):
- 设计: “我们需要一个能住 4 个人的住宅,包含休息区、饮食区、卫浴区。”
- 核心: 此时绝不讨论用什么牌子的马桶、瓷砖贴多厚。一旦太早陷入细节,就会迷失在局部中。
- 第一轮精化(模块拆解):
- 设计: 将“饮食区”进一步分解为“厨房”和“餐厅”。定义它们之间的接口(例如:一道传菜口/门)。
- 核心: 只要接口定义清楚,厨房内部怎么装,和餐厅的装修可以独立并行进行。
- 逐层深入(算法与数据精化):
- 设计: 进到厨房内部,再决定水槽、燃气灶的排布,最后才精化到“水管用 20mm 还是 25mm PVC 管”。
减少bug的核心设计
顶层目标清晰 ──> 描述精确,减少理解偏差导致的 Bug
│
模块相互独立 ──> 修改 A 模块不会导致 B 模块莫名崩溃(避免系统级 Bug)
│
隐藏实现细节 ──> 骨架清晰,容易一眼看出结构上的设计缺陷
│
逐层可独立测试 ──> 不需要等所有代码写完,顶层逻辑用 Mock 假数据就能先测通
Loading...