关于codereview:那些年在Coding质量上走过的路

本文首发于泊浮目标掘金:https://juejin.cn/user/146860…

0. 前言

最近接了几个我的项目，代码品质参差不齐。本想依照以往的实际倡议每个 patch 都做 review，但往往 dead line 当头。我会想，我如果对这次 patch 做了 review、以及长期做 review 能给业务带来什么价值。接着本文，我还想探讨其余技巧在 coding 中也可能显著带来价值。

留神，这里的价值指的是可量化的价值。常见的说法可能是有利于零碎长期的可维护性、稳定性等，但无奈给出相干指标。但咱们须要晓得， 数据思维要优于教训积淀 。

1. 期间最重要

期间很重要，依据不同的期间，咱们会抉择不同的生存，也会抉择不同的投资策略。技术也是，之前听王志猛的分享，给出了一个很接地气的技术倒退阶段：

• 能用
• 好用
• 卓越

在商业模式或者业务价值被验证之前，最好是谋求速度。这就像你饿着肚子要去打猎，你不会在意这把武器有多丑陋，而是它能不能帮忙到你打到猎物防止饿死。这就是能用的阶段。

CodeReview 往往产生在好用和卓越的阶段。这个时候我的项目的价值曾经被验证，须要配合业务倒退进一步的迭代。这里也能够拆分细说：

• 好用即齐全满足业务需要。
• 卓越即在齐全满足业务需要的根底上，可能用更少的老本。无论是从业务还是技术的角度做到行业顶尖。

而 CodeReview 的价值就是从好用开始产生的，这个时候往往关注如何稳固的迭代业务。而到了卓越期间，CodeReview 显得更加重要——这个时候承载的业务往往是有体量的，须要更加留神业务的稳定性和连续性；同时团队规模也在扩充，须要进一步关注降本增效。

2. CodeReview 的双刃剑

我本人是参加过很多 CodeReview 的，在 ZStack 每个 patch 都要找相应的 maintaner review 当前才能够合入主干，总体 Review 的粒度也很细。就对集体而言，我很多的 Coding 技巧就是在那个时候学来或者收到启发的。但这具备肯定的老本——我举个例子：比方有一个性能开发了 3 天，测试测了 3 天也测过了，当初进行骨干合入，maintaner 看了半小时，提了 10 个 comment 须要改良。那么开发就须要去批改并测试（花了 1 天），并再次配合测试进行测试（测试花了 2 天），最初骨干合入，那么就比原来的 6 人天多出了 3 人天，50% 的人天增长。

或者咱们能够聪慧点，搞个 develop 分支：那么就是开发提交代码，review 后再次批改并自测，而后再提交合入，交给测试测试。但总体来说，还是带来了研发“额定的老本”，maintaner 往往是业务的次要角色，他的工夫也很贵重。

在沃趣时，我的项目迭代炽热时一天有 10 多个 patch 须要我 review，于是我一天都在 review，起初缓缓的把不同的我的项目、模块拆给不同的负责人，这种状况才好了点。

如果你正在思考引入 CodeReview，并且确实是在好用到卓越的过程中。那么我感觉首先要和下层达成共识，对于这额定产生的人力老本如何进行成本计算。当初在 ZStack CodeReview 由 CEO 张鑫直推，因而我不分明那时是如何显式量化 CodeReview 带来的价值。但据我所知，一些大厂都有相应的研发效力洞察平台，会依据大量指标来掂量研发效力，本文谈到相干办法得出的指标可能只是其中的沧海一粟，思考到管制篇幅，不再开展。

而对于引入的 CodeReview 里的实际规定来说，我认为重点是关注宏观上的设计。举个例子，如果咱们写一个简单的业务平台，而不是简略的 CRUD 业务（比方图书馆借阅零碎），用“经典”的三层架构，那么无论你的代码细节标准抠的多好（缩小 if else 技巧，每个函数不能超过 x 行之类的）最终都是难以迭代的。而当咱们借用了整洁架构的思维后——无论是 DDD 还是六边形架构或者是 SOLID、设计模式、经典编程思维，咱们会发现相比那些蹩脚的小细节，放弃宏观的整洁才是最重要的。

令人惆怅的是，很多自动化检测工具都是关注宏观的细节，而可能关注宏观整洁的工具少之又少。这是能够了解的，不同我的项目对于宏观整洁的要求是不同的，众口难调。

举例：咱们的住处往往区域明确，厨房里摆着餐具，卧室里有床铺。即便厨房里的锅或者铲子放的地位有点乱，也不是难以承受——这就是宏观上的整洁，宏观上的小蹩脚；而如果咱们厨房里叠着一个洁净的床单，卧室里有一个锅，就算他们摆放得再参差，这也违反了宏观的整洁，即便在宏观上来说他们很整洁。

另外一个简略暴力的伎俩则是白盒测试的覆盖率，尤其是单元测试。可能轻易编写单元测试的代码相对来说比拟松耦合，因而将白盒测试的覆盖率作为 review 的考查重点是个不错的抉择。

3. 如果不写代码就能够不 Review 了

正如小标题所说，既然 review 代码代价这么大，那罗唆不写代码了。比如说咱们能够用 DSL。

这种做法其实十分常见，做过大数据的都晓得 MapReduce 或者 Strom，编写它们要关注大量的细节，比方数据如何 shuffle，如何保障可靠性。而现在咱们用 FlinkSQL 则齐全不必关注这些底层的细节，咱们只需关注数据从哪来，怎么做业务解决，而后落哪儿去。这就是陈词滥调的申明式编程，而不是面向过程编程。

同样的思维，也体现在 K8S 的申明式 API 上，写好配置申明而后提交，就等资源创立就完事了。假使你创立一组资源，须要依照其依赖先后调用，并关注外面的状态细节，这样的易用性显然是差了很多的——就像 OpenStack，你要创立 VM 前有一系列的事要先筹备好。

低代码平台也是同样的思路，通关拖拽的形式造成 UI 相干的代码，甚至能够定义一些简略的逻辑在外面。这样造成的代码天然不必 Review，要做优化也是低代码平台里的代码解释器来做。

以这种形式来思考业务价值，其实是十分不言而喻的：让一个一般的开发去写一段 SQL 可能只有 10 分钟，而用代码写一个对应的数据处理工作可能要半小时起。

4. 写好代码并非一无是处

这么说起来，谋求齐全洁净整洁的代码对于业务来说仿佛没有那么重要。从业务角度来说，是这样的。但总有一些外围的代码、常常被大家应用库、框架须要洁净整洁的代码与 API 设计，它们往往位于我的项目的底层，但却默默的撑持着在下面倒退的业务。这就须要 CleanCode，哪怕少传一个参数，少一行代码，普惠的则是所有的使用者——这种价值往往体现在降低成本上。

5. 小结

本文探讨了笔者在 coding 品质上走过的路，针对 CodeReview 分析了引入工夫以及重点关注项。并指出了更容易被量化价值的申明式编程是一个不错的抉择。

针对绝大多数的业务代码，需依据期间来衡量 CodeReview 的水平。下面承载的业务就像咱们进来打猎时的武器一样，商业战场就像一个丛林。如果咱们无奈用武器打到猎物——获取商业上的胜利，那么咱们迟早被饿死。至多得在咱们不被饿死的状况下，再思考武器的棘手水平，甚至那天情绪好还能够雕个花在下面，让它像个艺术品一样。

谋求代码的极致并非是无用的。那些外围库，框架就须要这些技巧，因为把它们写好的同时，就曾经能给下层的业务带来更多的价值了。