在很长一段时间我并不知道怎么去平衡速率和质量之间的关系，我虽然看过不少书和文章告诉我只有保证质量才能保证速率，但我还没有见过反例，我没办法很好地说服别人，我只能看着他们义无反顾的冲向进度，然后抱怨时间不够。我想用我经历和见证的不同项目、不同情况来和你聊聊为什么质量等于速率。

我们这个迭代的卡完成不了了，你们先不要管重构测试之类的东西了，先把功能写完。
我们上个迭代的速率还不错，不过这个迭代的压力也很大，我们还是加加速吧，code review先放放。

这可能是在很多进度紧张的 fix bid 项目能听到的一些话。质量和进度的取舍好像是软件工程一直都绕不开的话题。对于这两个维度我们到底应该怎么做呢，放弃质量追求进度的做法可不可行呢？或者我们能不能都要？

在很长一段时间内我并没有答案，毕竟没有过经历就没有发言权，不过如今在我经历了不同项目、不同情况后好像找到了一些答案。

不过在开始前我想先简单聊聊质量和速率这俩东西。

产品质量

**人们最普遍的认知是，质量越好的产品成本越高，价格也越高。**当然我们需要控制变量，不考虑品牌溢价等因素。

举个例子，假如一个产品用两个月就坏了，为了让它用的更久，我们可能需要改进工艺，可能需要使用更好的材料制作。这些改进会让制造商付出更多的成本，为了赚回这些成本，这个产品就会卖更高的价格。

软件质量

但是软件质量和一般的产品质量又有些许不同。它主要分为两个方面 – 外部质量和内部质量。

外部质量

外部质量简单来说是用来描述软件用户能够触碰到的部分的质量。比如是不是有 bug 会导致软件崩溃；软件的可用性/易用性如何；用户是不是能用软件快速解决自己的问题等。

内部质量

内部质量则对用户不可见，用户也不关心软件的内部质量。它主要涉及的是代码的可维护性。比如代码架构是不是合理；是不是可扩展的；模块间的依赖是否杂乱无章；是不是有无法控制的技术债；是不是有自动化测试保证代码的正确性等。

质量与速率

如果把这两部分拆开来看，用户压根不关心内部质量，因为用户只管你的软件好不好用，至于代码好不好维护这件事他们根本就不在意。但是用户在意的是他提出的意见和建议开发者能不能快速反馈，他想要的新功能你能不能赶紧给安排上。

而这个时候就体现出了内部质量的重要性。我们每个人都知道的是，在一份内部质量优秀，技术债不多的代码库中增加新功能，要比在一个内部质量相对差一些的代码库中增加新功能容易得多。

此图来自：https://martinfowler.com/articles/is-quality-worth-cost.html

当然你也有可能会想，我们为了使代码保持高质量，去解决技术债、重构、组织代码结构的时候是实实在在花了时间的，我把这些时间用来增加新的功能速率就是会更快。

在保持其他条件不变的情况下，我们无法否认这样做是会加快你的速率，但这其实是一个短期收益和长期收益的取舍，而这个短期可能比你想象中要短的多。

此图来自：https://martinfowler.com/articles/is-quality-worth-cost.html

从这个图里可以看到，如果代码一直保持高质量，开发速率将在几周后超过内部质量不太好的代码，这个结果来自于 Martin Fowler 和他认为资深同事的经历的总结。

和大多数人一样，我在最开始对这份数据持怀疑态度，直到我如今我参与或间接见证了几个有意思的项目。

六边形战士

这是一个从起项目就聚集了一众大佬的明星团队，哪怕在项目压力大，需求复杂且不明确的情况下，大家对于工程实践和软件质量的要求都很高。我所学习到的停留在书本上的敏捷实践在这个组都能看到。我在这里体验了极限编程、clean code，大家会抽时间 pair，实践 TDD，用重构来使代码符合 simple design，有自发的不定期的分享，以定期 tech huddle 的形式来管理和讨论技术债…

我是在项目更替许久已经进入某个平稳期的时候加入项目的，这时候项目闲的发慌，大家都在想各种办法提升自己的能力，我在这里切身体会到了 P2 文化。

事情的转折来自于项目 N 期准备上线前的几个迭代，突然出现了一批之前没有分析出来的隐藏需求，但与此同时我们还需要做上线前的准备，项目进入了赶进度阶段。

但是在这种紧张的情况下我们并没有丢弃各种实践，大部分实践依旧是我们的底线，不过我们也确实停止了 pair，暂停了 tech huddle。TDD、重构、simple design，各种工程实践已经成了这个项目的 baseline。

这些后来被称为“负担”的东西不仅没有拖慢我们的脚步，反而作为保护网保护了我们在需求不明确的情况下反复修改的代码，大大减少了 debug 和破坏已有功能的可能性。

停不下来的雪崩

这是一个已知的短期项目，我并没有亲身经历。项目组制定的策略是，放弃一些实践，短时间内快速堆出客户想要的东西完成 MVP。

