代码整洁的意义
最近读了《代码整洁之道》这本书，结合自己工作之后的项目经验，对代码整洁的重要性有了一些新的理解与感悟。首先我想先谈谈什么是整洁的代码，从字面意思上理解，整洁的代码，对于程序员来说非常的一目了然，简单、整洁，结构清晰，逻辑清楚。那么整洁的代码到底对一个项目的影响有多大？对于这个问题没有明确的数据支撑我给出答案，我只知道糟糕的代码对于一个项目的影响是与这个项目的规模呈正比的，我觉得大概可以算作是呈指数级的增长。
糟糕的代码是如何影响一个项目的？想象一下一份只有10行的充斥了i、j、k等变量的代码，读完并不是一件难事，或许逻辑并不那么清晰，但是好歹还是能够理解作者的意图，但是如果变成1000行呢？或许这个数量增长到100行的时候就已经让人想要放弃，随意的命名让人一头雾水，错综复杂的逻辑混在一起。如果还要在这样的代码上继续叠加逻辑，这几乎已经是不可完成的任务了。
从我自己的经验来说，我几乎记不住代码的具体实现是怎样的，尽管这是自己所写出来的代码，在每一次进行一个新的功能的开发时，我都需要去熟悉一下旧代码的实现逻辑，然后才能在此之上进行新功能的叠加。一份整洁的代码可以让阅读它的程序员快速的了解其实现逻辑，而不需要去了解具体的实现细节。如果一份代码需要程序员了解了所有的实现细节才能知道这份代码的作用，这势必意味着程序员需要花费大量的时间在阅读一份与工作关系并不大的代码。这样的代码越多，程序员花费的时间也就越多，这就是为什么我在文章开头说糟糕的代码对于一个项目的影响是与这个项目的规模呈指数级的增长。
所以糟糕的代码意味着难以维护，也意味着代码会慢慢的腐烂。所以在完成代码后花一些时间去保持代码的整洁反而是一种提升效率的手段。
怎样的代码才叫整洁的代码呢？对于这个问题我的理解是这样的，代码其实是一种语言，传递的是逻辑，如果这份代码可以像我们说话一样快速的将逻辑传递给读者，那么这样一份代码就是一份整洁的代码。
如何保持代码整洁
在明白了代码整洁的意义之后，如何保持代码整洁就是当前最紧迫的问题。私以为可以从几个点来进行考虑：
意识
首先便是要有保持代码整洁的意识，我很喜欢《代码整洁之道》中反复提到的一条童子军军规：让营地比你来时更干净。我认为有保持代码整洁的意识并不是说从写代码的时候就一直是整洁的，如果能够这样当然很好，但是这很难做到。在一开始编写代码的时候我们可以按照自己的思维顺序，个人习惯，甚至是只是为了追求想要可以工作的代码来写出一些较为混乱的代码，但是在结束当前的工作之前，在让自己的大脑脱离开之前，一定要整理代码，一定！
明天的你与今天的你总会有所不同，在再次进入工作之后，你或许会忘记很多的细节，而混乱的代码只会让思维更加的混乱。所以趁着你的思维还没有与你代码中巧妙的实现断线之前，整理你的代码，使代码尽可能的保持整洁。这便是我理解的童子军军规，你可以把营地搞得一团糟，但在你离开之前，一定要整理的更加干净。
代码规范
从代码规范入手是最基础也是最容易实现的保持代码整洁的方式。从几个方面来体现代码形式的整洁：足够好的命名，简单专注的函数，有意义的注释以及规范的代码格式。
一个好的命名可以帮助读者快速的理解变量以及函数的意义，所要实现的事情是什么。很多时候程序员宁愿花费更多的时间在变量名后加一些注释，也不愿意取一个简单易懂的名字，这实际是一件本末倒置的做法。一个函数、变量、类或者接口应该只通过命名就可以把它所做的事情传达给读者。所以不要害怕花费时间在思考命名上。
函数应该做一件事。做好这件事。只做这一件事。这句话摘选自函数这一章节。这句话很重要，我总会在函数中看到比函数名描述的更多的事情，有的时候我不得不花时间去阅读一些我不想了解的实现细节才能明白这个函数到底做了一件什么事。所以一个函数只做一件事，这是我认为很容易达到却又很容易被忽略的非常重要的事情。同时，函数还应该尽可能的短小，一个函数就算写的再清晰，如果一下子展示出100多行，那种庞大的行数也会让读者瞬间放弃。当然我相信，如果一个函数只专注于一件事，是不会产生过于庞大的代码量的。所以我认为，一个好的代码，应该像洋葱一样，可以一层一层的剥开，由粗略到细致。而不是像一个煮鸡蛋，完全一整个，让人无法一点一点的理解。
关于有意义的注释，我想我在前边两段的描述已经传达了一个信息，注释或许并不那么必要。如果编程语言足够有表现力，能够传递给读者所要表达的信息，注释其实就失去了意义。只在真正需要的地方写代码才是注释应该存在的意义。
好的代码格式，例如缩进的形式，可以有力的将层级结构传递给读者。我很讨厌没有缩进的代码，因为我根本记不住哪个｝是哪个｛的结束。有的时候，代码格式也是一种有力的信息。
质量保证
所谓质量保证，便是指可运行的自动化测试以及代码中的错误处理。测试与错误处理代码的整洁常常被人们所忽略，或者不止是整洁，连测试和错误处理本身都常常是会被忽略的事情。事实是，测试很好的保证了我们的代码质量，给了我们对代码修改的信心，这是另一个话题了，这里不做赘述。
错误处理是指在代码中程序员常常为了覆盖更多的情况、给出更多的错误信息而在代码的前后加try catch。设想一个极端的情况，每一行代码都被一个try catch包围，整个结构就已经一团糟了，再清晰的结构这个时候也已经被拆解的支离破碎。错误处理可以汇总到某一处集中处理，不要让随处添加异常处理破坏代码的逻辑。
除了异常处理，测试的整洁同样重要。测试与编程语言一样，也是一种向读者传递实现内容的一种方式，随着代码的衍进，测试也同样在进行着改变。所以测试代码的整洁和生产代码的整洁同样重要。一团糟糕的测试代码或许可以保证代码的质量，但当代码产生变动时，对于测试代码的改动或许比对生产代码的改动所花时间还要长，我们需要花费更大的代价去维护测试代码，这是一件得不偿失的事情。为了不让这类事情发生，需要对测试代码的整洁与生产代码的整洁给予同样的重视。同方法的职责单一原则一致，断言的内容也需要职责单一。每个断言应该只判断一件事。如此便可以更好的帮助我们快速精准的定位问题。
分层与结构
分层是指代码从整体上，由上至下的一种层级结构应该是清晰的，并且一层一层应该很好的区分开。与分层平级的便是结构，结构是指从业务逻辑上，各个模块应该很好的区别开。分层与结构的构建清晰与否极大的影响了整个项目的整洁程度。
从大的方面来说，系统的使用与构造需要明确的区分开，才不会将整个结构混杂在一起。与此同时，决定了系统的数据流走向便是决定了整个系统的层级划分，不同的层级也需要明确的区分开来。从小一些的方面来看，当创建一个类时，类的职责也需要明确，一个类应该只有一个职责。以上这些无论大的或是小的方面，之所以都需要明确划分职责，都是为了更好的实现内聚。
内聚代表着职责的专一，这是整洁的一个很重要准则。当我们实现内聚的时候，便会很自然的存在一个分类的界限。举个可能并不是很恰当的例子，学校里有很多学院，每个学院有很多专业，每个专业有很多班，每个班里有很多学生，这样层层递进，每一层也分的很清楚，每一层的结构也很清晰。如果换一种说法呢，还是学校，学校里有很多学生1、2、3，有专业1、2、3， 有学院1、2、3。这样的话，学校还是那个学校，分层完全没有体现，有的更糟糕的，还会把不同层级、不同结构混合在一起。
所以好的结构和层级的划分可以认为是一种逻辑上的整洁，是相对更加抽象的代码整洁，要求程序员自上而下地来进行代码的整洁。
如何整理代码
说完如何保持整洁的代码，如果遇到了一团混乱的代码，我们要如何将它整理的井井有条呢？首先我们要能够明确的找到混乱地方，当然我们不太可能一下子就找到所有，不用太着急，我们就要像剥洋葱一样一点一点的拆解代码，小幅的进行改动。每次改动，都有前边提到的测试来保证我们并没有破坏现有的功能。
当我们要整理一大坨代码的时候，我自己的经验是，如果不知道如何改动的时候，可以先从最基本的入手，看懂一段代码并且明确这是做了一件事之后，提取出来，取一个具有描述意义的名字。当将代码这样拆解成一个一个的方法之后，结构就清晰了很多。之后我们就会闻到很多的code smell，发现很多的重复。关于如何发现和解决code smell，可以参考《重构》这本书，这本书列举了很多的code smell，并且给出了很好的解决方案。
小幅的、迭代式的进行代码的改动可以帮助我们一点一点的梳理结构，朝着更清晰的方向行走。同时千万不要忘记每一次的改动都需要运行测试来保证我们做的是对的事情。