面向价值编程：高ROI工程之旅

• ZStack源码分析：juejin.cn/column/6963…
• 代码与技巧：juejin.cn/column/6964…

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. 第二个例子中，获得的成果是我们可以将开发从繁琐细节、问题中解放出来，更好的支持业务功能迭代。同时我们建立了数据思维，根据指标来判断我们落地的结果，使质量问题长期来看处于收敛趋势。

而数据思维让我们的目标更加明确，也让我们可以更好的去判断我们是否有做好这件事、这件事是否有在好的方向发展。而不是全凭一张嘴——这样将会很难说服众人，便无法对齐这件事的价值。