《代码整洁之道》读书笔记

代码正常运行，为什么需要重构

对于项目管理者来说，代码的好坏似乎并不重要，相反，重构已有功能的代码伴随一定的成本和风险，通常管理层认为毫无意义；

对于开发者来说，谁都想写完美优雅的代码，高扩展高可靠的代码设计，高性能的代码实现……但是往往由于当时的技术水平和极少的开发时间，代码最终实现或许不尽人意。开发者往往瞟一眼糟糕设计的代码，决定视而不见。

但是随着混乱的增加，团队的生产力持续下降趋向于零，最终开发团队再也接不下新的需求，不得不重构系统。重构整个系统需要大量的人力和风险和时间，与最初只需要数小时优化的混乱形成鲜明对比。

我之前做过很多项目整体重构，确实苦不堪言，书作者书提到了一个项目重构的例子，本人感同身受，重构是必要的，重构就像是疫苗，打疫苗总比病发住院来的好。

怎么写出整洁的代码？

简单来说，你要保证代码的可读性，我们写代码不是写密码，不仅自己能够看懂，还要保证更多人能够轻易看懂，怀揣开源的思想，与队友分享自己的设计和思考，尽量做到优雅简洁。代码有的时候比言语更清晰，talk is cheap, show me your code.

首先是命名的可读性和规范性，尽量能顾名思义；
函数不要过于复杂，尽量短小，保证一个函数中做的事情在同一个抽象层面。
函数参数尽量精简，如有非要有函数有超过5个以上的入参，可以考虑提取新的函数分担，或者将一些参数封装为对象。
……

如何做到代码简洁？很少有人能够一开始就写出完美的代码，我最近听到一个理论，“先实现，再重构”，代码重构的时机可能是代码写完的第二天，也可能是下次做扩展需求，这取决于你代码的凌乱程度。

“要写整洁代码，先写肮脏代码，然后再清理它”

注释多一点好还是少一点好

书作者认为开发者应该尽量减少注释，用代码说话，注释不能美化糟糕的代码。在纯技术代码和基础架构的封装上我同意书作者的观点，但是实际的企业开发中，最常见的是业务代码，程序员更多的是将一些业务过程封装成对象和代码，如果我们不理解不清楚相关的需求，自然没办法看懂代码的用意。我认为代码的业务注释是加分项，尤其是接口函数的注释和SQL的注释以及抽象出业务对象的说明，代码的设计加上业务注释，可以体现出代码作者的需求思路。

其次，书作者认为与其增加注释的篇幅，还不如尽量做到命名规范，做到见名知意。但是我们必须考虑到我们和书作者有母语的差异，他们以英文为母语以英文命名变量或是函数，而我们不会用中文去命名函数和变量。仅仅依赖英文不能指望项目内部人员能够完全见名知意，中文注释是不可或缺的。

个人鄙见，不能寄望看你代码的人跟你有同样的技术高度，为了未来的清净，注释还是多多益善。

代码格式

我见过非常资深的coder但是在代码格式上不拘一格，草书一般的代码风格却在书写诗一般的代码内容，就像没人会在意爱因斯坦几天洗一次头，代码格式似乎是一个可以忽视的问题，甚至不算是问题。确实，如果公司或是项目对代码格式不做要求，那么你写成草书或是行书可能并不重要。

代码风格是一个coder的自我修养，代码是coder的名片，代码格式就是名片的排版，决定别人对你的第一印象。

错误处理

很多人习惯回避错误，似乎错误和优雅是反义词一样，但是没有错误处理的代码并不是优雅的代码。

可能程序运行时，百分之九十的数据都是正常数据，但是你必须要考虑那百分之十的错误数据过来应该怎么错误，直接抛出运行时异常是十分丑陋的，在主要逻辑之中花费大量的篇幅写异常处理也会降低代码逼格和可读性，我们需要想办法隔离异常处理，封装，抽象。

测试驱动开发

测试驱动开发，一个很旧又很新的理论。很旧是指它提出的时间很早，很多公司都在提倡，但是每个人对它的理解又不尽相同。很新是指很少有公司能够真正落地这个理论，它一直漂浮在我们前方。

之前的一家公司采用的标准的DevOps模式，开发承担开发测试和运维，TDD（Test-Driven Development）是我们的思想之一，在进入开发之前，我们需要先写完测试用例，先想清楚这个功能应该如何测试，再进入开发。

后面又进入另一家传统的瀑布式开发模式的公司，开发人员和测试人员是两个不同的团队，他们同样倡导TDD，但是并没有太多的落地措施，最后只要求写足够的单元测试就完事大吉。

TDD受制于公司，受制于体制，它并不能直接产生价值，也有很多公司并不倡导。但是它确实是一个先进的编程思想，我对比上面两家公司的代码交付质量就很能轻松证明这个理论的优越性。无论身处于哪个公司，coder都应该对自己代码的交付质量负责，而TDD正是能够提升我们代码质量的一个好的方式，在进入开发之前，先想想怎么测试它，需要测试哪些场景，从使用者的角度考虑问题。

高内聚低耦合

当我们要写一个系统，就像建造一个城市，不可能一开始就知道这个城市最终有多大，一般要创建一个小城市，然后保证它的高扩展性，后面逐步扩容重构。

怎么保证系统的高扩展性？答案是高内聚低耦合，但是要真正能做到这点确实不容易。我见过很多几千行代码的类，很多人习惯于像写文章一样写类甚至是函数，也许这个类的代码确实是高效，也许将整个功能封装到一个类可读性也挺高，但是当功能开始迭代，类中代码需要扩展的过程将十分痛苦，不出几次的迭代这个类必会经历重构。书作者列举了许多降低耦合度的方法，如工厂模式和依赖注入等思想，还提到java代理和并发编程，特别提到了Spring框架，里面有很多思想值得我们借鉴和思考。

重构

书作者在最后一张提到了Martin Flowler和他的著作《重构-改善既有代码的设计》，并在此列举了很多“代码的坏味道”，幸运的是我在读这本书之前拜读过了《重构》那本书，在此向各位coder推荐一下，绝对是程序员必读清单。

《重构》和这本书其实并不适合编程新人，正如书中所讲到的，“至少要先有代码”。

当coder经历过两三个项目之后，多多少少会遇到书中提到的问题，当你面对一盘乱麻的代码不知道怎么办的时候，才能理解书作者的思想，带着项目中的问题和个人思考看完这两本书，重构的思维基本上就在脑海中形成了。