程序員擁有一個(gè)較好的編程原則能使他的編程能力有大幅的提升，可以使其開(kāi)發(fā)出維護(hù)性高、缺陷更少的代碼。

目錄

• KISS（Keep It Simple Stupid）
• DRY（Don’t Repeat Yourself）
• YAGNI – You ain’t gonna need it
• Code For The Maintainer
• Be as lazy as possible.
• Programming is only the road, not the way.
• If you are in a hurry, stroll along slowly. If you really are in a hurry, make a detour.
• Know your path, Neo.
• If it wasn’t tested, it is broken.
• 與程序溝通時(shí)分辨原因和結(jié)果，與人交流時(shí)要分辨事實(shí)和觀點(diǎn)

KISS（Keep It Simple Stupid）

KISS原則是英語(yǔ) Keep It Simple, Stupid 的首字母縮略字，是一種歸納過(guò)的經(jīng)驗(yàn)原則。KISS 原則是指在設(shè)計(jì)當(dāng)中應(yīng)當(dāng)注重簡(jiǎn)約的原則?？偨Y(jié)工程專業(yè)人員在設(shè)計(jì)過(guò)程中的經(jīng)驗(yàn)，大多數(shù)系統(tǒng)的設(shè)計(jì)應(yīng)保持簡(jiǎn)潔和單純，而不摻入非必要的復(fù)雜性，這樣的系統(tǒng)運(yùn)作成效會(huì)取得最優(yōu)；因此簡(jiǎn)單性應(yīng)該是設(shè)計(jì)中的關(guān)鍵目標(biāo)，盡量回避免不必要的復(fù)雜性。

這個(gè)首字母縮略詞根據(jù)報(bào)導(dǎo)，是由洛克希德公司的首席工程師凱利·約翰遜（U-2 、SR-71等的設(shè)計(jì)者）所創(chuàng)造的。雖然長(zhǎng)久以來(lái)，它一直是被寫(xiě)為 “Keep it simple, stupid”，但約翰遜將其轉(zhuǎn)化成 “Keep it simple stupid”（無(wú)逗號(hào)），而且這種寫(xiě)法仍然被許多作者使用。詞句中最后的 S并沒(méi)有任何隱涵工程師是愚蠢的含義，而是恰好相反的要求設(shè)計(jì)是易使人理解的。

說(shuō)明這個(gè)原則最好的實(shí)例，是約翰遜向一群設(shè)計(jì)噴射引擎飛機(jī)工程師提供了一些工具，他們所設(shè)計(jì)的機(jī)具，必須可由一名普通機(jī)械師只用這些工具修理。因此，“愚蠢”是指被設(shè)計(jì)的物品在損壞與修復(fù)的關(guān)聯(lián)之間，它們的難易程度。這個(gè)縮寫(xiě)詞已被美國(guó)軍方，以及軟件開(kāi)發(fā)領(lǐng)域的許多人所使用。

另外相類似的概念也可作 KISS原則的起源。例如“奧卡姆剃刀”，愛(ài)因斯坦的“一切盡可能簡(jiǎn)單”、達(dá)芬奇的“簡(jiǎn)單是最終的復(fù)雜性” 、安德魯·圣艾修伯里的“完美不是當(dāng)它不能再添加時(shí)，它似乎是在它不能被進(jìn)一步刮除時(shí)實(shí)現(xiàn)的”。

有兩種軟件設(shè)計(jì)方法，一種是盡可能的簡(jiǎn)單并保證沒(méi)有什么缺陷。另外一種方式是盡可能的復(fù)雜并保障沒(méi)有什么缺陷。而第一種方式相比第二種更加困難。

保持簡(jiǎn)單（避免復(fù)雜）永遠(yuǎn)是你應(yīng)該做的第一件事，簡(jiǎn)單的代碼不僅寫(xiě)起來(lái)簡(jiǎn)單、不容易出Bug，還易于維護(hù)。簡(jiǎn)單規(guī)則下，還包括：

