3種CTO要小心的架構技術債

番茄、黃瓜等作物需要背後支架作為支撐，才能順利往上長，而企業想要繼續蓬勃發展，撐起其運作背後的IT架構，也扮演著類似地位，例如，軟體架構、程式語言的選擇，在數位轉型、產品轉型等重大決策都有舉足輕重的地位。

而書亞集成技術長曾義峰表示，最理想的技術決策是根據團隊、公司需求，搭建出最合適的技術組合，「但現實狀況中，技術組合大多是由技術長、架構師等關鍵人物決定」，如此運作下，一家公司的技術決策，也會跟該關鍵人物的開發偏好有相當關聯。

他表示，不時聽到來自軟體社群、企業或新創公司的開發者，抱怨如此重大決定，卻只透過技術長或是外部顧問所決定，例如一舉決定放棄.NET，改為使用Java；或認為使用PHP開發步調太慢，全部改使用RoR，「這些決策未必錯，但是必須能夠讓人信服。」

而曾義峰認為，執行技術決策時，總共有三大重點。首先，必須視架構為最優先考量，「架構會影響商業文化」，同時，不能只重視技術，而忽略既有內部流程跟人員，他表示，當開發者晉身為技術長、架構師後，思維要超越程式碼層次，「不能只了解技術。」

第二要素是選擇最適合自家的架構，「完美的架構並不存在，更沒有可以套用在所有應用情境的架構」，他表示，當開發者不能列舉某架構存在的缺陷，也意味著對它不夠熟悉。最後一個要素，則是不過早改良架構，「架構必須逐漸演進」，他認為，太早追求一步到位，反而是短視近利。

設計不良的架構，將衍生出後續架構債

而設計架構時，無外乎希望能同時滿足三個條件：節省成本、具有擴展性，以及能快速進入市場。然而，一旦沒有滿足其中的任一條件，都會衍生出後續三種架構債（Architectural debt）。

第一種架構債常常出現在具備實戰經驗的技術團隊，沒有快速進入市場壓力下，通常偏好導入最新、最佳化的架構，因此，在此碰上過於架構過於早熟（Premature）的問題。而曾義峰提醒：「我們都不是AWS、Google或是臉書等大公司」，真正重要的問題在於，現階段組織的營運規模是否適合導入該架構。

再者，當開發團隊欠缺架構系統經驗時，系統就會發生缺乏延展性（Scalability）的痛點，導致程式碼不能重複使用，也很難導入高可用性架構或使用水平擴充，「在還清技術債前，只會債臺高築。」曾義峰表示。

最後一種架構債，則出現於起初推出良好商業模式的團隊，在不缺乏資金的情況下，導入品質良好的IT服務，像是使用AWS等基礎架構，執行基本的服務。曾義峰表示，只要營運狀況良好，並足夠支撐這些基礎架構的費用並非壞事，「而一旦後續募資沒有成功，只好裁員節省成本。」

曾義峰觀察，以上3種架構設計時出現的痛點，最常出現的是系統缺乏延展性，其彈性不足以支撐業務成長，即使想要增加硬體、水平擴充時，「系統架構也不允許，導致升級很困難。」

碰上這些挑戰，曾義峰表示，導入最小可行性產品（Minimum viable product，MVP）的觀念也是一種解決方法。此概念就是迅速將產品推上市場，驗證產品理念是否有符合市場需求。他比喻，就像最初先推出滑板這個最基本的商品，再陸續讓產品功能趨於完整，演進至腳踏車、摩托車甚至汽車，「每階段的產品都推上市場中試驗。」

但是，「如果MVP沒有控制好，技術債會迅速成長」，曾義峰表示，由於每階段產品都面臨許多變更，老舊程式不容易清除，導致程式碼很難重複利用。外界亦有部份人認為，當產品通過市場驗證後，再利用投資人的提供資金，作為技術轉型所需的支出即可。但他認為，處在迅速成長階段的新創公司，並沒有過多時間進行技術轉型，「因為投資人或高層主管都希望盡快將產品推上市場」，不僅如此，除了原型產品離進入正式環境還有一大段距離外，先前快速推出產品也會遺留許多技術債，「只會讓轉型變得更加困難。」

推動MVP時，必須設定技術債的上限值

因此，在推動MVP時，曾義峰建議，必須設定技術債的上限值，當開發團隊發現超過上限值時，得著手清除技術債。不過，「現實往往是債臺高築」，特別當開發團隊中沒有敏捷教練或架構師，或公司正處產品轉型的階段時，特別容易碰上這樣的痛點。

面臨龐大技術債的壓力，「即使找上大神，他們也覺得頭痛」，碰上系統架構重構的挑戰，曾義峰提出了3種解決方法。他利用位於空中的飛機，比喻營運不停機的企業，而飛機引擎就是支撐企業營運的系統架構。

「第一種解決方法是空中換引擎」，在企業成長的同時，一併進行技術轉型。但曾義峰表示，落實此方法的難度相當高，因為位處高度成長的企業，不僅許新業務需求必須被滿足，更有許多先前累積的技術債得清償。

第二種做法是「落地換引擎」，企業暫時停止開發新功能，全心投入技術轉型，雖然此種作法的技術難度低，但曾義峰也提醒，此方法必須衡量該公司商業模式是否適合，「允許新功能推出的步調慢，甚至無進展。」

最後的方式則是「空中小修，地面重建」，現階段仍然繼續投入開發新功能，逐步清償技術債，等待時機成熟再數位轉型。

而曾義峰解釋，此決策必須投入許多資源。在落實時，得要將現有團隊拆分成不同工作分組，或是另聘團隊投入新架構的建置，「但如果沒有解決本質的問題，未來新架構也會碰上一樣的問題。」

需求永遠不明確，因此系統架構得要具有彈性

碰上棘手的技術債，業界也出現了許多解決方法，像是敏捷開發、DevOps、測試驅動開發（Test-Driven Development），「這些方法都是在解決概念完整性（Conceptual Integrity）的問題」，曾義峰表示，如果沒有解決此問題，導致各方對產品的想法存在落差，後續工作將出現許多疑難雜症。例如，需求方與開發方溝通不順，需求方並沒有提出足夠詳細的規格書，導致開發者無法實作部分功能，滿足該方需求。

肇因溝通不良，導致需求永遠不明確的困境。對此，曾義峰表示，溝通應該是雙向，除了需求端提出要求外，開發方應該也要化被動為主動，提出回饋。

不僅如此，開發者也得讓系統架構更有彈性，當需求改變，導致程式設計有改變時，「預想但是不過早優化，不該把每次的新需求都視作獨立需求。」

曾義峰舉例，當業主提出開發需求，要求受眾在一天內不要看到重複的廣告。而這個看似簡單易懂的需求，其中就隱含了許多變數的操作空間，像是時間顆粒度，仍可繼續向下切分。因此，曾義峰建議，當需求方提出規格時，開發者不該只單線式思考，反之，「要使用抽象化思考的模式，仔細剖析該需求中，存在著哪一些變數。」

不過，即使架構設計的再如何完善，終有一天必須被拋棄。Thoughtworks首席科學家Martin Fowler就提出了一個犧牲架構（Sacrificial Architecture）的概念。他表示，許多人認為捨棄既有程式碼，便意味著失敗，「但現在你能寫出最好的程式碼，往往幾年後也會被捨棄。」

曾義峰也表示，即使必須捨棄現有架構，未必是一件失敗的事，重點在於清楚必須放棄的理由，以及新架構該如何執行、何時執行，「清楚明白打掉重練比較好，就勇敢執行吧！」他表示。