兄弟,不要试图在业务代码中炫技。

27,285 阅读7分钟

你好呀,我是歪歪。

最近项目迭代非常密集,导致组里面的同事都在同一个微服务里面进行不同需求的迭代开发。

由于我们的代码提交规则规定,提交代码必须有一个 review 环节,所以有时候我会去仔细看同事提交的代码,但是有一说一,绝大部分情况下我没有仔细的去看,只是草草的瞟上几眼,就点击了通过。

其实我之前也会非常仔细的去看的,但是不得不说这个 review 的过程真的会占据比较多的时间,在需求不密集的时候做起来没有问题。

但是一旦任务在手上堆起来了,就很难去仔细 review 别人的代码了,分身乏术。

去年有一段时间就是忙的飞起,多线程并发需求迭代,别人提交代码之后,我就是无脑点通过。

我并没有核对最终落地的代码和我最初的设计方案是否匹配,而且由于代码不是我开发的,我甚至没有看过,等出了问题,排查问题的时候我再去找代码,就发现根本不知道写在哪里的。

方案设计和代码落地之间的断层,这样带来的一个后果就是我后期完全失去了对服务的掌握。

每天都担心,生怕出线上问题。但是每天也不知道哪个地方会出现问题,就很恼火。

对每一次我点进 review 通过的代码负责,这是我写进年度计划的一句话。

所以,今年为了避免这个现象的再次出现,在同事对一个完整的功能点提交之后,即使再忙,我自己会花时间仔细去 review 一次对应的代码,然后拿着我看完之后记录的问题再去找对应的同事给我答疑,确保我们至少在业务逻辑的理解上是一致的。

通过这个方式,我又重新掌握了主动权。

在这个过程中还暴露出一个问题,各个开发同事的编码风格各异,经常可以闻到一些代码的“坏味道”。

比如,我见过一个新增操作,所有的逻辑都在一个 controller 里面,没有所谓的 biz 层、service 层、dao 层,一把梭直接把 mapper 注入到了 controller 里面,在一个方法里面从数据校验到数据库交互全部包圆了。

功能能用吗?

能用。

但是我们常常提到的一个词是“技术含量”。

这样代码是有“技术含量”的代码吗?

我觉得可以说是毫无技术含量了,就是偷懒了,觉得怎么方便就怎么来了。

那如果我要基于对于这一段代码继续开发新功能,我能做什么呢?

我无能为力,原来的代码实在不想去动。

我只能保证在这堆“屎山”上,我新写出来的代码是干净的、清晰的,不继续往里面扔垃圾。

我读过一本书叫做《代码整洁之道》,里面有一个规则叫做“童子军军规”。

军规中有一句话是这样的:让营地比你来时更干净。

类比到代码上其实就是一件很小的事情,比如只是改好一个变量名、拆分一个有点过长的函数、消除一点点重复代码,清理一个嵌套 if 语句...

这是让项目代码随着时间流逝而越变越好的最简单的做法,持续改进也是专业性的内在组成部分。

我觉得我对于这一点“规则”落实的还是挺好的,看到一些不是我写的,但是我觉得可以有更好的写法时,而且改动起来非常简单,不影响核心功能的时候,我会主动去改一下。

我能保证的是,这段代码在经过我之后,我没有让它更加混乱。

把一段混乱的代码,拆分的清晰起来,再后来的人愿意按照你的结构继续往下写,或者继续改进。

你说这是在写“有技术含量”的代码吗?

我觉得不是。

但是,我觉得这应该是在追求写“有技术含量”的代码之前,必须要具备的一个能力。而且是比写出“有技术含量”的代码更加重要的一个基础能力。

先不说代码优雅的事儿了,至少得让代码整体看起来不混乱。

一个人维护一个项目,想要把代码搞优雅是一件很简单的事情,但是如果是好几个人一起维护就有点不好做了。

只有大家相互磨合,最后慢慢的形成好的、较为统一风格。

所以我最近也是持续在找一些关于代码风格、代码规范、代码重构这方面的好的资料在组分享,总是能慢慢有所改变的。

比如这周,我就找到了“京东云开发者”的一篇文章:

《让代码优雅起来:记一次代码微重构实践 | 京东云技术团队》
juejin.cn/post/725714…

在这篇文章里面,作者给到了一个完整的关于代码重构的示例。

把一个功能代码,从这样冗长臃肿的代码:

最终拆分为了三个类,每个类各司其职。

这个类只是负责组装对象:

金额计算拆分到了枚举类里面去:

这才是符合面向对象编程的思想。

这部分代码具体是干啥的,以及重构前后的代码是怎么样的,如果你感兴趣可以自己打开链接看一下。

我这边主要还是赞同作者的一个观点:不要觉得重构前的代码每次修改也就肉眼可见的几个地方,没必要在这上面花费时间。

其实我觉得还是很有必要的,大家写代码的时候都想要追求技术含量,追求优雅性,这就是一个体现的地方,为什么不改呢?

但是我还得补充一句,结合个人截至目前有限的职业生涯和工作经验来说,我有一点小小的体会:

写业务代码,代码可读性的优先级甚至比代码写的优雅、写的有技术含量更高,且高的多。不要试图在业务代码中炫技。

我前面分享的“记一次代码微重构实践”文章的最后也列举了两个引用的地方,我也放在这里,共勉之。

软件工程中的“破窗效应”:

破窗效应指的是在软件开发过程中,如果存在低质量的代码或设计,如果不及时修复,就会导致其他开发人员也采用同样的低质量方案。这会逐渐升级到更严重的问题,导致软件系统变得难以维护、扩展和改进。因此,在软件开发中,及时解决问题和保持代码质量非常重要,以避免破窗效应对于整个项目造成的负面影响。

同时看看 Martin Fowler 在《重构:改善既有代码的设计》一书中对重构的部分解释:

重构的每个步骤都很简单,甚至显得有些过于简单:你只需要把某个字段从一个类移到另一个类,把某些代码从一个函数拉出来构成另一个函数,或是在继承体系中把某些代码推上推下就行了。但是,聚沙成塔,这些小小的修改累积起来就可以根本改善设计质量。