軟體開發專案中的一個常見爭論是：該不該花時間提高軟體質量，還是把時間專注於不斷髮布更有價值的新功能。通常，倡導把時間用於提供新功能的交付派別會贏得這場討論勝利，導致許多開發人員抱怨他們沒有時間研究架構和程式碼質量。

Betteridge的頭條新聞是一句諺語，意思是說任何以問號結尾的標題或文章都可以用“不”來概括。那些瞭解我的人不會懷疑我想要顛覆這樣的法律，但是這篇文章比這更進一步 - 它顛覆了問題本身。這個問題假定了質量和成本之間需要權衡。通過本文，我將解釋這種權衡並不適用於軟體 ： 高質量的軟體實際上更便宜。

雖然我的大部分寫作都是針對專業軟體開發人員的，但對於本文，我不會假設任何有關軟體開發機制的知識。我希望這篇文章對參與思考軟體工作的任何人都有價值，特別是那些充當軟體開發團隊客戶的商業領袖。

我們習慣於在質量和成本之間進行權衡

正如我在文章開始中提到的，我們都習慣於在質量和成本之間進行權衡。當我更換智慧手機時，我可以選擇更昂貴的型號，具有更快的處理器，更好的螢幕和更多的記憶體。或者我可以放棄一些這些品質來降低費用。這不是一個絕對的規則，有時我們可以在優質商品更便宜的地方買到便宜貨。更常見的是，我們對質量有不同的價值： 有些人並沒有真正注意到一個螢幕比另一個更好。但大多數時候這種假設是正確的，更高的質量通常會花費更多。

軟體質量意味著很多東西

如果我要談談軟體質量，我需要解釋一下它是什麼。這就是第一個複雜問題 - 有很多東西可以算作軟體的質量。我可以考慮使用者介面：它是否容易引導我完成我需要完成的任務，使我更有效率並消除挫折感？我可以考慮它的可靠性：它是否包含導致錯誤和挫折的缺陷？另一個方面是它的架構：原始碼是否分為明確的模組，以便程式設計師可以輕鬆找到並理解本週需要處理哪些程式碼？

這三個質量的例子並不是一個詳盡的列表，但它們足以說明一個重要的觀點。如果我是軟體的客戶或使用者，我不會理解我們稱之為質量的一些概念。使用者可以判斷使用者介面是否良好。一位高管可以判斷該軟體是否使她的工作更有效率。使用者和客戶會注意到缺陷，特別是它們會損壞資料或使系統暫時無法執行。但是客戶和使用者無法理解軟體的架構。

因此，我將軟體質量屬性劃分為外部 （例如UI和缺陷）和內部（架構）。區別在於使用者和客戶可以看到什麼使軟體產品具有高外部質量，但無法區分更高或更低的內部質量。

乍一看，內部質量對客戶無關緊要

由於內部質量不是客戶或使用者可以看到的 - 這有關係嗎？讓我們想象麗貝卡和我寫一個跟蹤和預測航班延誤的應用程式。我們的應用程式都具有相同的基本功能，兩者都具有同樣優雅的使用者介面，並且幾乎沒有任何缺陷。唯一的區別是她的內部原始碼整齊有序，而我的內容卻是混亂的。另外還有一個區別：我以6美元的價格出售我的產品，並以10美元的價格賣掉了她的產品。

由於客戶從未看到此原始碼，並且它不會影響應用程式的執行，為什麼有人會為麗貝卡的軟體額外支付4美元？更一般地說，這應該意味著不值得為更高的內部質量支付更多的錢。

我說的另一種方式是，交換外部質量成本是有意義的，但內部質量的交易成本是沒有意義的。使用者可以判斷他們是否想要支付更多費用以獲得更好的使用者介面，因為他們可以評估使用者介面是否足夠好以至於值得多花錢。但是使用者無法看到軟體的內部模組化結構，更不用說判斷它更好了。為什麼要為沒有效果的東西付出更多？既然如此 - 為什麼軟體開發人員應該花時間和精力來提高工作的內部質量？

內部質量可以更輕鬆地增強軟體

那麼為什麼軟體開發人員會因內部質量問題而解決問題呢？程式設計師大部分時間都在修改程式碼。即使在新系統中，幾乎所有程式設計都是在現有程式碼庫的上下文中完成的。當我想為軟體新增新功能時，我的第一個任務是弄清楚這個功能如何適應現有應用程式的流程。然後我需要更改該流程以使我的功能適應。我經常需要使用已經在應用程式中的資料，因此我需要了解資料代表什麼，它與周圍資料的關係以及我可能提供的資料需要為我的新功能新增。

所有這些都是關於我理解現有程式碼的，但是軟體很難理解。邏輯可能變得糾結，資料可能難以理解，六個月前用來指代事物的名字可能對Tony有意義，但對我來說和離開公司的理由一樣神祕。所有這些都是開發人員稱之為殘餘的形式 - 當前程式碼與理想情況之間的差異。

內部質量的一個主要特點是讓我更容易弄清楚應用程式的工作原理，這樣我就可以看到如何新增內容。如果將軟體很好地劃分為單獨的模組，我不必閱讀所有500,000行程式碼，我可以在幾個模組中快速找到幾百行。如果我們將精力放在明確的命名上，我可以快速瞭解程式碼的各個部分，而不必贅述細節。如果資料明智地遵循基礎業務的語言和結構，我可以很容易地理解它與客戶服務代表的請求之間的關係。

技術債務增加了我理解如何做出改變所花費的時間，也增加了我犯錯誤的可能性。如果我發現我的錯誤，那麼就會有更多的時間丟失，因為我必須瞭解故障是什麼以及如何解決它。如果我沒有發現它們，那麼我們就會遇到生產缺陷，以及以後花更多的時間來修理。