• Don’t Make Me Think：如果一段程序?qū)τ陂喿x者來(lái)說(shuō)需要花費(fèi)太多的努力才能理解，那它很可能需要進(jìn)一步簡(jiǎn)化。
• 最少意外原則：程序代碼應(yīng)盡可能的不要讓閱讀者感到意外。也就是說(shuō)應(yīng)該遵循編碼規(guī)范和常見(jiàn)習(xí)慣，按照公認(rèn)的習(xí)慣方式進(jìn)行組織和命名，不符常規(guī)的編程動(dòng)作應(yīng)該盡可能的避免。

如何把Kiss原則應(yīng)用到工作中？

• 要謙虛，不要認(rèn)為自己是個(gè)天才，這是你第一個(gè)誤解。只有謙虛了，你才能真正達(dá)到超級(jí)天才的水平，即使不行，who cares！你的代碼那么stupid simple，所以你不需要是個(gè)天才！
• 將你的任務(wù)分解為4-12小時(shí)的子任務(wù)。
• 把你的問(wèn)題拆分成多個(gè)小問(wèn)題。每個(gè)問(wèn)題用一個(gè)或者很少的幾個(gè)類來(lái)解決掉。
• 保持你的方法足夠小，每個(gè)方法永遠(yuǎn)不要超過(guò)30-40行代碼。每個(gè)方法都應(yīng)該只處理一個(gè)小小的問(wèn)題，不要搞太多uses case進(jìn)去。如果你的方法中有多個(gè)分支，嘗試把他們拆分成多個(gè)小的方法。這樣不僅容易閱讀和維護(hù)，找bug也更快。慢慢的你將學(xué)會(huì)愛(ài)。
• 讓你的類也小點(diǎn)，原則和上面的方法是一樣的。
• 先解決問(wèn)題，然后開(kāi)始編碼。不要一邊編碼，一邊解決問(wèn)題。這樣做也沒(méi)什么錯(cuò)，但你有能力提前把事情切分成多個(gè)小的塊，然后開(kāi)始編碼可能是比較好的。但也請(qǐng)你不要害怕一遍遍重構(gòu)你的代碼。另外行數(shù)還不是為了衡量質(zhì)量的標(biāo)準(zhǔn)，只是有個(gè)基本的尺子而已。
• 不要害怕干掉代碼。重構(gòu)和重做是兩個(gè)非常重要的方面。如果你遵循上面的建議，重寫(xiě)代碼的數(shù)量將會(huì)最小化，如果你不遵循，那么代碼很可能會(huì)被重寫(xiě)。
• 其他的任何場(chǎng)景，都請(qǐng)你嘗試盡可能的簡(jiǎn)單，simple，這也是最難的一步，但一旦你擁有了它，你再回頭看，就會(huì)說(shuō)，之前的事情就是一坨屎。

DRY（Don’t Repeat Yourself）

DRY即Don’t repeat yourself（不要重復(fù)你自己，簡(jiǎn)稱DRY），或一個(gè)規(guī)則，實(shí)現(xiàn)一次（One rule, one place）是面向?qū)ο缶幊讨械幕驹瓌t，程序員的行事準(zhǔn)則。旨在軟件開(kāi)發(fā)中，減少重復(fù)的信息。DRY的原則是“系統(tǒng)中的每一部分，都必須有一個(gè)單一的、明確的、權(quán)威的代表”，指的是（由人編寫(xiě)而非機(jī)器生成的）代碼和測(cè)試所構(gòu)成的系統(tǒng)，必須能夠表達(dá)所應(yīng)表達(dá)的內(nèi)容，但是不能含有任何重復(fù)代碼。當(dāng)DRY原則被成功應(yīng)用時(shí)，一個(gè)系統(tǒng)中任何單個(gè)元素的修改都不需要與其邏輯無(wú)關(guān)的其他元素發(fā)生改變。此外，與之邏輯上相關(guān)的其他元素的變化均為可預(yù)見(jiàn)的、均勻的，并如此保持同步。

