軟件編碼原則

原文鏈接：http://webpro.github.io/programming-principles

    每個程序開發人員都會受益於對編程的原則和模式的理解。
    爲了給自己提供一個參考，我把這個概述寫在這裏。通過設計，討論，或者回顧複習，它可能會對你有所幫助。
    要注意的是，它距離完成還有很長的距離，並且你也會經常需要在衝突的原則中做出取捨。

這一系列的靈感來之於 The Principles of Good Programming .我認爲這更接近，而不是全部符合，我會自己加入一些相關的東西。
此外，我需要更多的原因，細節，和其他的資源的連接。如果你有任何促進的反饋或者建議，請告訴我。

內容

屬性

KISS (Keep It Simple Stupid)
YAGNI
Do The Simplest Thing That Could Possibly Work
Keep Things DRY
Code For The Maintainer
Avoid Premature Optimization

模塊/類作用

模塊/類

KISS

大道至簡。
大部分的系統，簡單的總是比複雜的工作的更好。

爲什麼

更少的代碼可以節省書寫的時間，擁有更少的BUG，並且易修改
大道至簡，至繁歸於至簡
不是當沒有東西可以添加的時候，而是在沒有可以帶走的東西的時候達到完美。

資源

KISS 原則
Keep It Simple Stupid (KISS)

YAGNI

用時實現。
YAGNI就是："you aren't gonna need it"的簡寫：需要的時候再實現它（現在不需要它）

爲什麼

任何只是在明天需要用到的工作特徵，意味着它就是去了當前迭代需要的工作特徵的作用
這會導致代碼的臃腫；軟件會變得龐大和更加複雜

怎麼做

總是在你確切需要它們的時候實現它們，而不是你預見要用到它們的時候去實現。

資源

You Arent Gonna Need It
You’re NOT gonna need it!
You ain’t gonna need it

Do The Simplest Thing That Could Possibly Work

用最簡單的方式實現需要的功能

爲什麼

如果我們只是關注問題的本身到底是什麼，那麼真正的過程將會最大化的解決問題。

怎麼做

-問一下自己：可以解決這個功能的最簡單的方法是什麼？

資源

Do The Simplest Thing That Could Possibly Work

Keep things DRY

在一個系統中每個知識點都必須只有一個唯一的，清楚的，權威的代表

一個程序中每個重要的功能塊應該只在源文件中的一個地方去實現。
相似功能被不同的代碼塊聲明的地方，一般可以通過抽象出不同的部分把它們組合到一個文件中。

爲什麼

重複代碼（有意或者無意）都會導致維護困難，不利於分離，並且邏輯矛盾混亂
對系統中的任何元素修改，另一個邏輯不相關的元素不需要改變
此外，邏輯相關的元素，所有的改變要可預見和一致，並且保持同步

怎麼做

把業務邏輯，長表達式，比如狀態，數學公司，元數據等等，只放在一個地方
識別系統中用到的每塊知識的唯一，清楚的源文件，然後使用這個源文件來產生相應的實例（代碼，文檔，測試，等等）
應用 Rule of three.

資源

Dont Repeat Yourself

Code For The Maintainer

易維護

爲什麼

維護是任何工程最昂貴的階段

怎麼做

想象自己是一個維護者
編碼的時候總是想象如果維護你的代碼的那個人是個暴力傾向的精神病患者，並且知道你的住處
用這種方式去編碼和註釋，不論什麼檔次的人拿起你的代碼，會樂於閱讀並且學習它。
不要讓別人去思考
使用最少驚訝的原則（一看就明白）

資源

Code For The Maintainer
The Noble Art of Maintenance Programming

Avoid Premature Optimization

避免過早的優化

Donald Knuth名言：
程序猿浪廢了大部分的時間用來思考，或者擔心，程序的非關鍵部分的速度，並且這會嚴重影響到考慮測試和維護時的效率。
我們應該忘了小的效果，對97%的時間：都浪費在了過早的優化上面。然而我們不應該放棄那關鍵的3%。

要理解什麼纔是關鍵部分，而不是過早優化。

爲什麼

對於瓶頸所在未知
在優化後，可能不利於閱讀和維護

怎麼做

