《代码整洁之道》，最近一次被推荐，是去年的朋友圈，一位只见过一次的程序员老乡发的，他当时推荐两本书，一本《重构》，一本《代码整洁之道》。《重构》已经在萌哥要求下看过，所以当时，只将《代码整洁之道》加入书架，去年12月开始断断续续于手机上阅读，到上个月读完，累计花费7个半小时。
作者在前言中将本书结构、内容做了很好的概括，我摘抄于此：
本书大致可分为3个部分。前几章介绍编写整洁代码的原则、模式和实践。这部分有相当多的示例代码，读起来颇具挑战性。读完这几章，就为阅读第2部分做好了准备。如果你就此止步，只能祝你好运啦！
第2部分最需要花工夫。这部分包括几个复杂性不断增加的案例研究。每个案例都清理一些代码——把有问题的代码转化为问题少一些的代码。这部分极为详细。你的思维要在讲解和代码段之间跳来跳去。你得分析和理解那些代码，琢磨每次修改的来龙去脉。
你付出的劳动将在第3部分得到回报。这部分只有一章，列出从上述案例研究中得到的启示和灵感。在遍览和清理案例中的代码时，我们把每个操作理由记录为一种启示或灵感。我们尝试去理解自己对阅读和修改代码的反应，尽力了解为什么会有这样的感受、为什么会如此行事。结果得到了一套描述在编写、阅读、清理代码时思维方式的知识库。
读本书，很多句子会让我在心中发出“对的对的”、“是这样的，是这样的”、“作者厉害”、“好的好的”、“我改我改”这样简单的顺从回答，我选取几句摘抄于此处：
你该明白了。读与写花费时间的比例超过10:1。写新代码时，我们一直在读旧代码。既然比例如此之高，我们就想让读的过程变得轻松，即便那会使得编写过程更难。
聪明程序员和专业程序员之间的区别在于，专业程序员了解，明确是王道。专业程序员善用其能，编写其他人能理解的代码。
函数的第一规则是要短小。第二条规则是还要更短小。
过去30年以来，以下建议以不同形式一再出现：函数应该做一件事。做好这件事。只做这一件事。
这样的句子，还有很多，在这些总结性句子之后，会有对应的示例。我认为读本书的正确方式，是将本书的纸质版置于办公桌前，在某些犹豫时刻，拿出来翻一翻，常读常新。
读本书的同时，我正在搭建一个小项目，每读到一个点，就会在脑子中梳理一遍自己的代码。有些是对的，有些不够清晰，有些是应该改进的，梳理之后，看代码，再做些许调整。读书当时，影响最深。
读完本书，我是多了一种理念的：“当我看出代码能优化一下，能重构一下，能表达更清晰些，我会在当时尽量做一下。”这里在现在的我是“尽量”，书中是推荐立马改掉的。立马慢慢的、稳健的一点点重构；晚点做，则会变成“勒布朗法则”的另一个佐证。（勒布朗法则——Later equals never，稍后等于永不。）
人都是会犯错的。如果靠着经验或者某个大家都需要遵守的约定而让代码运行下去，迟早有一天会踩坑。之前租房处去公司路上有一个坑，我一直注意着它，有次下班太晚骑车路过，掉进坑里。这个坑，我已经避过它不下百次。
读完本书，改变最深的是对“注释”的看法——以后，能不写注释就尽量不写注释；无用但可能再用的代码，不注释直接删掉，交由Git管理。注释代码这个事情，与生活中的习惯很有关联，我不会想扔掉那些鸡肋的、可能再也用不到的东西。
读完本书，再去看各路（主要是工作中会用到的组件库）源码，绝大部分函数是真的能够通过名字便知道它作用的。使用人数越多的代码，越明显。
本书，是作者拥有几十年编码经验之后整理出来的。我没有碰到过、不甚了解、不够熟悉的场景，只能模糊理解作者的观点。这让我知道自己的短板，比如测试驱动开发，比如线程、进程，比如异常处理。
自子程序发明以来，软件开发领域的所有创新都是在不断尝试从源代码中消灭重复。
Don't repeat yourself！
