关于软件工程:面向价值编程高ROI工程之旅

0. 前言

在后面的系列文章中，我提到了相干的实践，实操，以及一段工作经验。在这篇文章中，我会用我本人和团队的经验来作为例子，诠释面向价值编程，并通过两个例子阐明高 ROI 工程的打造过程。

ROI个别指投资回报率。是指通过投资而应返回的价值，即企业从一项投资流动中失去的经济回报。在这篇文章中，咱们指的是一个我的项目的投入产出比——当一个我的项目投入产出比高的时候，老板则会很乐意继续投入，相干人员也能够取得更高的报酬。反之则不然，甚至还会面临裁员危险。

1. 初生牛犊不怕虎：刚好有个重构的机会

刚到沃趣的时候，QPlus 刚好在进行重构——起因是这个产品卖的还行，而其本质应关注数据库相干的业务，但理论开发时开发者须要关注底层根底施行的逻辑，而基础设施这块没有相干人员的储备。而我的到来刚好能够补救这点，我略懂一些 Iaas，基于现有的开源我的项目也能够做出二次开发来满足业务需要。尽管咱们 利用 Iaas 来疾速的满足业务需要，但在迭代过程中其复杂性也是须要咱们管制的。

之前在 ZStack 的时候研发和 QA 的配比是 1:2。

在我的项目的一开始，我就在团队里强调 CleanCode 和白盒测试的重要性——Iaas 切实 太简单 了，一开始团队里就 3 个研发 1 个 QA，咱们二开时如果不去刻意 收敛它的复杂度，到前面的开发成本是收不住的，因而咱们须要通过自动化测试来保障正确性。但这在过后重构的时候带来了额定的老本——团队的同学不仅要去理解二开，还要做好 CleanCode（因为 CleanCode 做不好，白盒测试是做不了的），这减慢了开发速度。过后公司里也呈现了不反对的声音——之前别的团队也没有搞过自动化，照样能迭代出产品，为什么你们肯定要搞自动化，搞的这么慢？这种状况下，整个团队压力特地大。

放在 2018 年的时候，国内公司广泛考究研发一把梭，梭上市场看成果。研发老本治理这个事根本不会提，堆不动就堆人。但我对此始终有不同的认识——如果咱们能够把老本降得更低，咱们的利润就会更高。而且这个行业怎么可能始终是夏天（不停的增长），总有遇到冬天的时候，这个时候 ROI 就特地的重要。

万幸的是，咱们还是实现了重构，自动化的理念也在公司外部开始传开。再起初这个产品迭代得逐步成熟。当我在 2022 年的时候和共事聊起时，它曾经成了一个高 ROI 的我的项目，用两个人就能够撑持十分可观的销售额。

而对于 ZStack 二开、CleanCode 和 AutoTest，咱们在实践中也积攒出了一些教训。本着前人挖坑前人填坑的精力，我也是把相干的专栏列在这里：

• ZStack 源码剖析：https://juejin.cn/column/6963644910666776612
• 代码与技巧：https://juejin.cn/column/6964737683717357599

2. 盛年不再来，一日难再晨：一把梭的代价

当咱们收回了新版的 QPlus 后，公司正在做一个新的产品线，次要是做数据同步相干的事，我对它十分感兴趣，便申请转过去了。

过后产品线曾经有了天使客户，落地成果以及利润也不错。所以想着寻找一些行业里的典型客户，成为行业解决方案后再在行业里复制开来。这个版本的版本号咱们定为 2.0。过后的产品经理对迭代速度是有要求的，于是乎大家都热气腾腾的迭代，以至于大家 review 代码都要省着工夫——PM 认为这事以后没有价值。同样的是咱们对于老框架的质疑，这让咱们的开发人员一次又一次的陷入底层细节，这也给前面的品质问题埋下了伏笔。

底层细节：诸如数据同步有误、位点失落等等等。咱们在应用 Kafka 与 Storm 时经常遇到这样的问题。

这事再一次通知咱们——软件开发中的不可能三角是实在存在的：人力、品质、速度。当人力固定时，速度和品质只能二选一。

2.0 前面迭代进去，落地到一半时，公司成立了新的产品线，从咱们这里抽调了一部分人走，再加上人员变动，当我作为主程时，研发起码的时候只有 3 集体。那是最难熬的时候，我要解决一堆 2.0 的问题，食了前人种的果。

