【原创】关于软件开发的一些名言和思考 - 读《告别失控》有感_告别失控-软件开发管理团队必读读后感-优快云博客

本书摘录了《告别失控》中关于编码规范与项目管理的精华观点，包括将未来的代码维护者视为潜在威胁以确保代码质量，认识并应对项目时间估算的不确定性，定义完成标准的重要性，以及项目初期正确规划的必要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

《告别失控》这本书是听《极客时间》的时候哪位大神（可能是左耳朵耗子）推荐的，最近正在读这本书。

在本文中布鲁斯同学挑选了7条个人喜欢的名言，大言不惭地评论一番。

Martin Golding (Or John F. Woods)

始终应当把将来负责维护你代码的人想象成一个知道你住在哪里的狂暴的精神病患者，以此来敦促自己小心翼翼地编码。

为了人身安全，我决心把这一句话当做Rule 1 - 第一条也是最重要的一条守则。攻城狮同学们，为了不被祭天，为了不暴尸街头，写代码一定要三思而后提交啊。

候世达（Douglas Hofstadter）定律

做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。

这个定律布鲁斯同学深有体会。每个sprint无论怎么修订预期，怎么加上多的缓冲时间也没用。不仅仅整个sprint是这样，单个的user story也是这样。预估两天能够完成的，四天弄完算不错了。如果一个任务预估需要5天，那就呵呵了，最后一定不是完成而是“被完成”。关于“完成”的定义和理解，请看下面。

Chris Sims

要给“完成”下一个定义。若你的团队没有对“完成”的定义达成共识，自然很难去为工作的圆满完成而欢欣鼓舞。当团队成员说他们“完成”了他们负责的那部分特性时，究竟是意味着：

- 在他们的机器上可以执行？

- 已检入到源代码管理系统中？

- 进行过完整的验收测试？

- 所有测试都通过了？

- 文档编写完成了？

- 经过同伴审查了？

以前我总觉得程序员的素质都很高，关于“definition of done”的主体部分应该是共识：例如代码已经实现了并且添加了对应的单元测试，已经check in到代码库等等。然而，情况并不是这样的，现实中不乐观。要达成共识，一定是要明确地提出来，并且黑纸白字写下来。

有一半的项目都不是中途出问题，而是一开始就错了。因此一定要保证头6个星期做得正确。

正如“好的开始是成功的一半”这句谚语说的，开始阶段非常重要。项目的开始阶段，大多工作就是“搭架子”，“定规矩”。没有规矩不成方圆，而架子底座如果歪了，后期要纠正就非常困难了。引申一点，说说“演进型原型”和“抛弃型原型”。以前我总觉得讲一个系统原型抛弃掉，真的蛮可惜。虽然说重新做的工程量不是特别大，但是总有些浪费。但是，如果采用”演进型原型“常常会造成严重的问题，就是团队成员，尤其是新的成员，可能会误以为项目的要求不高：因为他们看到原型项目里边的代码质量可能不高，也没用什么严肃的测试，所以心理上的就有一种“锚定”效应。现在我是“抛弃型原型”的粉丝，每次的原型都丢掉重新开一个新的代码库重头开始设计。

Ray Ozzie, Lotus Notes的创造者，Groove公司的创立者，微软公司的CTO

复杂性是个要命的东西。它会榨取开发者的生命力，会使产品难于计划、构建和测试，会带来安全性上的挑战，还会使最终用户和管理员垂头丧气。

作为程序员，我们面对的最大困难不是掌握编程语言的语法语义，不是熟悉工具和框架等等，最有挑战性的事情就是管理复杂性。项目的规模和复杂程度不是线线关系。根据业界的经验，问题的复杂性每增加10%，软件解决方案的复杂性就会相应地增加100%。(Robert L. Glass) 一些项目并不是开始就变坏的，而是随着需求越来越多，“特例‘越来越猖狂，代码的复杂度终于超过团队能够管理的范围。