《代码大全》是一个查漏补缺的过程

首先，我不觉得《代码大全》是一本必须要读的编程书籍，虽然它包含了编程中所可能遇到的方方面面的问题，但很多问题都是在一个流程规范的项目中所必须坚持的。如果您运气足够好，在看这本书前，里面很多需要遵守的规范，早已经内化于心了。不是说它不好，而是看您适不适合。

虽然书里面的很多东西在看之前，几乎都是很早都知道的，但我还是把它全部看完了。没有经历过就没有发言权，所以，我花了一个月的时间把整本书都过了一遍。首先肯定的一点是，这本书是极好的，如果是一个刚工作或还未工作时看到的，它对您的帮助是极大的。作者写这本书的目的在于缩小我们这个行业中一般的商业实践与大师级别人物及专家们之间的知识差距。许多强大的编程技术在编程领域被大众接受实现之前，都已经在学术论文和期刊之中尘封多年。譬如现今逐渐走进人们视野中的RESTful这个架构，在2000年时也只是Roy Fielding的博士论文而已。

有时，软件的构建和编码总是被人认为是相同的概念，然而并不是。从某种程度上来说，"编码"是将已经存在的设计机械化的翻译成计算机语言，而"构建"则更多是将一个软件从无到有的创造出来，需要更丰富的创造力和判断力。

构建活动是软件开发的主要组成部分和核心活动，一个理想的软件项目在进行构建之前，都要经过谨慎的需求分析和架构设计。一个理想的项目在构建完成之后，也要经历全面的、统计意义上受控制的系统测试。然而现实中并不存在那么完美的软件项目，往往跳过需求和设计阶段而直接进入构建环节。之后又由于有太多的错误要修正而又时间不够，测试环节也被抛到了一遍。但是，无论一个项目的计划有多忙、多糟糕，它都不可能扔下构建活动。因此，对构建活动进行改进，是改进软件开发过程的一种有效途径。

软件开发中，架构师吃掉需求，设计师吃掉架构，程序员，软件食物链的最后一环，消化掉设计。源代码是对软件的唯一精确描述，在很多项目中，程序猿可以得到的唯一文档就是源代码本身。需求和设计文档有时并不是最新的，但源代码总是最新的。如果一开始就被污染了，整个项目就会具有放射性，到处充满需要修补的缺陷。所以一个项目从最开始就决定了它能否成功。

软件开发是一项很复杂的工程，面对大型的项目，没有人能清楚地知道整个项目的细枝末节，一个小小的bug可能就要耗费你数小时甚至一整天的时间，而代码如果是别人写的，这个过程可能就会更加的漫长和痛苦。即便不是别人写的，你也很有可能不认识自己一个月前写过的代码。人的大脑是有限的，你不可能同时将五六个密切相关的类同时装进你的大脑并思考改动其中的一个会对其他几个都产生怎样的影响，如果这些类之间的关系是一团乱麻，那么改动其中任何一个都将是非常困难的。所以，管理复杂度便是软件开发过程中非常重要的一个环节，这也是《代码大全》这本书中讨论得最多的一个主题。

除了管理复杂度，这本书还讨论了一个主题，便是如何提高软件开发的质量。这里的质量包括几个方面，需求的质量（详细的说明），开发过程的质量（对需求变更的控制，增量集成），代码的质量（代码审察，结队编程），测试的质量（单元测试，覆盖率）等等。过早的对代码进行优化对项目的进度其实是有损害的，然而偏执的程序员总是对优化上瘾，并为此感到自豪，一个好的解决办法是，性能分析! 很多优化有时候是程序员想当然的，如果不能对优化前后进行客观的测量对比，那么就不要优化！

代码是写给人看的，关于代码可读性的争论一直存在，各个论坛里社区上总会有关于是否需要加注释的争论，甚至还会有用拼音命名是否合适的争论。但只有当自己真正去维护那些不可读或者很难读的代码的时候才会有最深刻的体会。

在同一个工程里，我见过好的代码和差的代码共存，自己维护过这样的代码就知道代码风格糟糕的时候是个什么感觉。糟糕的代码，一个类就有15000多行，其中一个函数1500多行，里面嵌套了多层的if-else和多个循环，根本理不清其中的代码逻辑；函数命名看似规范，但和函数实际完成的功能毫不沾边；好不容易有个注释，却发现这个注释是过时的甚至和代码逻辑相悖。好的代码，一个文件里只有一个类，类名和文件名一致，光看类名就知道这个类是做什么的，只看其中开放出来的接口就知道如何使用这个类，该传什么参数；每一个子函数和成员变量都有清晰的名字，不需要看代码也不需要注释就知道函数的功能，函数短小精悍。调试差的代码的时候简直就是噩梦，如果不重写或者重构，改一个bug能够引入5个新的bug，改个提示信息都得弄懂所有逻辑后才敢动手；易读的代码，虽然也可能出问题，但是定位起来相当简单，改起来相当放心，不会担心说改了后会影响别的功能。

确实，好代码就如好文章，要写出来很难；但至少我们可以逐步改进，至少我们可以让自己或别人读得不那么难受。不要随便用a,b,c和x,y,z给变量与函数命名，要仔细遵循命名规则，根据是成员变量还是局部变量添加不同的前缀，有的时候需要查询字典或者翻译工具才能给出一个长度合适，表述准确和便于理解的名字。

适当添加空行，利用IDE的缩进功能调整好缩进，代码该放在一行的就放在一行，该分行的就分行，适当添加空格，整个工程的代码采用同一风格，就能让代码看得更舒服些。不能将所有的代码行堆砌在一个函数里，也不能将所有的函数都堆砌在一个类里，不能随随便便的写代码，而需要深思熟虑。在写代码之前理清逻辑，按照逻辑写代码，给代码分段，那么很容易写出短小精悍内聚高的函数和类。

好好阅读他人的好代码和差代码，自然而然就会知道可读性的重要性，然后按照<<代码大全>>里面的方法逐步改进吧！