Make It Work Make It Right Make It Fast（可以工作，正常運轉，快速就好）
需要的時候才進行優化，並且只有在你發現瓶頸了後再優化

資源

Program optimization
Premature Optimization

Minimise Coupling

最小化耦合。

模塊或者組件間的耦合就是他們之間的獨立性；低耦合最好。
換句話說，耦合就是A代碼修改後，B代碼出錯的可能性。

爲什麼

一個模塊中的代碼修改之後，通常會影響其他的模塊
組裝的模塊間可能需要更多的工作或者時間來改變，因爲依賴模塊改變了。
一個特別的模塊可能會不容易複用或者測試，因爲必須包含的依賴的模塊改變
開發者會畏懼改變代碼，因爲他們不清楚這會有什麼影響。

怎麼做

消除，最小化，和降低需要關聯的複雜度
通過隱藏實現細節，耦合度就降低了
應用迪米特法則

資源

Coupling
Coupling And Cohesion

Law of Demeter

迪米特法則

不要和陌生人說話

爲什麼

它通常會導致緊耦合
它可能會透漏更多的實現細節

怎麼做

一個對象的方法應該只是調用：
- 對象本身
- 方法本身的參數
- 方法中創建的對象
- 對象的任何直接屬性

資源

Law of Demeter
The Law of Demeter Is Not A Dot Counting Exercise

Composition Over Inheritance

使用繼承

爲什麼

類之間的耦合更少
使用繼承，子類可以容易的實現需要，並且打破LSP

怎麼做

測試LSP（可替代）來決定什麼時候繼承
組合的關係是“有一個”或者“使用一個”，繼承是“是一個”

資源

Favor Composition Over Inheritance

Orthogonality

正交的基本概念就是概念不相關的東西不應該在系統有關聯

資源：Be Orthogonal

與簡單相似：設計的越是正交，表達式就越少。學習，閱讀，編碼一種編程語言就越容易。
正交的特徵意味着上下文的獨立性；關鍵的參數具有對稱和一致性。

資源：Orthogonality

Maximise Cohesion

單個模塊或組件的聚合就是它形成一個有意義單元的職責程度；越高的聚合越好。

爲什麼

增加了理解模塊的難度
增加了維護系統的難度，因爲邏輯域上的改變影響多個模塊，並且一個模塊的需求變化會導致其他模塊的變化
增加了複用模塊的難度，因爲大多數的應用將不再需要模塊提供的操作的隨機組合

怎麼做

相關的功能集羣共享一個唯一的職責

資源

Cohesion
Coupling And Cohesion

Liskov Substitution Principle

里氏替換原則就是對於對象行爲的全部預期：
程序中的對象應該是可以用他們的子類型實例替換的，而不會影響程序的正常。

資源

Liskov substitution principle
The Liskov Substitution Principle

Open/Closed Principle

軟件實體應該對擴展開放，對修改關閉。即在不改變源碼的情況下擴展其行爲功能。

爲什麼

對已有代碼的最小化改變提高可維護性和健壯性

怎麼做

書寫可擴展的類（而不是可修改的）
只是顯示需要修改的可移動部分，其他的隱藏

資源

Open Closed Principle
SOLID JavaScript: The Open/Closed Principle

Single Responsibility Principle

單一職責原則，一個類應該只有一個可以改變的原因。
詳細：每個類應該有一個單一的職責，並且這個職責應該被這個類完全封裝。
職責可以用來定義爲一個可以改變的原因，因此一個類或模塊應該擁有一個，並且只有一個，改變的因素。

爲什麼

維護性：改變應該只是在一個模塊或類中需要

怎麼做

應用捲曲原則

資源

Single responsibility principle

Hide Implementation Details

隱藏實現的細節。一個軟件模塊通過提供接口來隱藏實現細節，並且沒有任何的無關信息

爲什麼

當實現改變時，使用接口的客戶端不需要改變

怎麼做

最小化對於類和成員的訪問
不要成員數據設爲public
避免在類的接口中實現私有的方法
隱藏更多的實現細節來降低耦合性

資源

Information hiding

Curly’s Law

克里法則就是關於爲任何的特定的代碼選擇一個單一的，清楚定義的目標：就是做一件事情。單一原則

Curly’s Law: Do One Thing
The Rule of One or Curly’s Law