我對(duì)DRY的理解：

• 盡可能的減少重復(fù)，如代碼重復(fù)、文檔重復(fù)、數(shù)據(jù)重復(fù)、表征重復(fù)、開(kāi)發(fā)人員重復(fù)（相同的功能不能的開(kāi)發(fā)人員的優(yōu)自己的實(shí)現(xiàn)）
• 不重復(fù)造輪子，能夠使用開(kāi)源的解決方案的情況下沒(méi)有必要再實(shí)現(xiàn)一遍。
• 重復(fù)的事項(xiàng)，盡可能的使用自動(dòng)化程序解決。
• 不要過(guò)于優(yōu)化，過(guò)度追求DRY，破壞了程序的內(nèi)聚性。

相關(guān)規(guī)則有： 

代碼復(fù)用：http://en.wikipedia.org/wiki/Code_reuse

YAGNI – You ain’t gonna need it

YAGNI 是You Ain’t Gonna Need It（你不會(huì)需要它）的簡(jiǎn)寫(xiě)，是極限編程的關(guān)鍵原則。YAGNI意思非常簡(jiǎn)單：僅在您真正需要它們時(shí)才去做，而不是在您認(rèn)為或預(yù)見(jiàn)將來(lái)可能需要它們時(shí)就提前做了！

您可以將YAGNI視為即時(shí)制造的擁護(hù)者。在這種情況下，制造業(yè)正在編寫(xiě)代碼并交付功能。只有當(dāng)有人真的需求功能存在時(shí)，您才可以開(kāi)始工作并創(chuàng)建它。否則，您將保持自己的懶惰！

它為什么如此重要？沒(méi)有編寫(xiě)的每一行代碼都是時(shí)間，因此可以節(jié)省金錢。但是，甚至更多！它是：

• 更少的代碼維護(hù)
• 更少的代碼測(cè)試
• 事情發(fā)生變化時(shí)更少的代碼可重構(gòu)
• 更多時(shí)間用于更重要的功能
• 更多時(shí)間用于文檔編制

而且還包括：

• 節(jié)省了編譯/移植的時(shí)間
• 節(jié)省了測(cè)試運(yùn)行的時(shí)間
• 生成時(shí)/運(yùn)行時(shí)節(jié)省了資源
• 不必以某種方式保留的知識(shí)

它可以防止什么？如今，大多數(shù)軟件開(kāi)發(fā)都是根據(jù)客戶的需求進(jìn)行的。無(wú)論您是在產(chǎn)品公司，在提供開(kāi)發(fā)服務(wù)的公司還是在其他地方工作。總是會(huì)在某處某人想要具有某個(gè)功能。是您的客戶要求具有某個(gè)需求的功能，還是產(chǎn)品經(jīng)理響應(yīng)客戶的反饋的功能。無(wú)論實(shí)際驅(qū)動(dòng)者是誰(shuí)，無(wú)論是早晚，這都是實(shí)際需求的體現(xiàn)。您正確預(yù)見(jiàn)未來(lái)功能請(qǐng)求的機(jī)會(huì)非常低。因此，您很有可能實(shí)現(xiàn)某些功能，而不是您的實(shí)際利益相關(guān)者想要的功能。過(guò)早地執(zhí)行某些操作很可能會(huì)導(dǎo)致一切都被丟棄。這是一個(gè)沒(méi)人真正喜歡的場(chǎng)景！然后，有時(shí)會(huì)發(fā)生另一種情況：沒(méi)有人真正需要該功能！

Code For The Maintainer

為維護(hù)者編寫(xiě)程序。比如讓代碼有自解釋的功能。在你編寫(xiě)代碼的時(shí)候永遠(yuǎn)記得將來(lái)需要維護(hù)他。

Be as lazy as possible.

