軟件開發要質量仍是要效率？

質量和效率彷佛永遠都是一對冤家，儘管咱們都但願既有質量，又有效率。

把「質量」當作宗旨的企業，一般都有一系列的規章制度，甚至是繁重且冗餘的流程用來約束軟件開發過程當中種種「有意」或「無心」的威脅軟件質量的行爲。

把「效率」當作宗旨的企業，一般其內部並沒有嚴格的規章制度，甚至寬鬆到一我的均可以輕鬆地完成從刪庫到跑路。

從事IT行業的相關人員大多知道，軟件開發不一樣於通常性的勞動，它並不能單純地增長人手就能縮減開發週期，也就是說一個軟件1我的開發須要10天，這並不意味着10我的就能夠1天開發完成。而且在軟件開發的過程當中，因爲須要「適應市場的快速發展」，經常伴隨需求變動等不可預知的問題。也就是在前期所作的工做可能由於某個需求而所有推倒重來。

下面從要質量仍是要效率兩個方面來闡述，不一樣的側重點所帶來的的問題。

咱們首先假設，公理P1：做爲IT行業的從業者（開發、測試、產品等）都知道，軟件開發具備必定的不可預知性。

那麼在這個前提下，傾向於「質量」的企業一般狀況下有如下作法：

• 經過規章制度讓軟件開發具備必定的可預知性

讓軟件開發具備必定的可預知性，這種方式有不少種實現，比較常見的手段是讓需求變動的成本上升。一旦進入開發階段（含設計階段），需求不得隨意變動，這種方式對開發人員相對比較友好，開發人員再也不被隨意變動的需求所打擾，但同時也對產品經理提出了更多的要求。這要求產品經理須要有高超的業務能力，以及必定的前瞻性。除了讓需求變動的成本上升之外，一般也會在前期作大量的工做，包括需求評審、文檔設計、設計評審等會議，在軟件開發的中後期不斷地進行代碼評審等工做。這一系列的規章制度流程，能使得軟件開發再也不爲所欲爲，而是有章可循。顯而易見，這樣「傳統」的開發形式，勢必帶來效率的降低。例如我曾經見過有的公司，一年最多發佈2個版本。這在現在快速的互聯網發展中是不可接受的。

而傾向於「效率」的企業，也就是一般所說的互聯網公司對於效率的提高一般採起如下手段：

• 經過縮短開發週期使軟件開發具備必定的可預知性

目前在部分互聯網公司所倡導的「敏捷開發」實際上就是經過縮短開發週期來使軟件具備必定的可預知性。咱們在開頭假設了了公理P1，軟件開發具備必定的不可預知性。而且開發週期越長，不可預知性越大。注重質量的公司，可能更傾向於提升需求變動的成本，而注重效率的公司則縮短開發週期。二者都是爲了使得軟件開發變得可控。但兩個不一樣的方式則致使了兩個不一樣的傾向。

縮短開發週期的確會讓效率變得更高，起碼能更快的適應市場的需求。那爲何會說縮短開發週期會使得質量下降呢？

其實這是一個顯而易見的道理，縮短開發週期，理論上來說彷佛就能縮短開發時間。10個需求須要作10天，平均1個需求不就只須要1天嗎？那麼我爲了提升個人效率，快速響應市場變化，我就採起敏捷開發的方式，這樣不就既知足了效率，同時也知足了開發時間，這樣的作法彷佛並不會下降軟件開發的質量。這麼想的一般是沒有從事過技術研發的同窗。仍然回到公理P1，軟件開發具備必定的不可預知性。我在作當前開發的時候，所採起的的設計基本上只適用於當前的業務模型，對於將來幾乎一無所知。隨着系統不斷地快速迭代，一次又一次的在原有的系統上疊加新的功能修改刪除舊的功能。這對於軟件開發者能夠說是災難性的，沒有哪個系統架構師能碰見將來的全部可能。「天下武功惟快不破」，快是快了，代碼後院也快起火了。

天底下沒有公司敢說我不注重質量，我只注重效率。不管是什麼公司都會採起如下手段去保證軟件質量。

• 經過必定的經濟利益懲罰手段

必定的懲罰手段，簡單粗暴地將開發人員的bug數與績效掛鉤。不過直接將bug數與績效掛鉤的狀況比較少，大多狀況是bug的reopen次數，以及是否有新引入的bug。其中reopen是較爲常見的一種懲罰手段，一樣也能較好地推進軟件質量提高。

事實上，並無哪種絕對完美的兼顧了質量和效率，對於目前的互聯網公司大多所採用的是快速迭代的開發方式。但這並不表明採用這種方式的公司質量就必定低下。

「快速適應市場的變化」這自己也是一種需求，採起快速迭代的方式實際上也是爲了知足這一「需求」。阿里巴巴集團CTO行癲曾談到過，「最先，業務比技術跑的快，技術一直追業務，由於業務增加實在太快了。前兩年我以爲是技術推進業務，特別是人工智能興起的以後，包括咱們程序化交易、廣告平臺、千人千面、推薦、搜索大量用算法和AI，包括客服等等大量用數據智能在驅動業務」¹。

「業務比技術跑得快」，這意味着必定一個快速迭代的過程。然後來「技術推進業務」，意味着技術走在了業務的前面，反卻是技術追着業務打。這其中儘管並未說起質量，但我認爲技術能推進業務不斷向前跑，必定是由於有堅實的技術後盾作支撐，而堅實的技術後盾也就意味着有超高的軟件質量。

因此，在質量與效率的權衡利弊平衡中，不妨回過頭來從新審視技術的重要性。在知足「市場快速變化」這一需求的同時，不要忘記技術也會負債，欠得越多越不牢靠。

這是一個能給程序員加buff的公衆號 （CoderBuff）

---

1. 《鈦媒體獨家對話行癲：最詳解密阿里雲頂層設計和底層邏輯》↩