面向价值编程:那些年在Coding质量上走过的路

906 阅读8分钟

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

版本日期备注
1.02022.8.3文章首发
1.12022.8.10根据反馈改进内容
1.22022.9.11修改标题

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的程度。上面承载的业务就像我们出去打猎时的武器一样,商业战场就像一个丛林。如果我们无法用武器打到猎物——获取商业上的成功,那么我们迟早被饿死。至少得在我们不被饿死的情况下,再考虑武器的顺手程度,甚至那天心情好还可以雕个花在上面,让它像个艺术品一样。

追求代码的极致并非是无用的。那些核心库,框架就需要这些技巧,因为把它们写好的同时,就已经能给上层的业务带来更多的价值了。