KISS （Keep It Simple, Stupid） 是軟體開發中常用的最佳實踐之一，指的是在開發或設計時應該保持簡單，避免使用過於複雜的程式碼。KISS 原則的目的是為了使軟體易於理解和維護，並且能夠減少軟體中的錯誤。
實踐 KISS 原則有什麼好處？
任何傻子都能寫出電腦看得懂的程式，而優秀的程式設計師則會寫出讓人類看得懂的程式。
對於大多數人而言，讀程式、寫程式的時間比例通常約 8:2，因此若程式碼夠簡單直觀，就意味著很容易讀懂，也讓其他同事們更容易理解與推理，提高工作效率。這種能將其意圖清楚地傳達給讀者的程式碼，在大型團隊中是不可或缺的要素。
簡單設計的系統還有許多優點
- 提高測試的效率，畢竟測試一個簡單的系統比測試一個複雜的系統更容易。
- 降低錯誤和風險。簡單的系統較不容易出錯，就算不幸出錯了，開發人員也能較容易排查問題、解決問題。
- 降低修改成本，開發人員可以更輕鬆的添加新功能。
總之，遵循 KISS 原則是有效提升系統品質的關鍵。
如何遵循遵循 KISS 原則
- 評估系統所需要的功能，去除冗餘或不必要的功能。
- 如果需要在兩種解決方案之間進行選擇，選擇較簡單的那個。
- 站在使用者的角度進行設計，保持設計的簡單和直觀，避免過度設計、過度抽象化。
- 選擇適當的技術和工具：選擇易於理解和使用的技術和工具，減少過度依賴複雜的技術和工具。
- 持續重構和簡化：定期檢視和評估系統，尋找並簡化過於複雜的部分，例如盡可能減少 method 的循環複雜度（Cyclomatic complexity）。
- 分解問題，從簡單的問題開始解決，逐漸構建複雜的解決方案。(Divide and conquer)。
- 減少物件的內部狀態。狀態往往會帶來更多複雜性。
- 遵循 SRP (Single Responsibility Principle)。
- 少用繼承，多用組合 （Composition over Inheritance）。
- 先不要急著優化效能，除非有證據顯示該寫法會造成效能瓶頸 (Premature Optimization Is the Root of All Evil)。
- code review：如果同事對你的程式碼有很多疑問，可能表示程式碼可能不夠簡單。
違反 KISS 原則的案例探討
有些決策者沒有考慮周全，一味的使用難度較高的技術，看似能解決問題，卻也導致將產品帶往複雜的方向，而且難以回頭！例如，因應業務成長，架構師可能會將單體架構改為微服務架構，雖然可以提升系統的承載力，但維運、開發成本也會大幅提升。因為，一個微服務架構除了本來的服務外，還要包含服務註冊、API Gateway、監控系統等，從一個服務變成一個分散式的生態系統，是相當有挑戰性的任務!
因此我認為在選擇解決方案時，除了要深入研究與權衡，決策者必須根據當時的時空背景 (context) 來做技術選型，此外還得考量團隊成員的技術能力，更重要的是不要一股腦兒加入過度複雜的設計，簡單直觀、團隊成員都能理解的方案應列為優先考量。例如可以先消除系統瓶頸、考慮加硬體資源、加入 cache, message queue 等等較簡單的方案，觀察一陣子，再根據 feedback ，循序漸進的調整。
後記
- 用複雜、高深技巧解決問題的人，往往不是最厲害的；真正的高手，往往是能用簡單的方法與思路解決複雜的問題，或是善於將問題簡化的人。
- 人類的腦容量有限，無法同時處理太多問題。如果在專案中加入不必要的複雜性，這將導致程式碼可讀性下降，從而降低其他同事的理解、推理能力與開發效率。
- 唐朝詩人白居易的作品平易近人。相傳白居易每作一首詩就念給老年婦女聽，不懂就改，力求做到她們能懂。我想這應該是將 KISS 原則發揮到極致的經典案例吧！