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

你好呀，我是歪歪。

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

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

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

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

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

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

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

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

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

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

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

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

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

再比如，一个方法的入参有七，八个之多，有的地方调用的时候每个参数都能给到，有的地方调用的时候可能只有一两个入参有值，其他的参数就都给个 null。

再再比如，在事务里面嵌套了大量的不需要在事务里面执行的代码，甚至还有远程调用。

......

你说这些功能能用吗？

能用，确实是能用。

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

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

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

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

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

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

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

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

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

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

我能保证的是，一段代码在经过我之后，我至少没有让它更加混乱。

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

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

我觉得不是。

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

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

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

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

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

比如这周，我就找到了“京东云开发者”的一篇文章，准备在团队里面分享一下：

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

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

把一个功能代码，从这样冗长臃肿的代码：

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

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

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

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

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

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

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

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

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

（当然，如果你写出了别人读不懂只有你才明白的核心业务逻辑代码，也算是你的一个技术壁垒，算你牛逼。）

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

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

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

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

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

··············  END  ··············

你好呀，我是歪歪。我没进过一线大厂，没创过业，也没写过书，更不是技术专家，所以也没有什么亮眼的title。

当年高考，随缘调剂到了某二本院校计算机专业。纯属误打误撞，进入程序员的行列，之后开始了运气爆棚的程序员之路。

说起程序员之路还是有点意思，可以点击蓝字，查看我的程序员之路。