導語

本文為《Quality Wall to Protect Developers Against Stress and Fear》文章的內容摘要，1200字帶你領略質量墻的魅力，完整版本，敬請期待。

作者：Yegor Bugayenko譯者：徐毅前言

程序員到底應該為所寫軟件的質量擔負多大的責任？有人認為程序員應該為產品負責，也有人認為程序員的主要責任是交付速度，項目質量是項目要去考慮的問題。

程序員編寫軟件的過程中，會創(chuàng)造有缺陷代碼或“Bug”。軟件項目的主要目標之一就是在提升質量的同時減少Bug數量。手工測試和同行評審等常用方法都是等代碼里已經出現了Bug才去尋找，過于被動。采取預防措施提升代碼質量的代價更低，也更為人所青睞。

“招募更好的程序員”是最為流行的一種方法，我們都認為更專業(yè)、更昂貴和更有才干的程序員能夠寫出沒有錯誤的代碼。然而，真相并非如此。正如Kaner等人所言，“程序員相互之間存在著巨大的差異，但沒有誰的工作是不會出錯的”。

責備那些產出了Bug的程序員們，是另一種同樣備受質疑的方法。其負面影響廣為人知，弊遠大于利，導致程序員們壓力越來越大、工作越來越慢、拋出更多代碼，被稱之為“恐懼驅動開發(fā)”。但正如Evans知名博文“恐懼讓你成為更糟的程序員”所言，對軟件開發(fā)來說，恐懼只會讓我們事與愿違。

打造“質量墻”

所有程序員都會犯錯，但他們不應該因此而被責罰。該如何解開迷局呢？該怎么做才能夠減少代碼缺陷、同時允許程序員隨意犯錯呢？辦法是有的。別為了代碼質量責怪他們，讓項目去關注質量、讓程序員能夠無所畏懼地全速編碼，效果好得不是一點點。辦法就是打造一面強大的、自動化的“質量墻”，守護其代碼基。墻越強大，程序員就越覺得安全。

首先，他們將在自己的“特性分支”上修改代碼和犯錯誤；其次，向主代碼基提出合并代碼變更，建議采取拉取請求的方式；第三，質量墻將驗證這些變更，如果發(fā)現任何新錯誤就會拒絕合入；最后，只要作者移除掉所有錯誤，質量墻就會合入這些變更。

如何構建這堵“墻”

軟件項目可以采取如下一些技術性和組織性的措施來構建這樣的質量墻，并保護源代碼不被程序員們所破壞。

自動化構建

單元測試和集成測試

強制覆蓋率閾值

變異覆蓋率閾值

強制靜態(tài)分析

多步驟代碼評審

只讀主干分支

“質量墻”讓程序員快速交付，保護項目

讓程序員在合并前備受折磨的障礙還有很多。Nygard在他的《發(fā)布！軟件的設計與部署》書中給出了建議。測試失敗？拒絕。Lint有告警？拒絕。集成測試導致構建失敗？拒絕。換句話說，拒絕變更的動作越快速越便宜，給項目帶來的好處也越大。問題是，如果流程和代碼倉有這么多限制，一個程序員怎么做到更快速地交付呢？如果質量墻已經罩住整個項目，那么如下這些技巧，不管誰用都能受益：

提交更小變更

以退為進

別害怕搞破壞

隔離變更

如果項目和程序員之間存在利益沖突，那就能創(chuàng)造出高質量的產品并迅速發(fā)展。項目可以強化質量，而程序員也可以提交代碼向前進、快速頻繁地完成變更。但不幸的是，大多數項目都與之背道而馳，他們將質量控制權交予程序員，滿心期盼程序員們會“不作惡”。而這會導致沮喪、痛苦、對犯錯的持久恐懼、長時間的拖延、責備和羞辱。最終，項目及其程序員兩敗俱傷。

快快建好質量墻吧，它既保護了程序員，也保護了項目。

原文標題：這本書終于有人翻譯了！“程序員到底應該為所寫軟件的質量擔負多大責任？”

文章出處：【微信公眾號：華為開發(fā)者社區(qū)】歡迎添加關注！文章轉載請注明出處。