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源码剖析：/column/6963…

• 代码与技巧：/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. 第二个比如中，取得的效果是咱们能够将开发从繁琐细节、问题中解放出来，更好的支持事务功用迭代。一起咱们建立了数据思想，依据方针来判断咱们落地的效果，使质量问题长时刻来看处于收敛趋势。

而数据思想让咱们的方针更加清晰，也让咱们能够更好的去判断咱们是否有做好这件事、这件事是否有在好的方向开展。而不是全凭一张嘴——这样将会很难说服众人，便无法对齐这件事的价值。