A-A+

人月神话 读书笔记

2018年12月29日 编程 暂无评论 阅读 121 次

最近听到一个度量软件复杂度的概念,叫decoupling level,想起来以前买过一本《人月神话》,这两天把它从书堆里面翻出来了。虽然书有300多页,不过里面大部分观点,我想从业者应该都认可,因此书里的新东西并不多。

Chapter 1: 焦油坑

职业的乐趣:工作的创造性;产品有价值;零件正常运转的魅力;持续学习的快乐。

职业的苦恼:追求完美;他人设定目标;寻找bug是痛苦的。

Chapter 2: 人月神话

在很多项目中,缺乏合理的进度安排是造成项目滞后的最主要的原因。

  • 对估算技术缺乏有效研究
  • 估算技术时常隐含地假设了人和月可以互换
  • 软件经理通常不会有耐心做估量
  • 对进度缺乏跟踪和监督
  • 当意识到进度偏移时,下意识反应是增加人力

乐观主义:程序员大都是乐观主义,但这种乐观主义理应受到慎重的分析。

人月估计量:适用于项目被拆解成很多个可以并行的小任务的场景,否则必须考虑沟通的工作量。新进来的人员也需要培训。

空泛的估量:客户给的时间很紧,但项目经理需要挺直腰杆。

Brooks法则:向进度落后的项目增加人手,只会使进度更加落后。?!

Chapter 3: 外科手术队伍

优秀程序员和较差程序员差别可能比想象中的还要大:2倍年薪带来的是10倍生产率和5倍编程速度。

需要沟通的人员数量严重影响着开发成本。

Mills的建议:架构师(或首席程序员)做分解,其他人做支持。

Chapter 4: 贵族专制、民主政治和系统设计

概念完整性:各个系统组件之间一系列连贯的设计思路。

功能与理解上的复杂度的比值才是系统设计的最终测试标准。:)

概念的完整性要求设计必须由一个人或者非常少数互有默契的人员来实现。但实现压力又要求很多人开发,所以设计和开发要想办法分开。

架构师时常需要专制。

Chapter 5: 画蛇添足

Chapter 6: 贯彻执行

使用形式化的语言,更精确。

周会和年会。

架构理解和解释最好沉淀成文字。

Chapter 7: 为什么巴比伦塔会失败

大型编程项目的组织架构

团队组织的目的是减少所需交流和合作的数量。所以要做人力划分和限定职责范围。

树状组织结构并不能用来描述交流沟通。

Chapter 8: 胸有成竹

Chapter 9: 削足适履

规模控制:需要设定每个部分的规模目标(设计容量),通常需要对可用方案有深刻理解。

Chapter 10: 提纲挈领

Chapter 11: 未雨绸缪

唯一不变的就是变化本身。

Chapter 12: 干将莫邪

工具的重要性。

Chapter 13: 整体与部分

系统各个部分的开发者都会做出一些假设,这些假设之间的不匹配是大多数致命和难以察觉的bug的主要来源。

1971 Niklaus Wirth提出了一个理念:系统开发分为架构设计、设计实现和物理编码,每个步骤都可以自上而下的方法实现,即先有个粗略大致的思路,再精细化。

系统集成测试的时间一般比预期的长。

Chapter 14: 祸起萧墙

里程碑:需要是可度量的,清晰的。

PERT图(就是一种数据结构教科书上讲的Ativity On Edge网络)。

Chapter 15: 另外一面

流程图是吹捧得最过分的一种文档。?!

Chapter 16: 没有银弹,软件工程中的根本问题和次要问题

作者认为,软件开发中困难的部分是规格说明、设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼真程度进行验证。

注:这句话写得着实有些抽象。我对这句话的理解是,根本的困难是把问题的本质是什么理清楚,也就是需要你动用洞察力的那些事情。第四章所描述的概念完整性,大概意思就是各个模块都在描述一个东西。读者有不一样的看法烦请指出。

如果这是事实,那么软件开发天生就没有银弹。考虑如下软件系统的几个内在特性:复杂度、一致性、可变性、不可预见性。

复杂度:计算机有大量的状态,大量不同的实体。Todo

一致性:面对复杂度,物理学家们坚信这些复杂度背后一定有一个简洁通用的理论,而程序员没有这种信念,因为这些复杂度往往是人造成的,而不是自然的规律。

以往解决次要困难的一些突破

更加易用的高级语言;分时[没理解...];统一编程环境;

银弹的希望

更好的高级语言;面向对象编程;人工智能;专家系统;"自动"编程;图形化编程;程序验证(这个目前看着是一个事倍功半的鸡肋思路)。

注:看着都不大有希望。作者确信将来也不会出现。

针对概念上的根本问题的颇具前途的方法

购买现成的软件(注:...);需求精炼和快速原型;增量开发;卓越的设计人员。

Chapter 17: 再论“没有银弹”

本章题记是 “生死有命,富贵在天”。如此悲壮的想法……

不过这本书随书附带了一本小册子,里面有大概十页内容讲述了本书作者Brook和另外一位大牛Cox关于到底有没有银弹的辩论。

Cox对有银弹很乐观:Cox认为这些软件开发碰到的困难都是正常的(注:乐观的人大概都是这么想?!);这些复杂度不是病因,而是症状,真正的病因是缺乏利益驱使来让更多公司编写和买卖各种粒度的组件。这把尚方宝剑不是技术上的,是软件思维的变化。

Chapter 18: 《人月神话》的观点:是与非?

Chapter 19:  20年后的《人月神话》

 

END

给我留言