摘要： 快快建好品质墙，既能爱护程序员，也爱护我的项目。
前言
程序员到底应该为所写软件的品质负担多大的责任？有人认为程序员应该为产品负责，也有人认为程序员的次要责任是交付速度，我的项目品质是我的项目要去思考的问题。
程序员编写软件的过程中，会发明有缺点代码或“Bug”。软件我的项目的次要指标之一就是在晋升品质的同时缩小 Bug 数量。手工测试和同行评审等罕用办法都是等代码里曾经呈现了 Bug 才去寻找，过于被动。采取预防措施晋升代码品质的代价更低，也更为人所青眼。
- “招募更好的程序员”是最为风行的一种办法， 咱们都认为更业余、更低廉和更有才干的程序员可能写出没有谬误的代码。然而，假相并非如此。正如 Kaner 等人所言，“程序员相互之间存在着微小的差别，但没有谁的工作是不会出错的”。
- 指责那些产出了 Bug 的程序员们，是另一种同样备受质疑的办法。 其负面影响广为人知，弊远大于利，导致程序员们压力越来越大、工作越来越慢、抛出更多代码，被称之为“恐怖驱动开发”。但正如 Evans 出名博文“恐怖让你成为更糟的程序员”所言，对软件开发来说，恐怖只会让咱们大失所望。
打造“品质墙”
所有程序员都会犯错，但他们不应该因而而被责罚。该如何解开迷局呢？该怎么做才可能缩小代码缺点、同时容许程序员随便犯错呢？方法是有的。别为了代码品质嗔怪他们，让我的项目去关注品质、让程序员可能无所畏惧地全速编码，成果好得不是一点点。方法就是打造一面弱小的、自动化的“品质墙”，守护其代码基。墙越弱小，程序员就越感觉平安。
首先，他们将在本人的“个性分支”上批改代码和犯错误；
其次，向主代码基提出合并代码变更，倡议采取拉取申请的形式；
第三，品质墙将验证这些变更，如果发现任何新谬误就会回绝合入；
最初，只有作者移除掉所有谬误，品质墙就会合入这些变更。
如何构建这堵“墙”
软件我的项目能够采取如下一些技术性和组织性的措施来构建这样的品质墙，并爱护源代码不被程序员们所毁坏。
- 自动化构建
- 单元测试和集成测试
- 强制覆盖率阈值
- 变异覆盖率阈值
- 强制动态剖析
- 多步骤代码评审
- 只读骨干分支
“品质墙”让程序员疾速交付，爱护我的项目
让程序员在合并前备受折磨的阻碍还有很多。Nygard 在他的《公布！软件的设计与部署》书中给出了倡议。测试失败？回绝。Lint 有告警？回绝。集成测试导致构建失败？回绝。换句话说，回绝变更的动作越疾速越便宜，给我的项目带来的益处也越大。问题是，如果流程和代码仓有这么多限度，一个程序员怎么做到更疾速地交付呢？如果品质墙曾经罩住整个我的项目，那么如下这些技巧，不论谁用都能受害：
- 提交更小变更
- 以退为进
- 别胆怯搞破坏
- 隔离变更
如果我的项目和程序员之间存在利益冲突，那就能发明出高质量的产品并迅速倒退。我的项目能够强化品质，而程序员也能够提交代码向后退、疾速频繁地实现变更。但可怜的是，大多数我的项目都与之南辕北辙，他们将品质控制权交予程序员，满心期盼程序员们会“不作恶”。而这会导致丧气、苦楚、对犯错的长久恐怖、长时间的迁延、指责和羞辱。最终，我的项目及其程序员两败俱伤。
快快建好品质墙吧，它既爱护了程序员，也爱护了我的项目。
点击关注，第一工夫理解华为云陈腐技术~