ThoughtWorks 首席科學家 Martin Fowler 指出,軟體開發項目中存在一種常見爭論,即「花時間提高軟體質量,還是專註於發布更有價值的功能?」他認為「提供功能的壓力常常主導著討論,導致許多開發人員抱怨他們沒有時間研究架構和代碼質量」。於是,Martin 近日在個人博客發布了一篇名為《高質量軟體值得這麼多成本嗎?》的文章,就此展開討論。
通常,這樣的反問句答案顯然是否定的。不過,Martin 接下來的闡述進一步顛覆了問題本身,這個問題假定了質量和成本之間的共同權衡,可在他看來,這種權衡並不適用於軟體——「高質量的軟體實際上生產成本更低」。
這種說法是否顛覆了你的認知?人們習慣於在質量和成本之間進行權衡,「一分錢一分貨」不無道理。當然,Martin 承認該假設在大多數情況下是正確的,更高的質量會花費更多。但他強調這並非一個絕對規則。
Martin 首先對「軟體質量」做出了界定。有很多方面可以囊括在內:用戶界面清晰嗎?軟體足夠可靠嗎?架構合理、明確嗎?
用戶可以判斷用戶界面是否良好;高管可以判斷軟體是否使工作更高效;消費者會注意到系統缺陷,特別是當軟體出故障時。但用戶可能無法體會軟體架構——這對開發者來說是軟體質量的判定標準之一。
所以,這篇文章將軟體質量屬性劃分為外部(例如 UI 和缺陷)和內部(架構)。區別在於,用戶和消費者可以看到軟體產品具有高外部質量的原因,卻難以分辨出內部質量的高低。
用戶可以判斷他們是否想要支付更多費用以獲取更好的用戶界面,但對於內部模塊化結構難以做出判斷。試想一下,如果有兩個近乎完全相同的應用程序,一個賣 6 美元,另一個售價 10 美元,區別僅僅在於後者的源碼整齊有序而前者較為混亂。這並不影響程序正常運行,客戶為何要多花 4 美元購買後者?既然如此,為什麼軟體開發人員還要花時間和精力來提高工作的內部質量?
Martin 在此引出了「技術債務」(Technical Debt)的概念。由於代碼混亂而造成的難以清理的殘餘項(cruft)便是積累技術債務的罪魁禍首,為增加新功能所付出的額外努力則是債務利息。
如果模塊結構足夠清晰,假設添加一個新功能需要四天時間,但由於邏輯混亂或數據難以理解等代碼規範問題,這一工作可能將會被延長至六天。
這些繁瑣的部分不僅會更加耗費開發人員的時間和精力,也加大了出錯的可能性,那麼以後將需要花費更多成本來進行修補。
由此看來,內部質量實際上對用戶來說也至關重要。因為更好的內部質量使得添加新功能更快、更容易,成本也更低。
Martin 表示,「內部質量的基本作用是降低未來變革的成本。但是編寫好的軟體需要額外的努力,這在短期內會產生一些成本」。為此,他提供了兩張圖表,以可視化的方式來呈現將內部質量的影響。
上圖是軟體內部質量較差的情況。可以看到,在最初一段時間,工作進展很快,但隨著時間的推移,添加新功能變得愈發困難。這也是大多數軟體工作的境況。
專註於高內部質量很可能造成生產力下降,但開發人員可以通過利用先前的工作輕鬆構建新功能。這一目標需要一支技術精湛,訓練有素的團隊來實現。
加上高內部質量的曲線之後,一些微妙之處顯現出來:前期低內部質量比高內部質量的軟體更具有生產力,在此期間,質量和成本之間存在某種權衡關係。問題是,它能持續多久?
Martin 綜合參考了一些熟練開發者的意見,發現質量差的代碼會在幾周內顯著降低生產速度,擁有高內部質量的軟體隨後遠遠反超。因此,從長遠看來,不必太費心思在質量與成本之間權衡。
即使是最優秀的團隊也會在工作時不可避免地產生一些無用且瑣碎的東西(cruft)。
許多人將構建軟體比作建造摩天大樓,想想為什麼高級程序員被稱為「架構師」?但軟體構建於物理世界未知的不確定世界中,軟體開發的構建模塊——語言、庫和平台——每隔幾年就會發生重大變化。鑒於這種程度的變化,軟體項目總是創造出新穎的東西。Martin 說他常常聽到團隊只有在花了一年左右的時間構建它之後,才能真正理解軟體的架構。即使是最好的團隊也會在他們的軟體中肆意妄為。
不同的是,好的團隊即使創造了垃圾,也能及時清理掉它們,他們可以繼續快速添加功能。此外,他們還會花時間創建自動化測試,也經常進行重構,以便快速解決問題、清理殘餘。
Martin 用清理廚房來比喻這項工作:做飯時如果不快速清理檯面污漬,之後更難去除,所有骯髒的東西會妨礙烹飪下一道菜。
總結一下:
一些開發團隊向 Martin 訴苦:「管理層阻礙我們寫出質量好的代碼,因為它需要花費太長時間」。對此 Martin 再次呼籲,高內部質量實際上降低了未來成本,了解內部質量與成本之間的關係對於以最高效率開發軟體來說至關重要。
[admin
]