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