今天聊一聊軟體架構設計中的 KISS 原則。

對！

就是親嘴的那個 “KISS”！

一定要多練習。

...

... ...

...

作為一個程式設計師我是推薦理解為“親嘴”的，可以很好的解決單身問題，但作為一個架構師在“親嘴”的同時，希望還能理解它另一層含義。

KISS

KISS = Keep It Simple, Stupid.

它的核心就是把一切事情簡單化，用最簡單的解決方案來解決問題。

把一個事情搞複雜是一件簡單的事，但要把一個複雜的事變簡單，這是一件複雜的事。

簡單的人生就是幸福。但是這裡需要說明的是簡單是優秀的，但簡單是有底線邊界的，超過底線的簡單也有變得稚幼。KISS原則來源於《UNIX程式設計藝術》中總結的。

簡單是軟體設計的目標，簡單的程式碼佔用時間少，漏洞少，並且易於修改。

核心：

• 拆分，把複雜的邏輯拆分為一個個單一執行單元。
• 簡潔，只允許串型依賴的呼叫關係。
• 簡單，單個執行單元程式碼量一定要儘可能少。

我們應該如何從KISS原則中獲益？

• 你會以更快的速度解決更多的問題
• 你會以很簡潔的程式碼來解決很複雜的問題
• 你能寫出高質量的程式碼
• 你能完成更大的系統並且它很容易維護
• 你所編寫的程式碼會更加靈活，易於擴充套件、修改或重構
• 你能得到比你原本想象的更多
• 自從你將程式碼變得 Stupid&Simple，你就能有機會在更加龐大的產品團隊或者專案團隊中工作

如何在工作中實踐KISS原則？

1、保持謙虛，第一個容易產生的誤區就是總認為自己才是天才。保持謙虛你將最終實現超級天才的狀態，反之，沒有人會在乎你。儘量保持程式碼的簡潔，否則你只能要求與你工作的都是天才。

2、將你所面臨的問題拆分成多個小塊，每個問題解決需要的類的個數不應該太多。將任務拆分成完成時間在4-12小時之間的程式碼量，並讓任務的依賴儘可能的是單一的關係。

3、儘量縮短每個方法，每個方法只要負責解決一個問題就足夠了，每個方法的程式碼最多不要超過30-40行。如果在方法中需要相容很多條件，那麼你應該將這些條件拆分為更小粒度的方法。

4、控制你的類不要過大，這種方法學（保持較小）同樣也被用在我們之前提到的函式方法（methods）上（Keep your classes small, same methodology applies here as we described for methods）。

5、先去解決問題，再考慮編碼。很多開發人員喜歡一邊思考一邊編碼，這麼做的確也沒什麼錯。如果你認為自己可以在腦袋中一邊將問題拆分的足夠小，並且同時動手編碼完成這些功能的話，等待你的是今後一遍一遍又一遍 ... 。

6、不要害怕刪除程式碼，重構和重新編碼都是非常重要的兩個問題。當你遇到不存在的需求 or you weren't aware of when you wrote the code to begin with you might be able to solve the old and the new problems with an even better solution. 如果你遵循上面兩個原則那麼重寫的程式碼將會變得很少，否則程式碼也許會大量被重寫。

在其它所有情況下，儘量保持程式碼的簡潔，這是才是最難的行為模式，但是一旦你這麼做，當你再次回頭看時你會說：“我真的不能想象我以前是怎麼工作的”。儘量保持簡單，聽起來很容易，其實它是在說耐心，而更多的是在說你自己。

關注

作者：Owen Jia

推薦關注他的公眾號：冬天就要吃胖點

一路荊棘，一路前行