书写可维护代码的重要性

《代码整洁之道》、《实现模式》、《设计模式》、《重构》、《重构和模式》这些书中，都指出书写可维护代码是很重要的。想必每位开发者都能说出几条原因吧，这里我也梳理一下自己的逻辑。

什么是好的代码？概括地说就两条：第一，能实现需求，第二，可维护性高。

1.1 能实现需求是第一要满足的

程序员工作的本质，就是代码交付。这是我们工作的基本，若代码不能实现需求，肯定不是好的代码。这一点是无需置疑的，任何其他方面的工作，都为它让路。因此有很多公司，把这点作为绩效考核的唯一要求。

1.2 书写可维护性代码是老鸟和新手的本质区别

怎么衡量自己成长了呢？有一个看似开玩笑的方法，就是当你去看自己以前写的代码，如果你觉得垃圾时，此时表明你进步了。

什么样的代码是可维护性高的代码呢？《代码整洁之道》给出的观点是，代码可维护性与代码的整洁度成正比。当然也给出了整洁的代码是什么样的，并给出了原则和各种细则。在我看来，作者只是把“可维护”重新定义了“整洁”而已。

我总结的可维护性代码的三大特点是：

• 可读性高
• 可扩展性高
• 可复用性高

1 代码要可读性高

《代码整洁之道》中说，如果你把敲代码的过程进行录屏，就会发现大部分时间都是读代码的过程。

往往大部分代码都是自己最近写的，因此没有理解上的难度。此时，我们很少去关注代码是否具有高可读性。变量名字叫什么无关紧要，是否有注释也无关紧要，是否有优化的空间更无关紧要。我们下意识的心理逻辑是这样的：反正都是自己写的代码，自己能理解，明天看这个代码的人还是我自己，完成任务是首要的，毕竟公司看重的任务完成指标，因为这个影响绩效。

对待自己的代码是这个态度，对待他人的呢？对于非自己写的代码，比如要使用别人的接口时，基本上会问一下同事，“发起某某请求的方法，在哪个文件，叫什么名字？”，因为我们知道这样做来得快，要自己去找，那可就费劲了。

但是一直这么做会有问题的。正如《第五项修炼》说的那样，你要解决的问题，很可能是你上一次解决方案导致的问题，它们原本就不该出现。

问题出现的场景一般都发生在维护时。自己写的代码，半年后能会去读他的人仍可能还会是你本身。届时，你会想，自己当初为啥那么要这么写呢？那么长的一坨，竟然还没有注释，当初的思路是什么呢？这个变量名是什么意思呢？恨不能穿越过去，告诉自己：你现在的偷懒，以后还会由你来买单的。

最可怕的是，当你去维护别人写的垃圾代码，心里骂着别人时，其实，很可能现在的你同样会坑以后的另外一个人。当你每敲一段代码时，都要想一想那句名言：

代码是给人看的，只是偶尔运行一下。

2 代码要可扩展性高

写出来的代码，不会一成不变的。在迭代过程中，可能会多次修改。所以写代码时，不能只聚焦于眼下，只要完成功能就行了。想一想，如果一个月后，boss说你要把某某功能里添加一个小功能时，你怎么能快速定位到你的代码。此时就要考虑代码的可读性以及 设计模式 了。

这一点，其实目前流行的mvvm框架，本身就是为了解决此问题的。就跟画画一样，轮廓别人画好了，剩下我们只需要着色就行了。高内聚低耦合的代码，一直是我们追求的设计目标。封装变化、多用组合等等思想，良好的框架在这点上帮我们解决了不少问题。

3 代码要可复用性高

既然一些代码能复用，说明它们能解决一些通用的问题。比如流行的框架和库，本身就是让别人复用的。这也是设计模式存在的原因。你遇到的问题，别人肯定之前就遇到过，并且给出了通用方案。而我们要做的通常就是“拿来主义”。

