導(dǎo)語

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

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

程序員到底應(yīng)該為所寫軟件的質(zhì)量擔(dān)負(fù)多大的責(zé)任？有人認(rèn)為程序員應(yīng)該為產(chǎn)品負(fù)責(zé)，也有人認(rèn)為程序員的主要責(zé)任是交付速度，項目質(zhì)量是項目要去考慮的問題。

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

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

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

打造“質(zhì)量墻”

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

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

如何構(gòu)建這堵“墻”

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

自動化構(gòu)建

單元測試和集成測試

強(qiáng)制覆蓋率閾值

變異覆蓋率閾值

強(qiáng)制靜態(tài)分析

多步驟代碼評審

只讀主干分支

“質(zhì)量墻”讓程序員快速交付，保護(hù)項目

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

提交更小變更

以退為進(jìn)

別害怕搞破壞

隔離變更

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

快快建好質(zhì)量墻吧，它既保護(hù)了程序員，也保護(hù)了項目。

原文標(biāo)題：這本書終于有人翻譯了！“程序員到底應(yīng)該為所寫軟件的質(zhì)量擔(dān)負(fù)多大責(zé)任？”

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