人類因“偷懶”而進(jìn)步。懶惰只是創(chuàng)造了需求。需求本身并不算進(jìn)步。滿足需求形成了進(jìn)步。

偷懶還包括：

• 不要重復(fù)發(fā)明輪子
• 過(guò)度優(yōu)化是萬(wàn)惡之源

Programming is only the road, not the way.

編碼只是一種實(shí)現(xiàn)方式，而不是解決方案。編碼只是告訴電腦應(yīng)該如何去做。要編寫(xiě)高效、可靠的軟件需要精通算法、最佳實(shí)踐等其他與變成相關(guān)的內(nèi)容。

編程前需要先了解你要解決的問(wèn)題是什么。編程只是手段并不是目的。能實(shí)現(xiàn)并不代表需要實(shí)現(xiàn)。知道什么時(shí)候不需要編程或沒(méi)有必須要去編程。

If you are in a hurry, stroll along slowly. 

If you really are in a hurry, make a detour.

如果你很忙，那就放慢速度。如果你真的很忙，那就先放一放。這聽(tīng)起來(lái)很愚蠢，但是千萬(wàn)不要讓自己陷入會(huì)導(dǎo)致后期問(wèn)題的妥協(xié)。如果你正在編寫(xiě)程序的核心部分，盡可能保證精確。如果你在編寫(xiě)離核心代碼較遠(yuǎn)的方法，可以盡可能的加快速度。

Know your path, Neo.

知道你的實(shí)現(xiàn)路徑，你需要了解你每天使用的環(huán)境、工具及其他依賴的內(nèi)容，并且把它調(diào)試到適合自己的配置。如果你的編程環(huán)境真的很好，那么你編程中的基本不需要關(guān)心他。如果你需要完成一項(xiàng)任務(wù)，最好的方式是不要引進(jìn)“新的內(nèi)容”，只有當(dāng)你完全掌握“新的內(nèi)容”的時(shí)候再去考慮引入。

If it wasn’t tested, it is broken.

如果沒(méi)有經(jīng)過(guò)測(cè)試的代碼都是不能運(yùn)行的。

與程序溝通時(shí)分辨原因和結(jié)果，與人交流時(shí)要分辨事實(shí)和觀點(diǎn)

相關(guān)的準(zhǔn)則，包括：

• 最小化耦合關(guān)系：代碼片段（代碼塊，函數(shù)，類等）應(yīng)該最小化它對(duì)其它代碼的依賴。這個(gè)目標(biāo)通過(guò)盡可能少的使用共享變量來(lái)實(shí)現(xiàn)。
• 最大化內(nèi)聚性：具有相似功能的代碼應(yīng)該放在同一個(gè)代碼組件里。
• 開(kāi)放/封閉原則：程序里的實(shí)體項(xiàng)(類，模塊，函數(shù)等)應(yīng)該對(duì)擴(kuò)展行為開(kāi)放，對(duì)修改行為關(guān)閉。換句話說(shuō)，不要寫(xiě)允許別人修改的類，應(yīng)該寫(xiě)能讓人們擴(kuò)展的類。
• 單一職責(zé)原則：一個(gè)代碼組件(例如類或函數(shù))應(yīng)該只執(zhí)行單一的預(yù)設(shè)的任務(wù)。
• 隱藏實(shí)現(xiàn)細(xì)節(jié)：隱藏實(shí)現(xiàn)細(xì)節(jié)能最小化你在修改程序組件時(shí)產(chǎn)生的對(duì)那些使用這個(gè)組件的其它程序模塊的影響。
• 笛米特法則(Law of Demeter) —— 程序組件應(yīng)該只跟它的直系親屬有關(guān)系（例如繼承類，內(nèi)包含的對(duì)象，通過(guò)參數(shù)入口傳入的對(duì)象等。
  

原文及鏈接：What do you consider the 1st principle(s) of programming?

?http://programmers.stackexchange.com/questions/91527/what-do-you-consider-the-1st-principles-of-programming?