大約在60年前，美國軍方的軟件開發開始遵循一個原則，叫KISS原則。他們希望武器系統中所用的每個指令都是極其簡單和傻瓜式的。這個原則后來在編程領域中被廣泛采用，如今好多著名的開源框架都是遵循這一原則來開發，并最終取得了巨大的成功。

　　在上一文中《Apache的架構師們遵循的30條設計原則》，第一個原則便是KISS原則，幾年前簡單的了解過這個原則，前幾日又翻出來，仔細查看后，倍感震驚，這篇原文可以說道破了編程的天機。以下原文的翻譯：

　　KISS表示的是什么？

　　KISS 是Keep It Stupid Simple 或 Keep It Simple,Stupid的縮寫。

　　KISS的含義

　　該原則在我的多年的軟件工程生涯中取得關鍵、巨大的成功。當今的軟件工程師和開發者們有個共同的問題，那就是他們總是慢慢地使得問題復雜化。正確的做法應該是當開發者遇到一個問題后，把問題拆分成一個個能夠明白的小塊，然后進入編碼階段。但我會說，10個開發者中有8個或9個都沒有把問題分解成足夠小或可以理解的足夠小的部分。這就導致了即使是一個非常簡單的問題最后也變成了非常復雜的實現，另外一個副作用就是意大利面代碼，在BASIC里只是一個goto語句的事情，在Java中卻需要500到1000行代碼，每個方法都有幾百行代碼。

　　你需要先想好問題的解決步驟一共分為幾步，然后再進入編碼。而不是拿到需求后，就開始一邊寫代碼一邊去滿足需求。這樣做的好處就是你的代碼會變的足夠容易理解和足夠清晰。

　　我們能從KISS中獲取到什么好處？

1. 你可以更好地解決更多問題。

2. 你將可以通過很少的幾行代碼去解決復雜的問題。

3. 你將可以產出高質量的代碼。

4. 你將可以構建更大更易維護的系統。

5. 當新的需求來了后，你的代碼將會更加的靈活，易于擴展、易于修改和重構。

6. 你將完成比你想象得更多的事情。

7. 你將能夠工作在一個大型開發團隊和大型項目中，因為所有的代碼都是stupid simple。

　　我如何把KISS原則用到我的工作中？

　　這里有幾個簡單的步驟可供執行，但有一定挑戰。就像說起來的那么簡單，keep it simple，主要是需要耐心，更多的靠你自己。

• 要謙虛，不要認為自己是個天才，這是你第一個誤解。只有謙虛了，你才能真正達到超級天才的水平，即使不行，who cares！你的代碼那么stupid simple，所以你不需要是個天才！

• 將你的任務分解為4-12小時的子任務。

• 把你的問題拆分成多個小問題。每個問題用一個或者很少的幾個類來解決掉。

• 保持你的方法足夠小，每個方法永遠不要超過30-40行代碼。每個方法都應該只處理一個小小的問題，不要搞太多uses case進去。如果你的方法中有多個分支，嘗試把他們拆分成多個小的方法。這樣不僅容易閱讀和維護，找bug也更快。慢慢的你將學會愛。

• 讓你的類也小點，原則和上面的方法是一樣的。

• 先解決問題，然后開始編碼。不要一邊編碼，一邊解決問題。這樣做也沒什么錯，但你有能力提前把事情切分成多個小的塊，然后開始編碼可能是比較好的。但也請你不要害怕一遍遍重構你的代碼。另外行數還不是為了衡量質量的標準，只是有個基本的尺子而已。

• 不要害怕干掉代碼。重構和重做是兩個非常重要的方面。如果你遵循上面的建議，重寫代碼的數量將會最小化，如果你不遵循，那么代碼很可能會被重寫。

• 其他的任何場景，都請你嘗試盡可能的簡單，simple，這也是最難的一步，但一旦你擁有了它，你再回頭看，就會說，之前的事情就是一坨屎。

　　有沒有一些KISS原則的例子

　　太多了，以后我會把一些不錯的案例po到這里。但現在我想先給你一些我的觀點和想法：

　　世界上的很多偉大的算法幾乎總是有很少的數行代碼。當我們去看這些的時候，會發現很容易理解。這些算法發明者，他們把問題拆分，直到容易理解的程度，然后去實現它。

Many great problem solvers were not great coders, but yet they produced great code!

　　許多偉大的問題解決者（problem solver）都曾不是偉大的程序員，但他們卻產出了偉大的代碼！

　　KISS只能用于java代碼？

　　顯然不是，它可以用于很多編程語言，并且甚至可用于你生活的其他的領域。當然不能用于你的感情、愛，更重要的是，不能用在你的婚姻上。

　　相關閱讀：

　　Apache的架構師們遵循的30條設計原則

　　如何寫一個清晰明了的bug