之前的我是一名普通的程序員，自從看了編碼原則後，碼生如開掛！！！

怎樣才能算做是一名優秀的程序員?Martin Fowler如是說：「任何傻瓜均可以編寫計算機能夠理解的代碼。優秀的程序員只編寫人類能夠理解的代碼。」

 

 

可以理解問題，以可行的方式向最終用戶展現解決方案，並團結協做共同實現這個最終目標，這才能算做是好的程序員。那麼問題來了，如何在人數衆多的狀況下管理如此龐大的代碼呢?

這就要求你們去遵照一些原則，讓每一個成員都編寫乾淨且易於維護的代碼。畢竟，敲代碼也得講「基本法」呀~

單一職責

編碼一段時間以後，你的代碼極可能會將變得笨拙，也許具備執行多種功能的類/模塊，最終你將獲得成百上千行代碼的類。

單一職責就是針對這一問題——程序中的類或模塊應該只負責一個特定功能的任務，這有助於保持模塊最小且乾淨。

 

 

迪米特法則

當模塊相互依賴時，它們就變得緊密耦合，這意味着一個類將對其餘模塊產生依賴關係。而緊密耦合下降了代碼的靈活性和可重用性。

迪米特法則是由伊恩·荷蘭(Ian Holland)1987年在東北大學首次提出。該原理總結以下：

每一個單元對其餘單元的瞭解應該有限：只瞭解與當前單元「緊密」相關的單元。

每一個單元只能與朋友交談;不要跟陌生人說話。

只與直系朋友交談。

若是你也想成爲程序員，想要快速掌握編程，趕忙關注小編加入學習企鵝圈子吧！

裏面有資深專業軟件開發工程師，在線解答你的全部疑惑~編程語言入門「so easy」

資料包含：編程入門、遊戲編程、課程設計等。

免費學習書籍：

 

免費學習資料：

 

該原理能夠擁有獨立的類和代碼，由於依賴性較弱，其之間的關聯也更加鬆散，而你所作的任何更改都應反映在最直接的朋友身上。

 

 

乾淨的代碼比聰明的代碼好

一些程序員在寫代碼時會忍不住「炫技」，然而這種看起來很厲害的代碼比實際易懂的代碼更難理解。

這至關於對於讀者來講並不友好，至關於給他們出難題。事實上，只要代碼乾淨且易於理解，沒人會真正在意代碼有多聰明。

例如，有些人想用三元運算來執行傳統的if-else語句。三元操做是標準編程操做，這固然沒問題，但問題出在嵌套三元語句時。

let A = 10; 

let B = 3; 

let C = 25;(A>B?A:B)// fine(A>B?(A>C?A:C):(B>C?B:C))//notfineif(A>B){     (A>C?A:C) }else{ 

    (B>C?B:C) }//better複製代碼

YAGNI(You Aren’t Gonna Need It)

生活中，人們作一件事時會提早計劃並作好準備。但這在編程中不是很適用。YAGNI原則就在談這一點，永遠不要爲未來可能須要的功能編寫代碼。它極可能不須要，這是在在浪費時間。

你能夠將這一條其視爲對KISS原則的具體應用，同時也是對那些認真遵循DRY原則的人的迴應。缺少經驗的程序員一般會盡最大努力避免編寫最抽象和通用的代碼，避免使本身代碼變得笨拙。可是太多的抽象最終會致使沒法維護的代碼膨脹。

你要作的是，只在看到須要抽象的代碼時才抽象代碼。相反，不要將DRY原則應用於未來可能會反覆編寫的代碼。

簡而言之，就是活在當下，而不是未來。

 

 

用正確的工具去運用這些規則

有一些工具能夠幫助更輕鬆地遵循這些原則，例如，前端開發人員使用像Bit.dev這樣的雲組件中心來發布獨立的組件。你須要去尋找這些工具。

那麼它們又是如何幫助程序員遵循這些原則的呢?

將組件構建爲獨立的代碼段(旨在做爲獨立代碼進行發佈，重用和協做)，天然使每一個開發人員都更加註意單一職責原則。

從任何代碼庫發佈組件的自由意味着能夠共享和重用更多代碼，也免不了遵循DRY原則。這也意味着不會用從不使用的UI組件來構建完整的設計系統，而是遵循YAGNI原則，僅在須要時才構建和發佈每一個組件。

 

編寫乾淨易懂的代碼聽起來簡單，實際作起來卻並不容易。現在，這已經成爲一項必不可少的要求了。咱們須要不斷實踐，必須慢慢改變處理問題的方式，並以一種清晰的方式得出解決方案。這不是一晚上之間的過渡，而是須要幾個月和幾個項目的積累。

編程是一項團隊合做任務，項目成功與否很大程度上取決於團隊表現。在爭取不作「豬隊友」的基礎上，努力去作那個帶飛團隊的大神吧!