軟體開發要品質還是要效率？
- 2019 年 11 月 29 日
- 筆記
品質和效率似乎永遠都是一對冤家，儘管我們都希望既有品質，又有效率。
把「品質」當做宗旨的企業，通常都有一系列的規章制度，甚至是繁重且冗餘的流程用來約束軟體開發過程中種種「有意」或「無意」的威脅軟體品質的行為。
把「效率」當做宗旨的企業，通常其內部並無嚴格的規章制度，甚至寬鬆到一個人都可以輕鬆地完成從刪庫到跑路。
從事IT行業的相關人員大多知道，軟體開發不同於一般性的勞動，它並不能單純地增加人手就能縮減開發周期，也就是說一個軟體1個人開發需要10天，這並不意味著10個人就可以1天開發完成。並且在軟體開發的過程中，由於需要「適應市場的快速發展」，常常伴隨需求變更等不可預知的問題。也就是在前期所做的工作可能因為某個需求而全部推倒重來。
下面從要品質還是要效率兩個方面來闡述，不同的側重點所帶來的的問題。
我們首先假設，公理P1：作為IT行業的從業者（開發、測試、產品等）都知道，軟體開發具有一定的不可預知性。
那麼在這個前提下，傾向於「品質」的企業通常情況下有以下做法：
- 通過規章制度讓軟體開發具有一定的可預知性
讓軟體開發具有一定的可預知性，這種方式有很多種實現，比較常見的手段是讓需求變更的成本上升。一旦進入開發階段（含設計階段），需求不得隨意變更，這種方式對開發人員相對比較友好，開發人員不再被隨意變更的需求所打擾，但同時也對產品經理提出了更多的要求。這要求產品經理需要有高超的業務能力，以及一定的前瞻性。除了讓需求變更的成本上升以外，通常也會在前期做大量的工作，包括需求評審、文檔設計、設計評審等會議，在軟體開發的中後期不斷地進行程式碼評審等工作。這一系列的規章制度流程，能使得軟體開發不再隨心所欲，而是有章可循。顯而易見，這樣「傳統」的開發形式，勢必帶來效率的下降。例如我曾經見過有的公司，一年最多發布2個版本。這在如今快速的互聯網發展中是不可接受的。
而傾向於「效率」的企業，也就是通常所說的互聯網公司對於效率的提升通常採取以下手段：
- 通過縮短開發周期使軟體開發具有一定的可預知性
目前在部分互聯網公司所倡導的「敏捷開發」實際上就是通過縮短開發周期來使軟體具有一定的可預知性。我們在開頭假設了了公理P1，軟體開發具有一定的不可預知性。並且開發周期越長，不可預知性越大。注重品質的公司，可能更傾向於提高需求變更的成本，而注重效率的公司則縮短開發周期。兩者都是為了使得軟體開發變得可控。但兩個不同的方式則導致了兩個不同的傾向。
縮短開發周期的確會讓效率變得更高，起碼能更快的適應市場的需求。那為什麼會說縮短開發周期會使得品質降低呢？
其實這是一個顯而易見的道理，縮短開發周期，理論上來講似乎就能縮短開發時間。10個需求需要做10天，平均1個需求不就只需要1天嗎？那麼我為了提高我的效率，快速響應市場變化，我就採取敏捷開發的方式，這樣不就既滿足了效率，同時也滿足了開發時間，這樣的做法似乎並不會降低軟體開發的品質。這麼想的通常是沒有從事過技術研發的同學。仍然回到公理P1，軟體開發具有一定的不可預知性。我在做當前開發的時候，所採取的的設計基本上只適用於當前的業務模型，對於未來幾乎一無所知。隨著系統不斷地快速迭代，一次又一次的在原有的系統上疊加新的功能修改刪除舊的功能。這對於軟體開發者可以說是災難性的，沒有哪一個系統架構師能遇見未來的所有可能。「天下武功唯快不破」，快是快了，程式碼後院也快起火了。
天底下沒有公司敢說我不注重品質，我只注重效率。無論是什麼公司都會採取以下手段去保證軟體品質。
- 通過一定的經濟利益懲罰手段
一定的懲罰手段，簡單粗暴地將開發人員的bug數與績效掛鉤。不過直接將bug數與績效掛鉤的情況比較少，大多情況是bug的reopen次數，以及是否有新引入的bug。其中reopen是較為常見的一種懲罰手段，同樣也能較好地推動軟體品質提升。
事實上，並沒有哪一種絕對完美的兼顧了品質和效率，對於目前的互聯網公司大多所採用的是快速迭代的開發方式。但這並不代表採用這種方式的公司品質就一定低下。
「快速適應市場的變化」這本身也是一種需求，採取快速迭代的方式實際上也是為了滿足這一「需求」。阿里巴巴集團CTO行癲曾談到過，「最早，業務比技術跑的快，技術一直追業務，因為業務增長實在太快了。前兩年我覺得是技術推動業務，特別是人工智慧興起的之後，包括我們程式化交易、廣告平台、千人千面、推薦、搜索大量用演算法和AI，包括客服等等大量用數據智慧在驅動業務」1。
「業務比技術跑得快」，這意味著一定一個快速迭代的過程。而後來「技術推動業務」，意味著技術走在了業務的前面，反倒是技術追著業務打。這其中儘管並未提及品質，但我認為技術能推動業務不斷向前跑，一定是因為有堅實的技術後盾做支撐，而堅實的技術後盾也就意味著有超高的軟體品質。
所以，在品質與效率的權衡利弊平衡中，不妨回過頭來重新審視技術的重要性。在滿足「市場快速變化」這一需求的同時，不要忘記技術也會負債，欠得越多越不牢靠。
