幾個簡單的方法判斷程式碼好不好懂, 簡不簡潔。
這是我從好幾位資歷深厚的前輩身上學習到的心得, 彙整成幾個簡單的原則。
1. 7±2法則：讓程式碼保持簡單
有一個來自心理學的概念叫做 7±2法則，這條法則指出一般人短期記憶的容量大約只能記住7±2個單位的信息。這個法則告訴我們，當我們寫程式時，應該避免將過多的變量或函數擠進同一頁或同一個函數裡。這不僅是為了讓程式碼對自己更清晰，也讓其他開發者能夠更容易理解。
因此，我的建議是：
- 每個函數的邏輯應該盡量簡單，最好在 7 個變量或函數左右，這樣閱讀起來不會過於混亂，更進階的作法是維持在 3~4 個變量或函數，因為現代人的短期記憶可能更短。
- 當一個 class 包含過多的函數或是變量(控制狀態)時，這時候就需要考慮一下要不要重構了。
2. 保持每頁程式碼的行數簡潔
程式碼的行數也是影響可讀性的關鍵。過長的程式碼頁面不僅讓自己難以跟蹤，也讓其他開發者無法快速理解。對於這點，有一些常見的原則可以參考：
- 每頁程式碼不應該超過300行。這是一個普遍的建議，因為過長的頁面會讓人難以一次性理解。
- 另外，我也聽過一個進階的建議，即每頁程式碼最好不要超過130行，這是因為大部分螢幕的高度大約能顯示130行程式碼。這樣的設計讓開發者可以在不需要滾動的情況下，快速掌握整個程式碼的邏輯結構。
因此，維持程式碼簡短，將程式碼拆分成較小的模塊，這樣每個模塊都能清晰、簡潔地表達自己的功能。
3. 物件導向設計與設計模式
在寫程式時，我們應該要遵循物件導向設計原則，保持程式碼的高內聚性和低耦合性。這樣不僅能讓程式碼更易於維護，也能確保在程式的不同部分之間不會出現過多的相互依賴。
單一職責原則（SRP）告訴我們，每個物件應該有且只有一個責任。如果一個物件的行為過於複雜，就需要進行重構，拆分成更小、更具單一職責的物件。
當一個物件的行為複雜度增加時，我們應該考慮使用依賴反轉原則（DIP）來分擔物件的責任。
當物件的行為模式有多種變化時，可以考慮使用策略模式來動態地選擇行為。若物件的行為依賴於狀態的變化，則應該使用狀態模式來處理狀態變化引起的行為變動。
4. 簡單判斷重構的時機：當程式碼超過一定的界限時
當我們的程式碼超過了一些“界限”，就應該考慮重構。比如說：
- 物件的職責是否單一，整體設計是否符合物件導向(OO)的原則。
- 當一個頁面程式碼超過130行或300行時，應該考慮將它拆分成更多的函數或模塊。
- 當一個物件的責任過於複雜時，我們應該考慮將它拆分成多個物件，並且將多變的行為交給設計模式來處理。
這些指標能夠幫助我們判斷程式碼是否過於複雜，從而提醒我們進行重構。
結論
在寫程式碼時，保持簡潔、模塊化是關鍵。我們應該遵循簡單的原則，避免過度設計和複雜的結構。當一個頁面程式碼過長，或者一個物件的行為過於複雜時，就是時候進行重構了。通過這些方法，我們能夠寫出更易於理解和維護的程式碼，並且保持程式碼的可擴展性和可讀性。
記住，簡潔是優雅的，清晰的程式碼不僅有助於我們自己，也能幫助其他開發者更快速地理解與使用我們的程式碼。
