軟體架構設計是為了解決複雜問題，不是把問題複雜化 —— 優雅的後端工程師系列（三）
===

前面兩篇都在介紹關於架構設計的一些思想，通常我們在整個架構中為了滿足「設計」，就會用到很多抽象層，剛開始接觸架構設計的時候都會覺得這樣的寫法相當漂亮，但你可能會發現，有時候一個簡單的函式功能卻跳了好幾個檔案，最後才知道具體的邏輯在哪，你認為的**乾淨的程式碼**其實可能沒那麼乾淨。

好程式的底層邏輯：高可讀性、高效能、少重複、可維護
---

正如標題所述，使用架構設計是為了解決問題，而不是讓你的程式碼最後很難看懂，那樣更像是看上去很強，實則很難維護，可讀性也不佳，當你的業務邏輯相對簡單時，不做架構設計可能會比一堆設計顯得更好，務必記住不要「過度設計」。

抽象類型是為了讓用戶不關心底層邏輯，不是讓你的程式很抽象
---

讓程式很抽象的抽象可以給大家舉個例子：


這裡的抽象看上去都是和資料庫相關的操作，但仔細一看你會發現這個抽象混合了真正資料庫交互的方法和一些業務邏輯，另外一個抽象內有過多的方法也代表架構分的不夠清晰，別忘記抽象也可以依賴於抽象，只要確定好誰是底層誰是上層不要有循環依賴即可。

好的程式無需註解，好的抽象都是註解
---

就像上面說的，抽象是為了讓這個抽象的用戶不用關心具體實現邏輯，如果抽象不包含註解說明各個方法會做什麼，那麼最終使用者仍然要 trace code 才會知道這些方法做了什麼事，顯然已經違反了當初建立抽象類的初衷。

前面說到在 [DDD 架構中我們的方法命名應該是「行為導向」](https://hackmd.io/@yydrBackend/B1NfOd2Zkg)，因此好的程式幾乎可以直接翻譯成人話，自然也就不需要什麼註解，另外注意註解只有在特殊邏輯處需要寫，不需要將程式已經表達清楚的語意再說一遍。

先完成再完美，如果你是個打工人
---

程式架構設計在初期的時候是需要花費大量時間的，通常要實現某些功能在公司中都會規定 deadline，如果 deadline 太趕的話，其實可以先選擇扁平化的架構實現所有功能，未來時間比較充裕時再調整架構慢慢重構，這可能會是一個比較好的解決方案。

當然如果是自己開發的產品或者開源項目就另當別論，你可以根據你自己喜歡的架構方法來開發整個軟體，畢竟也沒人規定要在什麼時候完成你的項目。

懂架構設計是你的武器，但請不要拿他亂砍人
---

這裡的亂砍人有兩個意思：

> 別人寫的程式也許沒經過設計，但在不了解情況時不要隨意批判

每個寫法都有其意義所在，也許當時的業務場景就不適合使用較高級的架構，也有可能單純只是為了讓公司的其他新手工程師也能看懂。

> 不是所有業務場景都需要架構，方法用在對的地方才能發揮效果

再次點題不要**過度設計**，只有當你知道這個專案或者這段邏輯區塊會很複雜時，才要考慮是否需要套用軟體架構的思想，不使用 DDD 也可以讓你的程式碼修改時侵入性很小。