起初随着业务机会的变多，咱们打算逐步进行 v2 版本的保护，去做 v3 版本的开发——这个版本次要是对 v2 版的技改，意在降本增效——通过框架的封装来防止开发陷入底层细节逻辑。再前面就是团队逐步扩招，研发扩招至 7 人，整个团队最多的时候有 16 集体。因为一开始我的项目是三跑的，v2 的落地和 v3 的开发都要推动，v1 的保护也要关注。前面咱们放弃了 v2 版本的落地，分心开始 v3 的迭代了。

v3 版局部组件是齐全重写的，基于新框架，底层根底性能确实再也没有呈现过问。但管控平台局部沿用了之前的代码。因而仍有一系列品质相干问题需解决，如：

1. 自动化测试在团队中已有相干实际，但大家不怎么乐意写，因为从短期来看这会减少集体工作量。但长期来看，这会减少软件的不稳定性。
2. 负责 code review 的同学，帮 A 同学 review 代码，这次 review 出了一类问题，下次 A 同学还是写出了这样的问题，review 仅仅是查看，并没有让 A 同学成长，长期来看这部分工作量并没有收敛，写进去的代码也没什么晋升，间接带来品质危险。
3. 线上问题频繁呈现，但大家都感觉软件有问题是失常的。因而团队里的同学对于软件品质这块的关注是非常少的，但咱们以一个整体视角来看：一个 bug 从客户现场产生，驻场同学报告，报到 PM，让 QA 复现，让研发跟进，这外面会有多少环沟通？又会有多少的细节在沟通中缺失？举个例子，有一次客户现场出了一个诡异的问题，咱们想把日志捞回来，得悉连机器的 copy 文件创建是 xx 点到 yy 点，当初曾经过了，因而要等今天才行。到了第二天，咱们拿到日志开始剖析，写好补丁本地验证，到了第三天公布过来，和客户沟通上线工夫，而后公布验证。这个 case，一个 bug 花了 3 蠢才解决。但如果在外部发现，可能 2 小时就解决掉了。因而得出结论，一个 bug 被发现、修复的越早，带来的老本越小。
4. 因为 问题频出，销售对于销售软件的信念和动向度也会逐步缩小， 长期来看不利于晋升产品的支出，几乎从本源上抹杀了产品倒退的可能。

但如何压服老板去做一个品质治理，以及如何让老板看到过程中的成果、最终拿到后果，这是须要认真思考的——团队大了，开销也下来了，决策上的失误会让公司浪费资源，咱们应该尽量避免这样的事产生。

我认为，bug 产生于开发期间，从它到客户现场被发现，两头还有许多环节，咱们应该激励事先发现，而不是预先救火。而那个时候业界里曾经有了很多成熟的计划，我在参考了许多计划后，做法如下：

• 关注稳定性：从写代码，到自测提交代码，到提测，到上线对整个软件生命周期进行关注，并量化跟踪考量。

-   写代码时：关注代码标准扫描，设计文档与框架束缚
-   自测提交代码时：关注自测覆盖率（白盒测试）以及代码 review 中 review 出的问题数
-   提测时：关注千行代码 bug 率
-   上线时：关注告警与重大问题统计，以及模型形象正当水平

• 找适合的人来落地这些事：依据团队的梯队划分来赋予更多的权力和职责

  • 对于职级高的同学，须要负责更多的模块，对相干模块的品质负责。品质好更利于绩效的评优
  • 对于倒退志愿强的同学，尝试给他额定的模块负责其品质

整体的计划比较简单，并没有引入特地多的指标以及一系列的平台工具。数据的收集事通过人工来做的——这在团队规模较小时是可行的，这点也是思考到为了疾速落地。在施行以上计划时，团队每个月还会进行一次简略的谈话，和团队成员沟通相干的指标是否合乎预期，以及接下来的指标或不足之处等。通过了小半年的治理，整体的品质有了较大的晋升，团队里的成员也切实感触到了这套办法的可行性。

3. 小结

以上两个例子和降本增效有着密切关系：

1. 第一个例子中，取得的成绩是通过两个人能够撑持起可观的销售额。
2. 第二个例子中，取得的成绩是咱们能够将开发从繁琐细节、问题中解放出来，更好的反对业务性能迭代。同时咱们建设了数据思维，依据指标来判断咱们落地的后果，使品质问题长期来看处于收敛趋势。

而数据思维让咱们的指标更加明确，也让咱们能够更好的去判断咱们是否有做好这件事、这件事是否有在好的方向倒退。而不是全凭一张嘴——这样将会很难说服众人，便无奈对齐这件事的价值。