圖片來源: 

iThome

番茄、黃瓜等作物需要背後支架作為支撐,才能順利往上長,而企業想要繼續蓬勃發展,撐起其運作背後的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)的概念。他表示,許多人認為捨棄既有程式碼,便意味著失敗,「但現在你能寫出最好的程式碼,往往幾年後也會被捨棄。」

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

熱門新聞

Advertisement