公司越来越重视代码质量，这是好事。
但这里有几个躲不掉的矛盾：
- 在开发人员能力不变的前提下，提升代码质量必然会延长开发周期；
- 提升开发人员能力，同样需要投入时间、精力；
- 优先保证交付；
简单来说，提升代码质量和保证交付是冲突的、是需要取舍的，如何取舍？从 PBC 或 OKR 中二者的占比中就能明显看出来。
大家都明白，考评才是大家工作的源动力。一件事儿不管对组织、对个人有多大的好处，如果不能带来考评收益，必然鲜有人愿意做。一件好事儿为什么不一定能带来考评收益呢，这个原因就有很多了，比如：
- 收益难以量化：量化需要工作量（成本），为了获取考评收益去投入过多成本去量化指标可能造成成本浪费；
- 收益周期较长：考评通常以半年或一年为周期，如果一件事儿的收益周期长于 1 年，那很可能不能带来考评收益等等。
所以话说回来，如果不在考评维度中提高和代码质量相关指标的比例，大家是没有动力做的，也是不可能搞好的。特别指出 Bug 个数并不能衡量代码质量，不懂技术才会把代码质量和 bug 个数划等号。
每个项目组肯定都有个 Leader，我所理解的 Leader 的主要任务是保证项目成功，能在关键的「时间点」给出相应的「交付件」。说白了就是以搞交付为主，在代码质量与保证交付的跷跷板上，Leader 必然是站在保证交付一边的。当然我承认必然存在经验丰富、能力极强、举重若轻、游刃有余、运筹帷幄的 Leader 可以完美兼顾二者的平衡。但是现实是，这种管理人才少之又少，期望每个项目组的 Leader 都能达到这个水平是完全不现实的。
这里我必须声明，我也认为保证交付是极其必要的，这无可厚非，我今天试图讨论的是引入何种机制可以保持这个微妙的平衡。
从宏观角度来看，无论是自然界的生态圈，还是生物体内，都是无时无刻不处在一种动态平衡状态的，各种负反馈调节环相互作用，达到这种最富有生命力的微妙的平衡。在狼吃羊这个经典例子中，有如下制衡关系：
- 狼过多 —[吃掉太多羊，导致] —> 羊过少 —[使狼没有足够食物，使]—> 狼减少；
- 羊过多 —[养活更多的狼，导致]—> 狼过多 —[吃掉更多的羊，使]—> 羊减少；
这虽然只是一个简化过的例子，但是能帮助我们很好地理解为什么最具有生命力、持久力的平衡模式是这种动态平衡，而不是一成不变、跷跷板倾向一边。同样道理，为了使团队能健康的发展，我们需要一个角色可以站在跷跷板的另一边与 Leader 互相制衡，这个角色需要在保证 Leader 目标达成的基础上，建设团队的开发人员能力、提升项目的质量。这个角色必然是善于思考、经验丰富且技术过硬的。
这忽然让我想起了部队的团长和政委：一个是负责打仗，不管怎么样，要优先保证仗能打赢；一个是负责思想建设，提高团队凝聚力、具备长久打胜仗的能力。团长的角色其实就是一个团队的 Leader，是保证交付的，交付搞不定一切免谈；政委就是提升代码质量的，保证项目面向未来的延续性的。
前几天面试一个内部转岗的同事，听说他现在的团队写 Java 不允许使用 Lambda 表达式，虽然猜了个八九不离十，不过还是问了原因，果不出所料：MDE 怕团队成员看不懂降低可维护性。当时甚为震惊，竟无语凝噎。
转载自我的公众号 2019-10-24
若有收获，就点个赞吧
0 人点赞
