蒼時弦也
蒼時弦也
資深軟體工程師
發表於

軟體架構的挑戰 - 重新思考 Rails 架構

這篇文章是 重新思考 Rails 架構 系列的一部分。

約 2010 年左右,我開始接觸到許多程式語言的社群、研討會,因此大量吸收許多軟體開發的知識。當時,在業界中一個很常被提到的職稱「架構師」對當時還是學生的自己似乎有點遙遠。而我直到十多年後,才意識到「架構」的意義。

何為架構

要用一句話來說明,我認為用「實作軟體的規範」描述相對具體一些,跟「設計」不同的地方在於,架構通常是很粗略的,不會告訴你細節。

在 2023 年決定以架構為主題投稿研討會時,花了不少力氣搜集資料去理解這一個概念。其中,有句話說「架構跟設計沒有明確的界線」讓我思考了不少如何去區分。

在 RubyConf TW 2023,我在簡報中用「詳細程度」來做比較,比較粗略的是架構,而非常詳細的是設計。如果有接觸過網站的視覺設計,大概就是所謂的 Wireframe(線稿)、Mockup(模型)這類差異。

架構的影響

因為架構是「難以改變」的,如同要蓋一棟房子的結構,一但決定了就很難調整。因此,對於軟體架構的選擇需要非常謹慎。

然而,現代大部分的軟體都是網路應用(Web Application),我們通常會選用 MVC 框架來進行開發,這讓我們對於架構的選擇受到很大的限制。

在我的觀點來看,框架(Framework)是基於一個或者多個架構來製作的原型,不像以架構開始需要從零開始,也不像設計決定了太多細節,因此能讓軟體開發更加迅速。

以 Ruby on Rails 為例子,他是非常知名的 MVC 框架,也就直接點出了採用 MVC 這種軟體架構的方式設計,當我們想採用 Clean Architecture(清楚架構)時,會發現 Rails 框架採用的 ActiveRecord 架構模式 跟 Clean Architecture 的一些要求是互相衝突的。

當然,這並不代表我們無法使用 Clean Architecture 而是需要做出部分調整,或者在一些地方妥協,如果不是非常其端的互斥,大多是能夠找到一個恰當的方法搭配在一起。

架構、風格、模式(Pattern)很常會在這類討論中出現,如果不是非常詳細的描述(連情境、流程都講清楚)我認為都可以看作一種架構的形式,差異只在涵蓋範圍

架構之痛

這系列的文章會以我在 2019 年左右接案發生的「痛苦過程」作為例子,來分享沒有把軟體架構處理完善時,會是怎樣的痛苦。

在這幾年,我對 Clean Architecture 進行實踐的過程中也有注意到,非常多問題是沒有親身經歷過,很難理解也不容易做出適當的規劃,這大概也是為什麼專業的架構師並不多的原因之一。

如同設計模式(Design Pattern)是彙整許多常見的物件導向設計方式整理而成,要設計一個好的架構,需要累積大量非常細節的實作經驗,以及對該產業的需求理解,才能夠將許多瑣碎的知識,歸納成一個大方向,用於規範開發人員的行為,來確保軟體不會任意發展。

換句話說,在處理軟體架構需要一種全局觀,要能夠從整體的角度去考慮軟體該如何實現。並且給予適當的規範,讓開發人員可以在一個框架內開發。