具体到我们项目时，项目结构必然要分层，底层代码自然要抽出来，这个道理我们都懂。《代码整洁之道》中说，重复是软件一切邪恶的根源。所以，Dont repeat youself。

（二） 为什么我们写出的代码不是整洁代码

养成写整洁的代码，需要形成习惯。但是新习惯的养成就是要克服旧习惯。大道理，谁都懂。难的是，知行合一。为何自己写的代码那么糟糕，我们能找到两个常见的原因是：没时间和没反馈。

2.1 没时间

我们最常找的理由之一就是，没有时间。

我们前端工作的时间比例是这么划分的。书写代码和调试代码的比例大概是3：7。

想必我们都有这种经验。要实现一个页面，不到三个小时就能实现大部分功能，然后发现一些小问题，即那些难缠的bug，此时我们剩下的大部分时间都在对付这些可恶的“虫子”，代码改来改去。有时一个问题的定位、技术调研、与人沟通就能占据一天的整个下午。等到解决完这些小问题时，差不多也到下班的时间了。

这是我们常见的一天里，没有让代码整洁的时间。

项目完事了，马上开始下一个项目。当你愁眉苦脸地思考当前如何完成功能时，此时你被通知要维护一下之前的项目。再次修改自己之前的代码，你可能会感慨，以后这个代码需要好好修正修正。可惜手里项目太紧了，没有时间，也就真没有时间了。

这是我们项目周期间，没有让代码整洁的时间。

2.2 没反馈

比写糟糕代码的更糟糕的事情是：你不知道你写的代码很垃圾。每个人都很忙，没人帮我看代码，我也觉得自己写得不好，但我又不知道如何改进。这是很多新人的困境，没有反馈的练习，怎么也变成不了高手的。

（三） 如何书写整洁代码

没时间，会导致代码写不好，代码糟糕，会导致更没时间，这是一个死循环。

没反馈，就不知如何提高代码质量，进而一直维持下去。把第一年的经验再重复几年。这是一汪死水。

如何破掉这个局呢？

3.1 微习惯

其实，代码要保持整洁，就跟你屋子里保持清洁的原因一样。让屋子整洁很容易，你只需要进行一次大扫除就可以了。但是要一直保持清洁。那么需要养成 微习惯 。看完的书，不能随便在桌子上一摆，要换洗的衣物，要放到固定的地方等等。每一个都是微习惯。

从小事做起，比如变量名或方法名。好的代码是不需要大量注释的，因为好的变量名称就起到了注释的效果。《代码整洁之道》一书中，给出各个方面的整洁的代码是什么样的。比如函数该怎么写，注释该怎么写等等需要养成的微习惯。

3.2 清单思维

知道了养成这些微习惯是重要的，但如何养成呢？答案就是清单思维。

清单，除了我们熟悉todolist之外，那就核查清单。在清单上列出，哪些我们需要注意的地方，然后我们一条条去核对。做到了就打勾，这点对形成微习惯很有帮助的。知道了这个点后，我每次出门都不会丢三落四了。因为我记住一句话，伸手要钱买烟火。

其实，我建立了一个核查清单，身份证、手机、钥匙、钱包、烟和打火机等一样不落。这个事情也用在我们平常代码的开发中，可以用它来养成微习惯。写完代码后，拿出清单，对一对，直到自己养成习惯。

3.3 code review

旁观者清，当局者迷。根据人性的理论，每个人或多或少有双向标准。相对于要求别人，要求自己就宽松一点。同事之间进行代码回顾，其实对每个人都有好处的，刚开始看似浪费时间，其实减少以后的不该浪费的时间。此时也可以利用核查清单，毕竟每个人对一个个核查点的理解程度不一样，这样能帮助彼此更快地成长。而不是你向他人请教时，只会得到”你去看某某书就行了“这样的答案。

本文完。

整洁代码的核查清单： github.com/ryanmcdermo…

vue代码的核查清单： cn.vuejs.org/v2/style-gu…