讓軟體邁向可維護性

軟體應滿足一些品質需求（quality requirement），才能被使用者、開發者和利害關係人視為高品質（high quality）。可維護性（maintainability）就是其中一種品質需求。

如果我說，從某個角度來看，「可維護性」這個品質屬性比「功能性」還來得重要，而且我們甚至應該看重軟體設計的「可維護性」凌駕於所有一切，你會有什麼想法？

可維護性是什麼意思？

身為軟體架構師，我們設計我們的軟體，以滿足對於該軟體來說「最重要的品質需求」。針對高吞吐量（high-throughput）的交易應用程式（trading application），我們可能會專注於「可擴展性」和「可靠性」。針對處理個人身分識別資訊的應用程式，我們可能需要著重於「安全性」。

筆者認為將「可維護性」與「其它的品質需求」混為一談是不正確的，因為「可維護性」有其特殊性。如果軟體是可以維護的，那就意味著它容易改變。如果它容易改變，那麼它就是「靈活」（有彈性）的，且可能是「模組化」的。這也可能是有「成本效益」的，因為容易改變意味著變更的成本不高。如果它是可以維護的，我們或許可以讓它演變成可擴展、安全、可靠，且效能優異（如果需要的話）。我們可以改變軟體，使其與其他系統具有「可互通性」，因為它很容易改變。最重要的是，「可維護性」代表「可測試性」，因為可維護的軟體很可能是由「更小且更簡單的元件」設計而成的，這讓測試變得容易。

可維護性能夠實現功能性

如果你問產品人員，在軟體專案中什麼是最重要的，他們會告訴你，軟體為其使用者提供的價值（value）是最重要的事情。

所以，我們的軟體需要提供價值。但是它不應該為了提供價值，而以「可維護性」作為代價。想想看，在一個你可以輕鬆變更的軟體系統中添加功能，相較於一個你必須逐行與程式碼搏鬥的軟體系統，效率和成就感會有多大的不同！我很確定，讀者一定參與過那樣的軟體專案，其中有太多的雜訊和繁複的儀式，以致於要建置一個「你認為只需要幾小時就能完成的功能」，卻需要花費數天甚至是數週的時間。

以這種方式來看，「可維護性」是「功能性」的主要支持者。可維護性不佳，意味著隨著時間的推移，功能性的變更成本只會越來越高。

在一個可維護性不佳的軟體系統中，功能變更的成本很快就會變得如此昂貴，導致變更成為一種痛苦。產品人員會向工程師抱怨變更成本。工程師則會辯護說，「推出新功能」一直都是優先於「提高可維護性」。隨著變更成本的增加，衝突的可能性也會跟著提升。

可維護性就像是一種潤滑劑。它與變更成本成反比，因此，它也與衝突的可能性成反比。你有沒有想過增強軟體的可維護性，以避免衝突？我認為那本身就是一項很好的投資。

我們應該持續關心「我們正在建置的軟體」的可維護性，以免它變成令人避之唯恐不及的一團大泥球（big ball of mud，即龐雜系統）。

這是否意味著，我們在開始寫程式之前，需要花費大量時間來規劃一個可維護的架構？我們需要進行常被認為是一種瀑布式開發方法的BDUF（big design up　front，前期大設計）嗎？不，我們不需要。但是，我們確實需要做一些前期設計（some design up-front，或許我們應該稱之為SDUF ？），藉此在軟體中種下一顆「可維護性」的種子，隨著時間的推移，這可以讓架構在需要的時候更容易演進。

前期設計（up-front design）的其中一部分，就是選擇一種架構風格，來定義「我們正在建置的軟體」的設計方向。本書將幫助你決定Clean Architecture（或是轉接埠與轉接器／六角形架構）是否適合你的情境。

可維護性能支援做出決策

在建立軟體系統時，我們每天都在解決問題。對於我們遇到的大多數問題，都有不止一種解決方案。我們必須做出決策，選擇其中一種解決方案。

