本文是个人对书写可维护代码的一点点思考。

（一）整洁代码的重要性。

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

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

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

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

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

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

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

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

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

1 代码要可读性高。

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

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

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

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

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

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

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

2 代码要可扩展性高。

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

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

3 代码要可复用性高。

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

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

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

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

2.1 没时间。

最常找的理由之一就是，时间不够。

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

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

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

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

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

2.2 没反馈。

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

（三） 如何书写整洁代码。

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

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

如何破这个局呢？

3.1 微习惯。

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

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

3.2 清单思维。

养成微习惯是重要的，但如何养成呢？答案是清单思维。

清单，除了我们熟悉的todo list之外，还又一种核查清单。在清单上列出哪些我们需要注意的地方，然后我们一条条去核对。做到了就打勾，这点对形成微习惯很有帮助的。

比如，我每次出门都不会丢三落四。因为我记住一句话，伸手要钱买烟火。

这里，我建立了一个核查清单：身份证、手机、钥匙、钱包、烟和打火。同样的道理，在我们日常代码的开发中，提交代码之前，拿出清单对一对，直到自己养成习惯。

3.3 code review。

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

本文完。

整洁代码的核查清单：
https://github.com/ryanmcdermott/clean-code-javascript#introduction

vue代码的核查清单：
https://cn.vuejs.org/v2/style-guide/