大家好，我是寒草????，一隻草系碼猿????。間歇性熱血????，持續性沙雕????
如果喜歡我的文章，可以關注➕ 點贊，與我一同成長吧～
前言
之前在開發的設計階段，我經常喜歡把一個元件設計的很複雜：
這個時候我的leader和我提出了一個原則：KISS 原則，簡單跟我們介紹了一下，大緻的意思是就是我們要把元件設計的更簡單，也對我年輕的想法表示了解，露出了長輩看待晚輩慈祥的目光。
于是，我打算去了解一下什麼是 KISS 原則，就産生了這篇文章。
KISS原則
概念
我去搜尋 KISS 原則的時候，關于該原則的起源衆說紛纭：
- David Mamet（大衛馬梅）的電影理論
- 美國洛克希臭鼬工廠的凱利.約翰遜(Kelly Johnson)
- 美國軍方的軟體開發
但是這個不重要，重要的是領會其精神核心。
KISS 是英文 Keep it Simple and Stupid 首字母的縮寫，意思是“保持簡單和傻瓜”。
百度百科
KISS 原則是指産品的設計越簡單越好，任何沒有必要的複雜都是需要避免的。其最完美的案例是傻瓜相機，傻瓜相機操作簡單，似乎連傻瓜都能利用它拍攝出曝光準确、影像清晰的照片來。
KISS 是一個描述性的原則，它認識到兩件事情：
- 人們通常喜歡簡單的，容易學習和使用的事物。
- 制造産品或提供服務的公司會發現簡單對公司來說也有一個好處，因為這将縮短時間，降低成本。
雖然公司嘗試站在使用者角度使用這個原則之處的設計時間也許會更長，成本會更高，但其實際效果将會非常有利，因為從長遠角度來看，容易學習和使用的産品或服務，其将來的生産和服務的成本将會大大降低。
各個領域的應用
百度百科
廣告設計
廣告創意必須簡單明了、純真質樸、切中主題，才能使人過目不忘，印象深刻。
廣告大師伯恩·巴克認為：“在創意的表現上光是求新求變化、與衆不同并不夠。”傑出的廣告既不是誇大，也不是虛飾，而是要竭盡你的智慧使廣告資訊單純化、清晰化、戲劇化，使它在消費者腦海裡留下深刻而難以磨滅的記憶。如果過于追求創意表現的情節化，必然使廣告資訊模糊不清，令人不知所雲。
企業管理
- 較簡單的系統更容易構造、運作和維護；
- 較簡單的解決方法總是更具彈性、柔性；
- 較簡單的系統更便宜；
- 較簡單的系統更容易被更快地實作、獲得更快的回報；
- 較簡單的方法使用者更喜歡；
- 較簡單的系統更容易分階段地執行；
- 較簡單的系統更容易被使用者了解。
目标管理
- 讓它簡單些，連笨蛋都看得懂
- 好的目标不是越複雜越好，反而是越簡潔越好
- 符合 KISS 原則的目标都是關鍵的，而非包羅萬象
- 目标必須确定優先順序，而關鍵的目标則是資源和努力的重心
網頁設計
- 網頁的下載下傳不要超過 10 秒鐘
- 盡量使用文本連結，而減少大幅圖檔和動畫的使用（
寒草了解不能
- 操作設計盡量簡單，并且有明确的操作提示
- 網站所有的内容和服務都在顯眼處向使用者予以說明等
産品設計
KISS 原則是DFMA中最重要的一條設計原則和設計思想，幾乎貫穿于 DFMA 的每一條設計指南中，減少零件數量是 KISS 原則在 DFMA 的主要展現。
一般來說，産品中的零件數量越多，産品制造和裝配就越複雜和越困難，産品制造費用和裝配費越高，産品開發周期也就越長，同時産品發生制造和裝配品質問題的可能性越高。在確定實作産品功能和品質前提下，簡化的設計、更少的零件數量能夠降低産品成本，縮短産品開發周期，提高産品開發品質。高水準的機械工程師把複雜的東西設計得很簡單，而低水準的機械工程師則把簡單的東西設計得很複雜，此時也可以把 KISS 原則應用上。
對于機械工程師來說，減少零件數量、簡化産品設計能夠大幅減少工作量，一個零件在其開發周期中的任務包括零件設計、生成二維工程圖、樣品制作、零件試産、零件裝配、零件品質和功能驗證等等，無一不是繁重的任務。減少零件數量、簡化産品設計對于工程師來說是看得見的實惠，能夠讓工程師把更多的時間和精力放在提高産品設計品質上來。
KISS 原則在程式設計中的應用
每個程式員都應該了解：KISS：60年前美國軍方的程式設計原則
當今的軟體工程師和開發者們有個共同的問題，那就是他們總是慢慢地使得問題複雜化。
正确的做法應該是當開發者遇到一個問題後，把問題拆分成一個個能夠明白的小塊，然後進入編碼階段。
你需要先想好問題的解決步驟一共分為幾步，然後再進入編碼。
而不是拿到需求後，就開始一邊寫代碼一邊去滿足需求。這樣做的好處就是你的代碼會變的足夠容易了解和足夠清晰。
運用KISS原則，能擷取到什麼好處？
- 你可以更好地解決更多問題。
- 你将可以通過很少的幾行代碼去解決複雜的問題。
- 你将可以産出高品質的代碼。
- 你将可以建構更大更易維護的系統。
- 當新的需求來了後，你的代碼将會更加的靈活，易于擴充、易于修改和重構。
- 你将完成比你想象得更多的事情。
- 你将能夠工作在一個大型開發團隊和大型項目中，因為所有的代碼都是stupid simple。
如何把KISS原則用到我的工作中？
這裡有幾個簡單的步驟可供執行，但有一定挑戰。就像說起來的那麼簡單，keep it simple，主要是需要耐心，更多的靠你自己。
- 要謙虛，不要認為自己是個天才。隻有謙虛了，你才能真正達到超級天才的水準，即使不行，who cares！你的代碼那麼stupid simple，是以你不需要是個天才！
- 将你的任務分解為4-12小時的子任務。
- 把你的問題拆分成多個小問題。每個問題用一個或者很少的幾個類來解決掉。
- 保持你的方法足夠小，每個方法永遠不要超過30-40行代碼。每個方法都應該隻處理一個小小的問題，不要搞太多uses case進去。如果你的方法中有多個分支，嘗試把他們拆分成多個小的方法。這樣不僅容易閱讀和維護，找bug也更快。慢慢的你将學會愛。
- 讓你的類也小點，原則和上面的方法是一樣的。
- 先解決問題，然後開始編碼。不要一邊編碼，一邊解決問題。這樣做也沒什麼錯，但你有能力提前把事情切分成多個小的塊，然後開始編碼可能是比較好的。但也請你不要害怕一遍遍重構你的代碼。另外行數還不是為了衡量品質的标準，隻是有個基本的尺子而已。
- 不要害怕幹掉代碼。重構和重做是兩個非常重要的方面。如果你遵循上面的建議，重寫代碼的數量将會最小化，如果你不遵循，那麼代碼很可能會被重寫。
- 其他的任何場景，都請你嘗試盡可能的簡單，simple，這也是最難的一步，但一旦你擁有了它，你再回頭看，就會說，之前的事情就是一坨屎。
許多偉大的問題解決者（problem solver）都曾不是偉大的程式員，但他們卻産出了偉大的代碼！
程式設計是為了解決問題，我們不隻是程式員，我們不隻生産代碼，讓我們一起成長為偉大的問題解決者。
對于 KISS 原則的感悟
我也是作為一個該原則的學習者，由于我之前喜歡加入一些花活兒使得元件更加複雜，是以不能說對這個原則一竅不通，隻能說我啥也不是。但是通過學習其概念，我也會有一些自己的感悟。
我試圖思考某些經典的案例得以成功是否也是源于其簡單的設計，比如：
- 蘋果公司的産品和作業系統
- 腦某金的廣告
- ...
可能冥冥之中都符合這個原則，使得他們有着空前的影響力，而我怎麼在工作去用好 KISS 原則也是一個大問題，我想到的是幾個方面：
- 開發前準備工作
- 元件職責設計
- 工作流程
具體也是要和上面那些結合起來，從現在起我可能會努力不再熱衷于一個強大的可以做更多事情的元件或者類，而去做能力的解藕和拆分，使其更簡單易用，職責清晰。
我在想是否需要舉一個執行個體：
之前在聊天的時候，說到一個這樣的需求，比如一個表單元件，可能就是編輯器和新增器元件會用到它，但是如果檢視器說不定也會需要資訊展示。
我當時就提議：
“給表單元件加一個 type 是 view，當組建的類型是 view 的時候，添加一個 css，把表單項的邊框去掉并且 readonly 。”
這個想法是不是聽上去很詭異～
然而現在看，檢視資訊并不屬于表單能力範疇，現在的我就會去增加一個 xxxLayout 元件了。
結束語
前端不隻是技術，思想原則亦是軟實力。這次結束語不扯有的沒的啦，直接求關注，點贊，點贊關注是對我最大的支援。如果有問題或者不同見解歡迎留言讨論✨
- 百度百科
- 每個程式員都應該了解：KISS：60年前美國軍方的程式設計原則