我們該複製這段程式碼，來建立我們的新功能嗎？我們要自己建立物件，還是使用依賴注入框架？我們應該使用重載建構子（overloaded constructor，又譯多載建構子）來建立這個物件，還是應該建立一個產生器（builder）？

許多這樣的決定，我們甚至都不是有意識地做出的。我們僅憑直覺，套用我們曾經用過、認為在當下情況或許可以行得通的模式或原則，例如：

● 發現程式碼重複（code duplication）時，應用 DRY（don't repeat yourself，不要重複自己）原則。

● 使用依賴注入（dependency injection），使程式碼更具可測試性。

● 引入一個產生器（builder，又譯建造者），使物件的建立更簡單。

如果我們觀察這些以及許多其他著名的模式，它們的效果（effect）是什麼呢？在許多情況下，主要的效果是它們使未來的程式碼更容易變更（也就是說，它們使它更易於維護）。可維護性已經內建於我們每天自動做出的許多決策當中！

即使在無法套用罐頭模式（pre-canned pattern，即預先準備的模式）的情況下，面對更困難的決策時，我們也可以利用這個原則：『每當我們需要在多種選項之間做出抉擇時，我們可以選擇未來更容易修改程式碼的那一個。』 不再需要為不同的選項感到苦惱。我們只需選擇最能提高可維護性的選項。

如同大多數的原則，這當然只是一種概括。在特定情境下，正確的決定可能是選擇那些不提升可維護性（甚至是降低可維護性）的選項。但作為一個預設的、可以有所依據的規則，選擇提升可維護性仍是「簡化」日常決策的一項可靠指引。

維護可維護性

好吧，我假設你相信我，即可維護性對開發者樂趣、生產力和決策能力有積極的影響。但我們如何知道，對code base（程式庫）所做的更改會不會增加（或至少不會降低）可維護性？我們如何隨著時間管理可維護性呢？

這個問題的答案是建立並維護一種架構，使得建立「可維護的程式碼」變得容易。一個良好的架構讓瀏覽code base 變得容易。在一個易於瀏覽的code base 中，修改既有功能或添加新功能簡直易如反掌。應用程式元件之間的依賴關係清晰且不混亂。總結來說，良好的架構提升了可維護性。

進一步來說，優良的架構能提升開發者樂趣、開發者生產力、開發者留任率，以及決策能力。我們可以繼續找出更多直接（或間接）受到「軟體架構」影響的事物。

這種相關性意味著我們應當深思熟慮，即我們如何組織程式碼的結構。我們如何將程式碼檔案分組為元件？如何管理這些元件之間的依賴關係？哪些依賴關係是必要的，哪些應該避免，以保持codebase 易於變更？這讓我們進入了本書的主軸。本書展示了一種讓程式碼容易維護的結構。本書描述的架構風格是實作Clean Architecture／六角形架構的一種方式。然而，這種架構風格並非解決建置軟體的所有問題的萬靈丹。

筆者鼓勵讀者利用從本書學到的知識，將它們付諸實踐，嘗試這些想法，修改它們，讓它們適應你的需求，然後將它們加入到你的工具箱內，並在特定的情境中靈活運用它們。（本文摘錄整理自《Clean Architecture實作篇》第一章，博碩文化提供）

圖片來源_博碩文化

 書名  Clean Architecture實作篇：在整潔的架構上弄髒你的手（第二版）

Tom Hombergs／著；錢亞宏、盧國鳳／翻譯；錢亞宏／審校

博碩文化出版

定價：600元

圖片來源_Tom Hombergs

 作者簡介 

Tom Hombergs

是軟體工程師、作家、奉行簡單主義的阿宅。複雜度就是他的死對頭，所以他致力於將複雜的東西簡化成容易消化的碎片。如果他能夠理解，那麼其他人也能夠理解。他簡化程式碼及文字，並撰寫讓人可以輕鬆閱讀的文章、書籍和開發文件。Tom目前在澳洲雪梨的Atlassian工作，負責Atlassian開發者使用的技術堆疊的DX(開發者體驗)。