軟件架構設計原則之「KISS」的總結使用

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

對！

就是親嘴的那個 「KISS」！

必定要多練習。

...

... ...

...

做爲一個程序員我是推薦理解爲「親嘴」的，能夠很好的解決單身問題，但做爲一個架構師在「親嘴」的同時，但願還能理解它另外一層含義。

KISS

KISS = Keep It Simple, Stupid.

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

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

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

簡單是軟件設計的目標，簡單的代碼佔用時間少，漏洞少，而且易於修改。

核心：

• 拆分，把複雜的邏輯拆分爲一個個單一執行單元。
• 簡潔，只容許串型依賴的調用關係。
• 簡單，單個執行單元代碼量必定要儘量少。

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

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

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

一、保持謙虛，第一個容易產生的誤區就是總認爲本身才是天才。保持謙虛你將最終實現超級天才的狀態，反之，沒有人會在意你。儘可能保持代碼的簡潔，不然你只能要求與你工做的都是天才。

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

三、儘可能縮短每一個方法，每一個方法只要負責解決一個問題就足夠了，每一個方法的代碼最多不要超過30-40行。若是在方法中須要兼容不少條件，那麼你應該將這些條件拆分爲更小粒度的方法。

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

五、先去解決問題，再考慮編碼。不少開發人員喜歡一邊思考一邊編碼，這麼作的確也沒什麼錯。若是你認爲本身能夠在腦殼中一邊將問題拆分的足夠小，而且同時動手編碼完成這些功能的話，等待你的是從此一遍一遍又一遍 ... 。

六、不要懼怕刪除代碼，重構和從新編碼都是很是重要的兩個問題。當你遇到不存在的需求 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

做者我的博客：Owen Blog

一路荊棘，一路前行，風雨無阻。