你好呀，我是歪歪。
最近项目迭代非常密集，导致组里面的同事都在同一个微服务里面进行不同需求的迭代开发。
(资料图)
由于我们的代码提交规则规定，提交代码必须有一个 review 环节，所以有时候我会去仔细看同事提交的代码，但是有一说一，绝大部分情况下我没有仔细的去看，只是草草的瞟上几眼，就点击了通过。
其实我之前也会非常仔细的去看的，但是不得不说这个 review 的过程真的会占据比较多的时间，在需求不密集的时候做起来没有问题。
但是一旦任务在手上堆起来了，就很难去仔细 review 别人的代码了，分身乏术。
去年有一段时间就是忙的飞起，多线程并发需求迭代，别人提交代码之后，我就是无脑点通过。
我并没有核对最终落地的代码和我最初的设计方案是否匹配，而且由于代码不是我开发的，我甚至没有看过，等出了问题，排查问题的时候我再去找代码，就发现根本不知道写在哪里的。
方案设计和代码落地之间的断层，这样带来的一个后果就是我后期完全失去了对服务的掌握。
每天都担心，生怕出线上问题。但是每天也不知道哪个地方会出现问题，就很恼火。
对每一次我点进 review 通过的代码负责，这是我写进年度计划的一句话。
所以，今年为了避免这个现象的再次出现，在同事对一个完整的功能点提交之后，即使再忙，我自己会花时间仔细去 review 一次对应的代码，然后拿着我看完之后记录的问题再去找对应的同事给我答疑，确保我们至少在业务逻辑的理解上是一致的。
通过这个方式，我又重新掌握了主动权。
在这个过程中还暴露出一个问题，各个开发同事的编码风格各异，经常可以闻到一些代码的“坏味道”。
比如，我见过一个新增操作，所有的逻辑都在一个 controller 里面，没有所谓的 biz 层、service 层、dao 层，一把梭直接把 mapper 注入到了 controller 里面，在一个方法里面从数据校验到数据库交互全部包圆了。
功能能用吗？
能用。
但是我们常常提到的一个词是“技术含量”。
这样代码是有“技术含量”的代码吗？
我觉得可以说是毫无技术含量了，就是偷懒了，觉得怎么方便就怎么来了。
那如果我要基于对于这一段代码继续开发新功能，我能做什么呢？
我无能为力，原来的代码实在不想去动。
我只能保证在这堆“屎山”上，我新写出来的代码是干净的、清晰的，不继续往里面扔垃圾。
我读过一本书叫做《代码整洁之道》，里面有一个规则叫做“童子军军规”。
军规中有一句话是这样的：让营地比你来时更干净。
类比到代码上其实就是一件很小的事情，比如只是改好一个变量名、拆分一个有点过长的函数、消除一点点重复代码，清理一个嵌套 if 语句...
这是让项目代码随着时间流逝而越变越好的最简单的做法，持续改进也是专业性的内在组成部分。
我觉得我对于这一点“规则”落实的还是挺好的，看到一些不是我写的，但是我觉得可以有更好的写法时，而且改动起来非常简单，不影响核心功能的时候，我会主动去改一下。
我能保证的是，这段代码在经过我之后，我没有让它更加混乱。
把一段混乱的代码，拆分的清晰起来，再后来的人愿意按照你的结构继续往下写，或者继续改进。
你说这是在写“有技术含量”的代码吗？
我觉得不是。
但是，我觉得这应该是在追求写“有技术含量”的代码之前，必须要具备的一个能力。而且是比写出“有技术含量”的代码更加重要的一个基础能力。
先不说代码优雅的事儿了，至少得让代码整体看起来不混乱。
一个人维护一个项目，想要把代码搞优雅是一件很简单的事情，但是如果是好几个人一起维护就有点不好做了。
只有大家相互磨合，最后慢慢的形成好的、较为统一风格。
所以我最近也是持续在找一些关于代码风格、代码规范、代码重构这方面的好的资料在组分享，总是能慢慢有所改变的。
比如这周，我就找到了“京东云开发者”的一篇文章：
在这篇文章里面，作者给到了一个完整的关于代码重构的示例。
把一个功能代码，从这样冗长臃肿的代码：
最终拆分为了三个类，每个类各司其职。
这个类只是负责组装对象：
金额计算拆分到了枚举类里面去：
这才是符合面向对象编程的思想。
这部分代码具体是干啥的，以及重构前后的代码是怎么样的，如果你感兴趣可以自己打开链接看一下。
我这边主要还是赞同作者的一个观点：不要觉得重构前的代码每次修改也就肉眼可见的几个地方，没必要在这上面花费时间。
其实我觉得还是很有必要的，大家写代码的时候都想要追求技术含量，追求优雅性，这就是一个体现的地方，为什么不改呢？
但是我还得补充一句，结合个人截至目前有限的职业生涯和工作经验来说，我有一点小小的体会：
我前面分享的“记一次代码微重构实践”文章的最后也列举了两个引用的地方，我也放在这里，共勉之。
软件工程中的“破窗效应”：
同时看看 Martin Fowler 在《重构：改善既有代码的设计》一书中对重构的部分解释：
标签：
