《人月神话》读书笔记

💡
书名很有意思,说是人月神话,其实是想说人月没有神话。
 

沟通与培训是无法忽视的成本

当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助(图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...