读完这本书一共花了接近一个月的时间，一共900多页，但无论如何，我觉得本书都值得所有一线工程师，技术带人头，或者是项目经理甚至是产品经理来读一读，如果实在对某些专业部分不太感兴趣，那么也值得挑选一些和自己工作有交集的部分仔细阅读。
读完这本书是否能给自己的工作带来巨大好处这个我觉得因人而异，因为不同的人的积累是不一样的，如果让我3年前来读这本书，我肯定不会有现在这么大的共鸣和收获，因为当你没有遇到过一些很让人蛋疼的代码和实际经验的时候，你很难理解作者写这些东西的意图，如果是容易迷信“大师”的人，很可能会去把作者的文字全当成某种信条来执行，如果是稍有自负的人，会觉得作者小题大做，或者是在吹嘘一些不切实际的理论。对我个人来说，当我在读本书中一些内容的时候，我不禁在心里大笑，哈哈，我终于能对一些烂代码喷得有理有据了，赞！
我就是这么贱，有时候管不住自己喜欢喷烂代码，在以前我能闻出某些烂代码的气味，但我说不出为什么，都是凭自己的经验和感觉在做判断，只是觉得这个代码写的不好，但你要我出个具体的出来，我还真不知道从哪说起，但现在有了《代码大全》里面某些对好代码的理论支持，我可以更加自信地对某些烂代码说，“你这个就是这么烂！因为你暴露了太多实现细节，因为你的函数命名有问题，因为你的错误处理方式不对，因为你的参数列表一团糟等等等等”。
当然光喷喷代码是没有意义的，如果不能对实际工作有任何好处，还不如上上微博看看程序员们撕逼过瘾，何必抱着一本砖头折磨自己。下面当做对本书的回顾，讲讲自己的收获和所见到的自己身边的程序员常犯的错误：
1.封装和信息隐藏
我觉得大多数程序员对代码的复用比较重视，我自己也是。但我自己常常把封装或者提取子程序当成复用代码的手段，对于它在信息隐藏方面的作用的理解不够深刻，所以有时候会把两者的手段和目的混淆，导致搞出一些不伦不类的设计和代码。
2.自上而下还是自下而上
对于简单的程序，这两种方法都实用，但是对于比较复杂的系统或者模块，两者相结合绝对的最好的办法，因为无论是用其中哪一种，复杂系统都很有可能导致在顶层和底层遇到问题，当遇到问题以后再进行相应修改的代价就太大了。
3.找出容易改变的区域
结合封装进行实践，会对代码的稳定性有非常大的帮助，因为如果能提前预见到那些地方可能改变，那么你就可以利用抽象和封装把这些代码隔离起来，当变化来临的时候，完全不虚。
4.类和子程序的设计
很多人一说设计，就会去说一些很高大上的东西，什么mvc，什么设计模式的，但在我看来，如果在基本的类和子程序的设计上都不爱花心思，这些东西都是虚的。有的代码一看就能感觉出来根本没有认真去思考，封装怎么做，参数怎么设计，怎么使用方便，怎么做到复用，怎么面对可能的变化，函数名称是否和做的事符合等等，这些事看起来很小，但却是工程师在日常工作中总在碰到的事情，如果这些都做不好，我不觉得能做好更上层的设计。
5.防御式编程
对于数据和参数，时刻以最怀疑的眼光来看待，能让你写出非常健壮的代码。
6.发现缺陷的方式
发现代码缺陷最好的方式就是直接读源代码，我觉得很多人包括我以前，都很难做到这一点，因为读源代码就意味着你必须在大脑中以计算机的方式来逐行运行你的代码来发现问题所在，但程序员普遍都很讨厌直接读代码，对于某些没办法找出必现路径的缺陷，这真的是最好的方式，总的来说效率是最高的。
7.迷信式编程
我不太清楚其他人编程的方式，但在我刚开始学习编程以后的很长一段时间里，我都会采用这种方式，不得不说这是一种很有害的方式，它会让你形成一种很不好的习惯。后来我努力改正了自己，尽量不再使用迷信式编程方式，我发现当你越来越不再依赖运行来检查错误的时候，你的思维方式也会跟着变化，你会以一种计算机的思维来看待你的程序，你能在编写的时候就写出非常完美的代码，这其实大大提高了整体的编码效率。
8.偷懒
我看到过很多勤快的工程师，一遍一遍去做很无聊的事情，大好时光都浪费了。