太长不读：在很长一段时间我并不知道怎么去均衡速率和品质之间的关系，我尽管看过不少书和文章通知我只有保证质量能力保障速率，但我还没有见过反例，我没方法很好地压服他人，我只能看着他们义无反顾的冲向进度，而后埋怨工夫不够。我想用我经验和见证的不同我的项目、不同状况来和你聊聊为什么品质等于速率。
咱们这个迭代的卡实现不了了，你们先不要管重构测试之类的货色了，先把性能写完。
咱们上个迭代的速率还不错，不过这个迭代的压力也很大，咱们还是加减速吧，code review 先放放。
这可能是在很多进度缓和的 fix bid 我的项目能听到的一些话。品质和进度的取舍如同是软件工程始终都绕不开的话题。对于这两个维度咱们到底应该怎么做呢，放弃品质谋求进度的做法可不可行呢？或者咱们能不能都要？
在很长一段时间内我并没有答案，毕竟没有过经验就没有发言权，不过现在在我经验了不同我的项目、不同状况后如同找到了一些答案。
不过在开始前我想先简略聊聊品质和速率这俩货色。
产品质量
人们最广泛的认知是，品质越好的产品成本越高，价格也越高。当然咱们须要控制变量，不思考品牌溢价等因素。
举个例子，如果一个产品用两个月就坏了，为了让它用的更久，咱们可能须要改良工艺，可能须要应用更好的资料制作。这些改良会让制造商付出更多的老本，为了赚回这些老本，这个产品就会卖更高的价格。
软件品质
然而软件品质和个别的产品质量又有些许不同。它次要分为两个方面 — 内部品质和外部品质。
内部品质
内部品质简略来说是用来形容软件用户可能触碰到的局部的品质。比方是不是有 bug 会导致软件解体；软件的可用性 / 易用性如何；用户是不是能用软件疾速解决本人的问题等。
外部品质
外部品质则对用户不可见，用户也不关怀软件的外部品质。它次要波及的是代码的可维护性。比方代码架构是不是正当；是不是可扩大的；模块间的依赖是否横七竖八；是不是有无法控制的技术债；是不是有自动化测试保障代码的正确性等。
品质与速率
如果把这两局部拆开来看，用户压根不关怀外部品质，因为用户只管你的软件好不好用，至于代码好不好保护这件事他们基本就不在意。然而用户在意的是他提出的意见和倡议开发者能不能疾速反馈，他想要的新性能你能不能连忙给安顿上。
而这个时候就体现出了外部品质的重要性。咱们每个人都晓得的是，在一份外部品质优良，技术债不多的代码库中减少新性能，要比在一个外部品质绝对差一些的代码库中减少新性能容易得多。
当然你也有可能会想，咱们为了使代码放弃高质量，去解决技术债、重构、组织代码构造的时候是实实在在花了工夫的，我把这些工夫用来减少新的性能速率就是会更快。
在放弃其余条件不变的状况下，咱们无奈否定这样做是会放慢你的速率，但这其实是一个短期收益和长期收益的取舍，而这个短期可能比你设想中要短的多。
从这个图里能够看到，如果代码始终放弃高质量，开发速率将在几周后超过外部品质不太好的代码，这个后果来自于 Martin Fowler 和他认为资深共事的经验的总结。
和大多数人一样，我在最开始对这份数据持狐疑态度，直到我现在我参加或间接见证了几个有意思的我的项目。
六边形兵士
.png)
这是一个从起我的项目就汇集了一众大佬的明星团队，哪怕在客户的各种胡搅蛮缠下大家对于工程实际和软件品质的要求都很高。我所学习到的停留在书本上的麻利实际在这个组都能看到。我在这里体验了极限编程、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 大叔在《麻利整洁之道》一书中对麻利勇气价值观的解释来完结这篇文章。
勇气 —— 换句话说, 就是 在正当范畴内敢于冒险。麻利团队的成员并不太关注公司政治意义上的“平安”，那会导致就义品质和机会。他们意识到，长期来看，管理软件我的项目的最佳办法是具备肯定水平的侵略性。
勇气和鲁葬是有区别的。部署最小的功能集须要勇气。保护高质量的代码和高质量的纪律须要勇气。然而，部署你本人都没有信念的代码，或者设计不具可持续性的代码，这就是莽撞。通过就义品质来恪守时间表就是莽撞。
品质和纪律会进步速度，这是一种信念，强势但童稚的人们在面对工夫压力时会一直挑战这种信念，因而保持正确的信念须要勇气。