程序员到底应该为所写软件的质量担负多大的责任？有人认为程序员应该为产品负责，也有人认为程序员的主要责任是交付速度，项目质量是项目要去考虑的问题。
程序员编写软件的过程中，会创造有缺陷代码或“Bug”。软件项目的主要目标之一就是在提升质量的同时减少Bug数量。手工测试和同行评审等常用方法都是等代码里已经出现了Bug才去寻找，过于被动。采取预防措施提升代码质量的代价更低，也更为人所青睐。
“招募更好的程序员”是最为流行的一种方法，我们都认为更专业、更昂贵和更有才干的程序员能够写出没有错误的代码。然而，真相并非如此。正如Kaner等人所言，“程序员相互之间存在着巨大的差异，但没有谁的工作是不会出错的”。
责备那些产出了Bug的程序员们，是另一种同样备受质疑的方法。其负面影响广为人知，弊远大于利，导致程序员们压力越来越大、工作越来越慢、抛出更多代码，被称之为“恐惧驱动开发”。但正如Evans知名博文“恐惧让你成为更糟的程序员”所言，对软件开发来说，恐惧只会让我们事与愿违。
打造“质量墙”所有程序员都会犯错，但他们不应该因此而被责罚。该如何解开迷局呢？该怎么做才能够减少代码缺陷、同时允许程序员随意犯错呢？办法是有的。别为了代码质量责怪他们，让项目去关注质量、让程序员能够无所畏惧地全速编码，效果好得不是一点点。办法就是打造一面强大的、自动化的“质量墙”，守护其代码基。墙越强大，程序员就越觉得安全。
首先，他们将在自己的“特性分支”上修改代码和犯错误；
其次，向主代码基提出合并代码变更，建议采取拉取请求的方式；
第三，质量墙将验证这些变更，如果发现任何新错误就会拒绝合入；
最后，只要作者移除掉所有错误，质量墙就会合入这些变更。
如何构建这堵“墙”软件项目可以采取如下一些技术性和组织性的措施来构建这样的质量墙，并保护源代码不被程序员们所破坏。
自动化构建
单元测试和集成测试
强制覆盖率阈值
变异覆盖率阈值
强制静态分析
多步骤代码评审
只读主干分支
“质量墙”让程序员快速交付，保护项目让程序员在合并前备受折磨的障碍还有很多。Nygard在他的《发布！软件的设计与部署》书中给出了建议。测试失败？拒绝。Lint有告警？拒绝。集成测试导致构建失败？拒绝。换句话说，拒绝变更的动作越快速越便宜，给项目带来的好处也越大。问题是，如果流程和代码仓有这么多限制，一个程序员怎么做到更快速地交付呢？如果质量墙已经罩住整个项目，那么如下这些技巧，不管谁用都能受益：
提交更小变更
以退为进
别害怕搞破坏
隔离变更
如果项目和程序员之间存在利益冲突，那就能创造出高质量的产品并迅速发展。项目可以强化质量，而程序员也可以提交代码向前进、快速频繁地完成变更。但不幸的是，大多数项目都与之背道而驰，他们将质量控制权交予程序员，满心期盼程序员们会“不作恶”。而这会导致沮丧、痛苦、对犯错的持久恐惧、长时间的拖延、责备和羞辱。最终，项目及其程序员两败俱伤。
快快建好质量墙吧，它既保护了程序员，也保护了项目。