Law Of Conservation Of Code Complexity
寫程式一段時間了，相信你一定多少碰過以下的幾種情境：
- 在重構套用了設計模式後，程式碼沒有變得比較簡單，架構反而變得更加複雜。
- 兩個軟體工程師討論程式碼時，有時會進入哪種寫法比較複雜的爭論，
誰也不服自己的寫法有比較複雜。 - 前後端分工時，不確定該把某些邏輯放在哪。
以下跟各位分享一個自己領悟出來的定律，也就是複雜度守恆定律！
還記得前段時間我們討論 S.O.L.I.D 時，
有說過遵守單一職責原則時，仰賴的是你切分職責的方式。
當你認為這個檔案不該每次有需求變化時就必須修改（違反開放封閉原則），
套用了狀態模式，此時程式碼會從原本單一檔案的複雜攤平成架構層面的複雜。
又或者你使用裝飾者模式、代理模式，
來隔離記錄 Log、實作快取等與原本的主程式不相關的邏輯，
其實並沒有讓程式碼變得比較簡單 （其他工程師可能還是看不懂）。
但這不表示我們就不該學這些內容，原因是當雙方都對這些概念有些許理解時，
你們的大腦便可以快速的轉譯程式碼的內容，進而減少討論與修改的時間。
回到一開始的情境，我們又該如何處理呢？
推薦幾個我用過的方法（概念來自 Problem Solving）：
- 傳教：組織讀書會，或適時分享設計模式的範例，讓團隊成員認識這些概念。
- 進行討論：討論不同寫法時，可以提出幾種需求變更的情境，來討論 Pros & Cons。不要陷在哪種寫法比較複雜的爭論。
- 適度妥協：有時候並不需要完全偏向某邊，重點在討論的本身，只要事情有往好的方向發展，可以分階段進行。
每個選擇背後都有 trade-off。
ʕ •ᴥ•ʔ：google 後發現 Tesler 有提出另一個複雜度守恆定律，
主要在描述交互界面設計的複雜度，該由軟體工程師寫更多的程式碼來降低，
還是由客戶花費更多時間來學習，也是相當有趣的觀點。