KISS原則
大約60年前，美國軍方的軟件開發開始遵循一個原則，叫KISS原則。
他們希望武器系統中所用的每個指令都是極其簡單和傻瓜式的。這個原則後來在編程領域中被廣泛採用，如今好多著名的產品都是遵循這一原則來開發，並最終取得了巨大的成功。
KISS原則是什麼？
KISS 是Keep It Stupid Simple 的縮寫。
當今的軟件工程師和開發者們有個共同的問題，那就是他們總是慢慢地使得問題複雜化。
正確的做法應該是當開發者遇到一個問題後，把問題拆分成一個個能夠明白的小塊，然後進入編碼階段。
你需要先想好問題的解決步驟一共分為幾步，然後再進入編碼。
而不是拿到需求後，就開始一邊寫代碼一邊去滿足需求。這樣做的好處就是你的代碼會變的足夠容易理解和足夠清晰。
運用KISS原則，能獲取到什麼好處？
- 你可以更好地解決更多問題。
- 你將可以通過很少的幾行代碼去解決複雜的問題。
- 你將可以產出高質量的代碼。
- 你將可以構建更大更易維護的系統。
- 當新的需求來了後，你的代碼將會更加的靈活，易於擴展、易於修改和重構。
- 你將完成比你想象得更多的事情。
- 你將能夠工作在一個大型開發團隊和大型項目中，因為所有的代碼都是stupid simple。
如何把KISS原則用到我的工作中？
這裡有幾個簡單的步驟可供執行，但有一定挑戰。就像說起來的那麼簡單，keep it simple，主要是需要耐心，更多的靠你自己。
- 要謙虛，不要認為自己是個天才。只有謙虛了，你才能真正達到超級天才的水平，即使不行，who cares！你的代碼那麼stupid simple，所以你不需要是個天才！
- 將你的任務分解為4-12小時的子任務。
- 把你的問題拆分成多個小問題。每個問題用一個或者很少的幾個類來解決掉。
- 保持你的方法足夠小，每個方法永遠不要超過30-40行代碼。每個方法都應該只處理一個小小的問題，不要搞太多uses case進去。如果你的方法中有多個分支，嘗試把他們拆分成多個小的方法。這樣不僅容易閱讀和維護，找bug也更快。慢慢的你將學會愛。
- 讓你的類也小點，原則和上面的方法是一樣的。
- 先解決問題，然後開始編碼。不要一邊編碼，一邊解決問題。這樣做也沒什麼錯，但你有能力提前把事情切分成多個小的塊，然後開始編碼可能是比較好的。但也請你不要害怕一遍遍重構你的代碼。另外行數還不是為了衡量質量的標準，只是有個基本的尺子而已。
- 不要害怕幹掉代碼。重構和重做是兩個非常重要的方面。如果你遵循上面的建議，重寫代碼的數量將會最小化，如果你不遵循，那麼代碼很可能會被重寫。
- 其他的任何場景，都請你嘗試儘可能的簡單，simple，這也是最難的一步，但一旦你擁有了它，你再回頭看，就會說，之前的事情就是一坨屎。
許多偉大的問題解決者（problem solver）都曾不是偉大的程序員，但他們卻產出了偉大的代碼！
編程是為了解決問題，我們不只是程序員，我們不只生產代碼，讓我們一起成長為偉大的問題解決者。
分享到:
閱讀更多 WangLiwen 的文章
