軟體架構的挑戰 - 重新思考 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）是彙整許多常見的物件導向設計方式整理而成，要設計一個好的架構，需要累積大量非常細節的實作經驗，以及對該產業的需求理解，才能夠將許多瑣碎的知識，歸納成一個大方向，用於規範開發人員的行為，來確保軟體不會任意發展。

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