我的變化也會影響未來。我可能會看到一種快速的方式來放入這個功能，但這是一條違背程式模組化結構的路線，增加了瑕疵。如果我採取這條道路，今天我會更快地為我做準備，但是在未來幾周和幾個月裡，其他所有必須處理此程式碼的人都要放慢速度。一旦團隊中的其他成員做出相同的決定，一個易於修改的應用程式可以迅速積累到每一個小小的變化需要花費數週努力的程度。

客戶真正關注的是新功能的快速交付

在這裡，我們看到了內部質量對使用者和客戶至關重要的線索。更好的內部質量使得新增新功能更容易，因此更快，更便宜。

麗貝卡和我現在可能有相同的應用程式，但在接下來的幾個月裡，麗貝卡的高內部質量讓她每週都能新增新功能，而我卻一直試圖通過簡單的方式來獲得一個新功能。我無法與Rebecca的速度競爭，很快她的軟體就比我的軟體更具特色。然後我的所有客戶都刪除了我的應用程式，並獲得了Rebecca，即使她能夠提高她的價格。

視覺化內部質量的影響

內部質量的基本作用是降低未來變革的成本。但是編寫好的軟體需要額外的努力，這在短期內會產生一些成本。

內部質量差的事後，最初進展很快，但隨著時間的推移，新增新功能變得更加困難。即使很小的變化也需要程式設計師理解大面積的程式碼，這些程式碼很難理解。當他們進行更改時，會發生意外斷裂，導致測試時間過長，需要修復缺陷。

專注於高內部質量就是要減少生產力的下降。事實上，有些產品會產生相反的效果，開發人員可以通過利用先前的工作輕鬆構建新功能。這種快樂的情況是一種罕見的情況，因為它需要一支技術精湛，訓練有素的團隊來實現這一目標。但我們偶爾會看到它。

即使是最好的球隊也會製造技術債務

許多非開發人員傾向於認為只有當開發團隊粗心大意並且犯錯時才會發生這種事情，但即使是最優秀的團隊也會在工作時不可避免地產生一些技術累贅。

用一個當我和我們最好的技術團隊領導聊天的故事來說明這一點。他剛剛完成了一個被廣泛認為是非常成功的專案。無論是在功能，施工時間和成本方面，客戶都對交付的系統感到滿意。我們的員工對該專案的工作經驗持積極態度。技術領導者非常高興，但承認系統的架構並不那麼好。我的反應是“你怎麼可能 - 你是我們最好的架構師之一？” 他的答覆是任何一位經驗豐富的軟體架構師都熟悉的答案：“我們做出了很好的決定，但現在才明白我們應該如何構建它”。

許多人，包括軟體行業的一些人，將構建軟體比作建造大教堂或摩天大樓 - 畢竟為什麼我們為高階程式設計師使用“架構師”？但構建軟體存在於物理世界未知的不確定世界中。軟體的客戶只是粗略地瞭解他們在產品中需要哪些功能，並在構建軟體時瞭解更多資訊 - 特別是一旦早期版本釋出給使用者。軟體開發的構建模組 - 語言，庫和平臺 - 每隔幾年就會發生重大變化。物理世界中的等價物是客戶通常在建造和佔用建築物的一半時新增新樓層並更改樓層平面圖。

鑑於這種程度的變化，軟體專案總是創造出新穎的東西。我們幾乎沒有發現自己正在研究一個之前已經解決的易於理解的問題。當我們構建解決方案時，我們自然會了解到這個問題，因此我常常聽到團隊只有在花了一年左右的時間構建它之後，才能真正理解軟體的架構。即使是最好的團隊也會在他們的軟體中肆意妄為。

最好的團隊創造了更少的技術債務，但也能夠快速消除了他們，他們就可以繼續快速新增功能。他們花時間建立自動化測試，以便他們能夠快速解決問題並減少浪費時間。他們經常進行重構，以便在它們技術累贅積聚到擋路之前將它們移除。由於團隊成員在不同的交叉目的下工作，持續整合可以最大限度地減少技術債務。一個常見的比喻就是清理廚房的工作臺面和裝置。你做飯時不能弄髒東西，但是如果你不快速清理東西，淤泥乾涸，更難去除垃圾，所有骯髒的東西妨礙了烹飪下一道菜。

高質量的軟體生產成本更低

總結：

• 忽視內部質量會導致快速構建
• 這種錯誤減緩了新功能的開發
• 即使是一個偉大的團隊也會產生技術債務累贅，但通過保持內部質量，可以控制它
• 高內部質量使債務降至最低，使團隊能夠以更少的工作量，時間和成本新增功能。

可悲的是，軟體開發人員通常不會很好地解釋這種情況。無數次我和開發團隊談過，他們說“他們（管理層）不會讓我們寫出質量好的程式碼，因為它需要太長時間”。

開發人員通常需要適當的專業性來證明對質量的關注。但是，這種道德主義的論證意味著這種質量是有代價的 - 這使他們的論點失敗了。令人討厭的是，由此產生的苛刻的程式碼既使開發人員的生活更加艱難，又使客戶付出了代價。在考慮內部質量時，我強調我們只應將其視為經濟論證。高內部質量降低了未來功能的成本，

高內部質量軟體反而降低“成本”。成本和質量之間的通常權衡（這種我們習慣於生活中的大多數決策）是對軟體的內部質量沒有意義。因為成本和內部質量之間的這種關係是一種不同尋常和反直覺的關係，所以通常程式設計師很難接受，但瞭解它對於以最高效率開發軟體至關重要。