一個系統能跑，不代表它真的適合一直長大

💡 一個系統能跑，不代表它真的適合一直長大

這件事情其實是我這幾年越來越有感的一件事。

大概七、八年前從廈門做 ERP 回台灣之後，我陸續接過不少不同類型的專案。

很多其實都不算什麼超大型系統，比較像是：

有需求，就把功能做出來； 有下一個需求，再繼續往上加。

久了之後就會變成一種很常見的狀況：

功能都有，系統也能跑，但東西散得到處都是。

各種資料夾、共用方法、業務邏輯、DB 操作、Log、Cache……

你說這樣「錯」嗎？

老實說，站在使用者角度可能根本沒差。

使用者不會管你 Log 怎麼寫、Cache 放哪、資料庫怎麼存取，他只在意：

「功能能不能用？」

但問題通常都是在系統開始長大之後才跑出來。

🧩 我自己後來會很堅持一件事：

至少、至少，要先分得出「系統核心」跟「業務功能」這兩層。

再往後，如果這是一套產品，本身還有標準版、客製版，甚至不同客戶有不同延伸，那才會再去考慮第三層，也就是我後來在用的 SpecFeature。

為什麼我要這麼麻煩？

因為有些東西，本來就不應該每個 Feature 自己寫一套。

例如：

Log、Cache、DB 存取。

這些本質上比較像「整個系統共用的能力」，不是某一個業務 Domain 專屬的邏輯。

但如果沒有先把這層切開，很容易發生兩件事。

1️⃣ 一直重複寫

今天做 A 功能寫一次，明天做 B 功能又來一次。

最後不是 Copy Paste，就是每個人寫出自己的版本。

2️⃣ 每一份都開始長得不一樣

A 有補 Log。 B 忘了。 C 用一套 Cache 邏輯。 D 又是另一套。

一開始看起來都只是一些小差異。

但等到真的出問題，要下手改的時候，就會進入一種很熟悉的狀態：

「嗯，我大概知道問題在哪。」

然後 Code 打開。

「……這一坨到底怎麼改啊 ˊ_>ˋ」

原本覺得一小時可以改掉的東西，開始查誰有用、哪裡 Copy 過、哪裡又自己改過一版。

一個下午就沒了。

🔍 反過來，如果系統的邊界一開始就比較清楚，至少遇到問題的時候可以先猜：

「這個比較像系統共用能力出問題？」

還是：

「這其實只是某個 Domain 的業務邏輯壞掉？」

光是能先把問題範圍縮小，其實就差很多了。

🤖 而且現在有 AI 之後，這件事情我反而更有感。

AI 現在真的很方便，丟一整個 Repository 給它，它可以很快幫你讀很多東西。

可是如果專案本身就是散的，同一個責任散在五六個地方、每個地方又有不同寫法，那 AI 看到的其實也還是一坨散的東西。

最後產出來的東西又回到剛剛說的：

A 有補、B 忘了、C 又另一套方法。

AI 可以幫你讀快很多，但它不會因為變成 AI，就自動讓一個原本沒有邊界的系統突然長出很漂亮的邊界。

甚至搞不好只是讓原本亂長的東西，長得更快而已。

這個我之前在接一些歷史技術債比較重的小專案時，就感受滿深的。

所以現在如果是我自己重新規劃一套「未來可能會繼續長」的系統，我至少會先守住兩層：

SysCore / Feature

如果這是一個需要有標準產品，又要針對不同需求延伸的東西，再去考慮：

SpecFeature

👉 下一篇我再來講，我自己到底怎麼分 SysCore / Feature / SpecFeature。

其實真的分到後面，它已經不只是：

「喔，我資料夾整理得比較漂亮。」

比較像是你開始替這個專案建立一套自己的 Framework。

💬 如果你手上的專案現在也有一種：

「功能越來越多，但開始不知道這東西到底該放哪」

的感覺，我也滿好奇你們現在是怎麼切系統核心跟業務功能的。

如果剛好也在整理類似的東西，也可以底下留言或私訊我聊聊。