胸有成竹
这一章是介绍对变成效率的量化的，种种量化方法将程序员的生产效率细化到指令/年(不好意思，他们当年是写汇编的，高级语言那个时候还很少)。我觉得这个实际上意义不大， 但是仍然是一个有趣的参考，最终的结论是工作量=常数*指令数量^1.5，也就是说工作时长跟代码数量的指数关系而不是线性关系，随着代码数量的增长，工作时长是指数级上升的。
削足适履
这一章主要是讲程序大小的，包括代码大小和内存占用的大小。代码大小现在应该已经不是软件开发的重要考量了吧？但是这一问题在如今的 App 开发中应该也有，虽然很多公司毫不在乎占用用户几百 M 的存储空间……当然在前端还存在另外一个问题，即过大的代码包会耗费过多的流量，尤其是在早年的移动端开发中，那时候流量很金贵，现在这样的顾虑逐渐变少了，但是一直都存在的顾虑是代码的加载速度，当然这一问题也可以通过分包懒加载来解决了。总而言之，当年的那些经验在前端领域适用的已经不多了，但是在客户端领域可能仍然适用。
内存当然始终是一个问题，但是应该主要考虑不要发生内存泄露的问题，自动的垃圾收集可以解决大部分问题了吧？计算机硬件的进步真的极大地降低了软件工程的难度。
提纲挈领
这一章主要是介绍文档的重要性，对于项目经理来说，文档是很重要的，它包含了项目目标、产品的技术说明、时间、资金预算、工作空间的分配和人员的组织结构。文档的重要性在于首先，明确的书面记录会让分歧更明朗，使混沌的状态变得清晰、明确；其次，文档降低了沟通的负担；最后，文档便于项目经理跟踪项目的进度状态。
未雨绸缪
这对于程序员来说可能是一个十分不幸的消息：系统必然会面对各种变化，你开发的软件必然会在修修补补中变得面目全非，最初的设计必须在各种妥协中打上各种丑陋的补丁。无论是多么良好设计的系统，都会走向混乱，区别只是这个过程的快慢而已。因此，好的设计会让这个过程尽可能地慢，尽可能地不那么痛苦，我们能做的就是眼光尽量放长远，让我们的代码尽可能地具有高可扩展性并且易于维护。而且，在面对不得不进行的重构时，做好心理准备。
干将莫邪
这一章一言以蔽之：磨刀不误砍柴工。好的开发工具和开发环境可以极大地提高开发效率，当然，作者在这一章中介绍具体方法、工具、语言等已经不适用于我们这个时代了。
整体部分
我们将整体的项目分割成更小的部分来开发，但是最终我们仍然需要将这各个部分合并成一个整体对外提供服务，这就带来了新的问题：各个部分可能独立工作良好，但是当合并成整体时反而导致了新的系统级的 bug。这就要求我们在设计系统结构时精心设计，减少各个部分间的耦合，各个模块的独立性越高，系统级的 bug 的可能性就越低。此外作者在本章还介绍了一些测试的方法，这部分我不太了解，而且测试的方法、流程可能也已经过时了，毕竟我们已经有了更好、更方便的版本控制工具和测试流程，但是其中一些理念还是有意义的，如重构过的模块在合进整体的时候仍然需要对系统整体进行测试，而不是仅仅测试重构过的模块。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· 阿里最新开源QwQ-32B，效果媲美deepseek-r1满血版，部署成本又又又降低了！
· AI编程工具终极对决：字节Trae VS Cursor，谁才是开发者新宠？
· 开源Multi-agent AI智能体框架aevatar.ai，欢迎大家贡献代码
· Manus重磅发布：全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后，我竟然真的恢复了删除的微信聊天记录！