软件构建随想 —— 《代码大全》读后感

---

前言

本文关注的是《代码大全》中介绍的最重要的两个概念：管理复杂度与程序可读性，并未记录书中详尽介绍的各个层面构建方法。

软件的首要技术使命：管理复杂度

这是整本书反复强调，贯穿始终，让我印象最深的观念之一。

软件开发的复杂性

次要性困难(accidental)与本质性(essential)困难

次要性困难指与目前的软件开发环境有关的困难。软件领域的发展解决了早期存在的很多次要性困难。高级语言的出现带来了可靠性、简洁性以及抽象层面上的突破；分时操作系统保证了软件开发的及时性；集成开发环境进一步提高了开发人员的效率。

但是，软件开发中固有的困难即本质性困难依然存在。而这些困难的解决将会缓慢而痛苦，
软件开发总是非常困难的，天生就没有银弹。究其原因，是因为从本质上说软件开发就是不断地区发掘错综复杂、相互连接的整套现实概念的所有细节。人们想要清楚地认识现实世界到底如何运作仍有很多挑战，软件开发必须面对复杂、无序的现实世界，甚至其中很多是随心所欲、毫无规则可言的，因为它们来自若干必须遵循的认为惯例和系统等等。无论工具如何发展，总是需要一类人来充当计算机硬件和现实世界之间的桥梁，这样的工作总是非常具有挑战性的。

智力限制

尽管谁都希望自如地应对计算机问题，但没有人的大脑真正有能力跨越从机器层面到应用程序层面超过9个数量级的细节，没有谁的大脑能容得下一个现代的计算机程序。
神奇的数字7。研究表明，人们在做其他事情时能记住的离散项目的个数是7(+-2)。也许不会如此精确，根据个人也会有差别，但这项”7”的原则在设计类、接口甚至子程序时提供了一个很好的暗示：减少同一个抽象层面的离散项目个数，降低程序的复杂度。

管理复杂度

正因为软件开发的复杂性，以及我们智力的固有限制，才使得管理复杂度成为软件开发中最重要的技术话题。作为软件开发人员，我们不应该试着在同一时间把整个程序都塞进自己的大脑，而应该试着以某种方式去组织程序，分而治之，以便能够在一个时刻专注与特定的部分，尽量减少在任一时间所要考虑的程序量。

软件设计与构建的主要目标就是征服复杂性，许多编程实践背后的动机正是为了降低程序的复杂度。

分治(Divide and Conquer)

分治的思想有助于我们更好的管理复杂性，它几乎可以延伸到软件开发的各个层面。例如把整个系统分解为多个子系统；保持类、接口的独立性以便我们安全的忽略其实现细节；创建子程序以屏蔽程序中的某些细节；从伪代码开始编程以从更高的抽象层次上编写代码；甚至缩短子程序中的变量跨度等等。

规范与约定

规范是一套用来管理复杂度的工具。我们可以用规范和约定来使大脑从记忆不同代码段的随意性、偶然性差异中解脱出来，专注于更具挑战性的编码问题。

迭代

由于现实世界的复杂性，软件开发过程需要在不断的迭代过程中深化对问题的理解，从而更好的描述、解决问题。
反复尝试，通常会产生更好的结果。迭代的设计可以获得更好的问题描述模型，迭代的编码可以深化对问题的理解并产生逻辑更加清晰的代码。

为人写程序，而不是机器

代码可读性也是这本书强调的重点之一。
软件开发是人的活动，就像我们平时用文字传播交流一样，在软件开发的各个层面也需要文档来使程序员包括客户相互理解，而最基础的最根本的”文字”便是程序员的代码。

程序员在整个项目生命周期里会把更多的时间花在阅读代码而不是编写代码之上，代码复审、修改、扩展、重用等等这些活动都依赖与可读的代码。保证代码的良好可读性对程序的可理解性、错误率改善、调试、可修改性、总的开发时间以及外在的程序质量等是非常有帮助的。

所以要像写博客、写文章一样写代码，时刻考虑读者的感受。
高可读性的代码包括，良好的程序结构、直率易懂的方法、有意义的变量名和子程序名、具名常量、清晰的布局，以及最低复杂度的控制流及数据结构。

总结

以前碰到一些棘手的问题或是艰深的算法，经常会有脑力枯竭的感觉，甚至一度对自己丧失信心。有时会想我在这个天才云集的行业里究竟能走多远？
读过这本神书以后知道，天才只是极少数，软件开发需要的更多是科学的方法与脚踏实地的努力。高智商与优秀的程序员之间并无太密切的联系，认识到自身的缺陷并时刻保持谦卑才是Complete Code之道。

后记

这篇文章自读过一遍《代码大全》之后一直放了很久，总是想着写得更详细，更令人信服一点，毕竟这本书对我影响如此之大，三言两语似乎无法表达我当时的惊喜与震撼，也无法让更多的人受益于此。
但遗憾的是沉淀了这么多天再写，还是不知从何下笔。仅仅将书中的概念剥离抽取出来并不能让人有心领神会之感，甚至会显得过于抽象松散，而书中一次次让我感动的也是详细列举的方方面面的编程细节，我绝不希望此文让读者对这本书失去兴趣，毕竟为了让我今后的程序员生活更加和谐我必须寻找同样读过此书的同事。

今天偶然又和同学聊到这本书，发现这书在他眼里只不过是一本太厚太抽象而且对找工作没有什么帮助的书。我当即怒火中烧想把他扼杀在作为程序员的萌芽之中，不过我当初何尝没有这样的想法？“现在看这种书没用，还是等工作以后有时间再看。”
这纯属扯淡。要想成为优秀的程序员，必须从一开始就培养优秀的编程习惯。就像软件开发必须要从正确的设计方案开始一样，错误的设计方案将会让你在整个开发、调试以及维护阶段痛不欲生，而修正设计错误通常需要付出巨大的代价。优秀的编程习惯与对软件开发过程的正确认识更是处在软件开发的源头位置，工作以后再去改善自己的编程习惯，就像先胡乱拼凑代码然后再反复修改调试一样，都是悲剧的开始。

“这是一本非常非常好的书！”我努力的在这句话之外增加更有说服力的观点。
管理复杂度是整本书的精髓，太厚是因为它整理、引用了大量的研究与统计资料，非常详尽的描述了在程序构建的各个层面可能出现的问题，以及管理复杂度的方法，”太厚”通常会成为阅读某技术书籍的一个很好的原因——程序员通常不善于大篇幅闲扯；某些概念太抽象是为了让你从更高的层面去把握整个软件开发活动，你会从整本书的各个细节之处回忆起这些看似抽象的概念，它们将成为你的人生信条之一；对找工作。。。这不得不说是招聘方与应聘方的一种无奈，毕竟要想在短短几轮面试之中，决定一个人是否满足要求是一件很难而且变数很大的事，通常招聘方都会选择考量一些更通用的“硬性”指标如算法的掌握、某领域的开发经验、对语言的了解程度等，而程序员真正的生产效率与代码质量是很难定性衡量的，我只能说这本书会让你有卓越的程序员修养，它会成为你迈向优秀程序员的非常重要的一步。

Stay hungry, stay foolish.
保持好奇，保持谦卑。

参考资料

《代码大全》
《人月神话》