在开始的一段时间项目按照预期稳步进行，但随着时间的推移和来自于交付的压力，团队放弃的实践越来越多。从开始的放弃 pair、放弃 TDD，到后来的放弃写测试、放弃 code review。再到后来为了达到预期的 velocity 开始加人。

但是情况已经如同雪崩一般无法阻止。从外部观察和私下与项目中 core team 的小伙伴 retro 来看，项目刚开始确实要轻松一些，但是随着大家不管不顾项目质量，一味追求进度，项目开始向雪崩的方向发展。

项目逐渐陷入泥潭的时间接近两个迭代，也就是四周接近一个月，与 Martin Fowler 的结论非常接近。在这个 retro 中我开始意识到老马好像没有骗人，他那个图没有瞎画。

当然我们并不能将这样的情况简单归咎于项目质量，但这的确是一个不可忽略的关键因素。

高达的内部协调

这是我经历过人数最多的项目，超过 200 人被分成 7 个团队，大家分布在 3 个国家的 6 座城市。而这个分布式团队要通过各种合作造出一个高达。

我们接手的是一份质量说不上好的代码库。刚上手我的体验极差：

• 项目代码结构混乱，很难找到自己想找的代码
• 被称为内部渲染引擎的的一份框架代码逻辑混乱，几乎没有测试，但被大半个代码库依赖
• 按照 README 甚至没办法启动本地环境
• 为数不多的测试代码极其不稳定，但又找不到不稳定在哪，然后之前的开发团队用了各种骚操作尝试修复这种不稳定
• …

刚开始的一个月我们举步维艰，甚至还没开始就已经陷入泥潭，更不必说接下来的速率目标，之后我们制定了一些每个人都应该遵守的原则：

• 就算花费时间久，起项目的前几个迭代中国区三个团队的 web devs 要在一起 code review，这有助于我们在 code review 的过程中发现和解决大家共同的问题
• clean code 是我们的底线，每个人都可以参与制定团队代码实践并严格遵守，任何人都能给其他人留符合实践规范的 comments，不改完不 merge
• 管理团队技术债并定期解决
• 重新规划整个代码结构
• 可以不 TDD 但必须写测试，制定可行的测试策略
• …

大家顶着被各种催进度的压力在做各种取舍，这中间花的时间是实实在在的，但改变也是实实在在的。

“我改了 xxx，yyy 的测试挂了，我得去看看。然后就能提 PR 了。”
“aaa 文件在 bbb 里面，bbb 里面是整个 flow。”
“这张卡我搞定了，现在在做重构，搞完后下张卡会很快。”
ccc 的功能 pattern 已经定成上次讨论的了，你后面的功能搞成一样，一看就懂了。

我们花在质量上的时间，都在未来的时间中赚回来了：由于定好了开发规范，我们在 code review 过程中不会再争论无意义的规范问题；大部分 bug 在出现的那一刻都能被我们的测试捕获到并快速修复；我们能快速找到我们想找的东西。

而那些我们还没有努力过的方向，依然让我们难受，比如前面提到的渲染引擎（苦笑

答案

看完三个故事，现在你应该能发现我们的时间都去哪了。

每个人都知道写垃圾代码可以让开发速度增快，那么我们停止花时间维护代码质量，把所有精力扑到完成功能追赶进度上来，如果可以的话，时间拉满，一个月工作 380 个小时。

静下心来好好想想朋友，”快而脏“是不存在的，垃圾代码只会让你把你所有时间用在 debug 里，垃圾代码只会拖累你。请记住，加快速度的唯一办法就是保证质量。

换个角度想想，你加快速度节省的时间，又在 team 里面其他人身上花掉了，QA 会向你抱怨为什么之前好好的功能现在坏掉了，同事会来问你为什么他昨天的代码今天自测就不工作了，BA 会来告诉你今天 showcae 又失败了…

你觉得省下的时间，三五天后又回来找你了。

勇气

最后我想引用 Bob 大叔在《敏捷整洁之道》一书中对敏捷勇气价值观的解释来结束这篇文章。

勇气 —— 换句话说, 就是 在合理范围内敢于冒险。敏捷团队的成员并不太关注公司政治意义上的“安全”，那会导致牺牲质量和机会。他们意识到，长期来看，管理软件项目的最佳方法是具备一定程度的侵略性。
勇气和鲁葬是有区别的。部署最小的功能集需要勇气。维护高质量的代码和高质量的纪律需要勇气。但是，部署你自己都没有信心的代码，或者设计不具可持续性的代码，这就是鲁莽。通过牺牲质量来遵守时间表就是鲁莽。
质量和纪律会提高速度，这是一种信念，强势但幼稚的人们在面对时间压力时会不断挑战这种信念，因此坚持正确的信念需要勇气。

---

文/Thoughtworks 张起荣
原文链接：为什么软件质量等于开发速率