程式架構有多重要？如果你的程式碼會需要不斷演化下去，會轉手給他人開發，會變成大型系統，那架構會非常重要！
但這樣似乎跟沒有講一樣，實務上的程式哪個沒有符合上述要求？所以我覺得用刪去法來看，只要你的程式是測試開發、創業初期驗證概念、只會使用幾次的，其實求快比較重要，架構倒是其次。但如果創業公司已經發展起來，開發人員增加，功能開始增多，我認為架構就是一切，沒有良好的設計架構，就像根基不穩的建築，隨時都可能倒塌！
在創業時期，我其實並不懂這些概念，也是求快優先，需要加什麼功能，用最快的方式搞定他。但到了中後期，開始發現自己之前寫的某些程式變得難以修改。比如說當時的應用需要同步手機與伺服器的資料，發現有時候資料會變的不一致，研究才發現一開始用的版本演算法是有問題的，想要修改卻發現邏輯和資料庫操作沾黏在一起，很難改動，外加沒有寫測試，也不知道改動會有什麼影響。那時只有我一個人負責開發伺服器和手機App，在時間的緊迫下，暫時放棄修改。
後來到了別家公司，接手前人的程式碼，功能更多，也寫的更沾黏，修改時牽一髮動全身。有時嚴重到像是蝴蝶效應，小改了某一個參數，導致數個功能開始出問題，此時才開始領悟到架構的重要性。
最近正在看「重構」這本神書，其中說到，任何一個人都可以寫電腦看得懂的程式碼，只有專家才能寫給人看得懂的程式碼。突然有種頓悟感，覺得非常有道理！對於電腦而言，程式碼只是一道道指令，他只要乖乖照的做就可以。但對於人而言，程式碼是一個抽象的概念，把工程師腦中的想法和設計，轉換成程式碼描述出來，就像設計圖一樣。如何讓接手的人看得懂前人的設計圖，真的是一門學問。
在軟體工程上，我也認為「分層」是一件很重要的事情。所謂分層，就好像一家公司，會聘僱各種專業人士，讓各個員工分別去處理他們擅長的事，而不是一個人負擔所有的事情。假設一家公司員工過少，每個員工都負擔太多任務，久而久之就會過勞，發生錯誤的機率也會上升。
同理，在軟體設計上，有時我們會對一個 method 或 function 賦予太多任務，在一個程式區塊裡面做了太多事情，雖然看起來好像一個萬能函數，呼叫他就能夠完成所有事情。但如果某天需要增加一個功能，你會發現難以修改！因為每個邏輯都互相相關，或是行行都看得懂，但就是不知道他在幹嘛（想像一個一千多行的巨無霸大函數，我相信當你打開它，只會想把它關掉）。
此時引入公司組織的概念，把一整個大任務適當的切分成各個小任務，然後為每一個 function 賦予他一個最重要的功能，他只要簡單做好這件事就好！最後再把它串接再一起，完成一開始我們所設想的任務。這樣的好處有很多：
- 功能模組化
如果未來要新增或刪減，因為已經模組化，就像玩樂高一樣，可以簡單的重新做組合
- 讓程式碼可測
巨大函數通常沾黏各種資料庫或是 api 呼叫，根本無法測試。如果把功能拆解，就能夠為每一塊撰寫測試。未來在修改時只需要簡單跑過測試，就能知道功能是否有被破壞。
- 人類可以看得懂
我覺得這個最重要！人的記憶力有限，要他一次消化掉一千行的程式，除非他是超強強者，不然我覺得困難重重。如果模組化，就好像看地圖，我可以先看 A 區，有概念後再看 B 區，接著看兩區的路線，就能夠簡單的串接起來，整體概念更清晰！
整體來看，把大函數切分成小函數，把一層切成多層，其實精神上是一樣的，就是簡化每一塊的功能負擔，儘量的分工、模組化。讓每一塊的相依性能夠變到最小，這樣未來開發才能有最大的彈性。
在生物界其實已經把這件事做到極致，就是我們的大腦。在神經科學上會將大腦皮質分區，比如說體感覺皮質區，視覺皮質區，聽覺皮質區等等。在功能上做分區，如果今天視覺皮質區受到損壞，體感覺並不會受到影響。皮質本身還會分層，每一層負責不同的視覺刺激解析，如亮度、顏色、型態等等。最後在統合成我們看到的東西，並且做更多認知上的判斷！大腦除了分層分區，他還是多執行緒！想想你有可能再聽到某個聲音的時候，暫時看不到東西嗎？如果我們要讓程式可以並行處理，勢必也是要有良好的結構和區分才能達到！不得不說生物真的是工程領域的老師！
這邊簡單以概念性的角度來討論程式架構的重要性，之後再從技術上來分享他的好處！
延伸閱讀
自動化測試的重要性
Modular Monoliths 是什麼？可以讓我們從單塊泥球中解放嗎？
