一个神奇的故事

一个程序员来到一个新的地方，这个地方的产品们人问他，你能做xxx吗？程序员大喊：“当然可以！！” 他才思泉涌，他披荆斩棘，很快他在几天内轻松完成了任务。一年之后，这个地方的产品们又找到了这位程序员，希望他把xxx再做一遍，结果得到的回答则是：“这也许需要1个月。”人们大惊问他为什么，“因为我们的系统太乱了，每改动一个地方，就要把全部内容重新做一遍。”

为什么会发生这种事？因为一个团队在初期或许有着绝妙的设计，但是不可免的在追求速度的时候会有一丢丢不够优雅的设计掺杂在里面，等到了将来再需要动这部分不优雅的设计时，它已经变成了一坨坨不优雅的东西了。

这时如果尝试加人会怎么样呢？答案是开发速度将以指数级下降。因为培养新人的永远不可能是老人，而是老代码。真实的情况，就是某个新人被扔到一团火中，对着代码大喊原来如此，那么这群新人就会变成汽油，这团火也会随着项目越大烧的越旺。

因此，清理你的代码！

理论上，你用多长时间写代码，你就应该用多长时间去整理它，当然这在现实生产中几乎完全不可能，因此适当的代码行为规范，就应该变成写代码过程中不可绕过得一步。极端的说，如果你的代码给我可以运行，但我无法简单的理解它，那这段代码就是一段失败的代码。反过来说，即便你的代码给我时不能运行，但我可以很清楚的理解它是如何运行的，那这段代码也是一段成功的代码。

函数

一、短小

函数得第一要义是短小，第二要义也是短小，函数的作用就应该是只用寥寥数语，把你引导至下一个函数里。

二、只做一件事

函数应该做一件事；做好一件事；只做一件事

三、保持一个函数内相同的抽象等级

这点也是保障前两点的一个要诀，同时可以带来一个额外的好处：面向对象。

四、尽量不要去用switch语句

switch语句非常特殊，它天生就是个大家伙,如下：

以上代码有一些明显的问题：

• 太长了，如果加东西它还会更长。

• 明显做了很多事。

• 违反了单一权责原则。

• 违反开闭原则。

简单来说，解决起来只需要用到抽象工厂，如下：

这里其实用到了接口隔离原则，详情可以阅读《架构整洁之道》。

五、使用描述性名称

要真真切切知道你的方法在干什么，一般来说一个方法至少应该是一个动作的描述。

六、注意函数参数

最理想是零参数，其次是单一或二，如果大于等于三的话可能就要考虑一下了，是不是把这些参数作为一个数据结构管理起来或许更好一些？

七、或许不要用bool作为参数

这只是一个软规则，如果我们用bool变量作为参数了，那大概率我们就会用到这个变量来进行一个分支方法，那为什么我们不把这些分支分别做一个方法来使用呢。

八、尝试使用try-catch来处理你的问题

毕竟try和catch已经是天然的两段代码块，比起if  else地狱来说，把log写在catch里要优雅的多。

注释

别给糟糕的代码加注释了——重新写吧。

——Brian W.Kernighan & P.J.Plaugher

注释本身并不是一个"纯粹的好"，更多时候它是一种"必要的恶"，毕竟你的代码越好，需要的注释便越少，甚至根本不需要。

一、还是尽可能用程序来写注释

就像上边说的一样，在写注释之前，花几秒想想是不是有更好的方法来拯救这团代码。

二、好注释

略。好的注释自然赏心悦目，这部分暂时不用在这里讨论。

三、不要喃喃自语

写就写清楚，不要把注释变成一个谜团

四、不要多余的注释

如果注释过于详细，还不如写伪代码。

五、不要留下注释掉的代码

相信我，其他人正常情况下是不敢删除他们的。

格式

一、书写上的格式

聪明的程序员会使用聪明的IDE，可能是自己的圈级不够高，至少在我附近的人能把IDE用的6的真是少之又少，比如这里提到的智能替写一些。

二、遵守一套团队规则

人多就要有规矩。

对象与数据结构

一、数据抽象

先看两组代码

二者最大的区别就是，上方直接操纵了代码里的数据本体，而下边则至少通过一次原子操作来做这些事情。我们不愿意暴露数据细节，更愿意以抽象形态来表述数据。

二、得莫忒尔定律（最少知识原则）

本意为模块不应了解它所操作对象得内部情形。及方法不应该调用由任何函数返回的对象的方法。

三、使用数据传送对象（DTO）

把数据放到类里进行传输。

类

一、单一权责原则

类或者模块应该有且只要一条加以修改得理由。这样最终会造成一个结果，即一个类会被拆成非常小得部分，但是这才是一个好的系统应该做到的，每一个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。

二、内聚

一个类应该只有少量得实体变量，类中得每个方法都应该操作一个或者多个这种变量,如果一个类中的每个变量都被每个方法所使用，则该类具有最大得内聚性。

系统

就像管理一个城市一样，你一个Manager是没办法管理全部细节得，这就要求我们在整体系统之上，也做到一定的梳理，让其变得非常整洁。

将构造和使用分开

• 工厂模式

• 依赖注入（DI）

代码是写给人看的，不是写给机器看的，只是顺便计算机可以执行而已。

——Harold Abelson