阅读 1312

书写可维护代码的重要性

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

(一)整洁代码的重要性

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

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

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

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

本文完。

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

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

关注下面的标签,发现更多相似文章
评论