前言
宜未雨而绸缪，毋临渴而掘井
程序员大多是重技能而轻规范的，因为要出活快，要抢占市场，要快速迭代..
这些都没错，但从长远来看，不去管质量真的让我们的开发效率更高效了吗？
场景
死海效应
文档的编写一直是老生常谈的问题，可能有人会说这个功能很简单，文档没写完我都开发完了。
是的，文档是一项耗时的事情，他是有成本的，但是互联网行业的人员变更是很频繁的，需求的变更也是很常见的，也许你接盘的需求已经有7，8个人经手过了，如果没有详细的文档沉淀，就会出现上图一样的情况，虽然不知道这段代码想干什么甚至不知道它怎么就运行起来了，但是常年踩坑的经验告诉我，此段代码非同小可，触者非伤即死，说不定会出现惊喜的bug，还是留着吧...，然后随着时间的推进，这种没头没脑的代码就形成了死海效应，后续的越来越多的需求覆盖在这个功能上，这种祖传代码就更没人肯修改了。
在前期，没有文档可能确实会快很多，但是，长期迭代的项目没有文档，你觉得还会对效率有提高吗？
改造成本
开发的生性都向往自由，各种奇技淫巧层出不穷，你有18种居中对齐的方法，我有36种颜色渐变的手段，但在多人协作的工程中，如果没有规范的约束，大家自由发挥，项目可能会像左图一样，杂乱无章，这种情况往往潜藏着兼容性bug，也许有人会说，需求这不是完成了吗，没有出现问题，为什么要听这种束缚我创造力的规则？
因为多一种实现方式，就多一种出现bug的风险，如果遵循统一的标准规范，就可以收敛出错的情况，也利于之后重构改造，健壮的代码是经得起反复改造与重构的，如果听到重构两个字，脑子里闪过一团乱麻，可能你的项目真的需要代码规范了。
代码风格
网上经常会看见诸如“用tab好还是用空格好”，“用两个空格好还是4个空格好”的问题，这种代码风格的问题有正确解吗？没有，况且也没意义。但是，在多人协作的场景下，如果代码风格不统一，就会浪费大量的时间在争论这种脑残问题与拉取代码解决格式冲突上。
其实，就像开车行驶一样，你靠左开可以，靠右开也没错，但是，每个人都随意开的话就很危险了，所以靠右行驶的规则才会诞生，目的是为了让大家开发都安全一点。
所以规范不一定是宣布谁的观点正确，而是为了降低多人协作时的无意义分歧，让大家把时间更聚焦于解决问题上面。
质量体系的作用
收敛工程复杂度的影响
随着需求的不断增多，各个模块的关系越来越复杂，往往牵一发而动全身，这时的研发效率是被复杂度所拖住的，因为工程的复杂度往往与需求的数量是指数关系。
质量体质的构建就是让大家遵守相同的规则，而相同的场景在相同的规则下具有相同的解法，这样，代码复杂度不随需求而上升，只受场景的影响，收敛工程复杂度，提升持续迭代项目的研发效率。
多人协作
在大型项目里，开发人员的能力往往良莠不济，同一个功能，可能几行代码实现，也可能被实现的又臭又硬，而代码规则就像是最佳实践的抽象，如果发现自己的代码不符合规范，说明是有代码坏味道的，可以考虑优化或者重构了，让团队成员的代码像一个人编写一般，也是代码规范的目的之一。
将bug扼杀在摇篮里
《重构》中说过，出现问题的代码往往散发着相同的bad smell。我们将各组的最佳实践与代码坏味道沉淀到规范中，并加以级别，就是为了可以提前发现隐藏的bug，如果违反了红线级别的规则，说明代码已经出现预见性的危害或严重的性能影响，而违反建议性规范，可能对现阶段没影响，但是日后的重构或是修改可能会困难重重。
结论
质量体系是整个开发流程的保护者，从需求阶段的文档保证，到开发过程中的代码规范与书写风格，最后开发结束后的code review，都是为了保证代码足够的健壮，最大程度的减少bug，方便功能的扩展。
所以，前期质量上的投入或许拖慢了研发的进度，但是，体系的建设是为了后期更快地扩展功能，避免陷入bug的泥潭中，更大程度地提升研发效率。