每個優秀程式設計師都應遵循的程式碼原則和規範
本文由葡萄城技術團隊原創並首發
轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。
什麼是優秀的程式設計師?
首先我們會先提出這個問題，如果你向10個人問這個問題，儘管可能答案不同，但是少有一點應該是一致的。而對我個人而言，一個優秀的程式設計師應該是一個能夠充分理解需求，並能提出可行性解決方案通過團隊協作向最終用戶展示成果。而說到團隊協作，就涉及到程式碼的可維護性，那麼你該如何管理龐大的程式碼庫？如果放任團隊成員提交隨意的程式碼，那麼在項目中無論在bug修復還是新增功能，都將很難完成。
如果想要實現可維護這個目標，那麼團隊中的每個成員都應該保證提交整潔且可維護的程式碼。那麼您應該讓你的團隊成員遵守一定的編碼原則。遵守這些原則，可以使你和其他人的協作變得更容易。所以團隊成員應該遵循什麼樣的規則呢？
童子軍原則
童子軍是美國社會針對未成年人的一種教育實踐制度，加入童子軍的小朋友都要學習並遵守一些規則，然後獲得各種各樣的勳章。其中一條規則是離開宿營地前進行清掃活動的原則，簡潔明了：
Leave the campground cleaner than you found it.
假設某個小朋友來到某個宿營地，不幸發現地上有兩處垃圾，然後他自己在接下來的日常活動中也製造了一處垃圾。那麼當他離開時，不僅要清理掉自己的垃圾，還有處理早先小朋友留下的兩處垃圾。而不是去尋找是誰丟的。應把注意力放在為下一個露營者創造更好的環境。
這個原則放到軟體生產中則意味著讓check in比check out時更整潔，至少不要讓程式碼變得更糟糕。
(圖片來源於網路)
避免重複
盡量在項目的開發過程中減少產出重複的程式碼、方法和類，多數的設計模式根本目的是為了減少程式碼重複，儘可能將重複使用的程式碼抽象封裝，是提高程式碼的可重用性和可維護性的最佳方式之一。
功能獨立
這裡功能獨立的意思是指，函數或方法儘可能簡單，功能儘可能獨立。
換句話來講就是，一個方法最好只做一件事，如果你覺得你的程式碼過於複雜，該怎麼做？抽方法。
初級程式設計師最常犯的錯誤就是在一個方法中包含了很多種要做的工作，這可能會在軟體的生命周期帶來災難。
簡單易懂的程式碼比「聰明「的程式碼更好
程式設計師作為社會中最聰明的群體之一，往往在寫程式碼時也會產出一些炫技的程式碼塊，這部分程式碼塊過段時間再去看，就像謎一樣存在於程式中，雖然很簡潔，但並不易讀。
例如：有些人在程式中喜歡使用三目運算而非if-else，雖然本身使用三目運算符沒有問題，但存在嵌套情況時，那麼對於後面的維護者就是一場噩夢，例如如下程式碼：
(A>B?(A>C?A:C):(B>C?B:C))
其實上面的程式碼等同於，顯然下面的格式更易懂
if(A>B){
(A>C?A:C)
}else{
(B>C?B:C)
}
迪米特法則
迪米特法則是1987年秋天由lan holland在美國東北大學一個叫做迪米特的項目設計提出的，它要求一個對象應該對其他對象有最少的了解，所以迪米特法則又叫做最少知識原則。它的意義旨在降低類和類之間的耦合，避免發生由於耦合度過大造成的因為一個類發生變化，而對另一個類造成影響。
YAGNI
YAGNI原則是指在開發時只需要將應用程式必需的功能包含進來，而不要試圖添加任何其他你認為可能需要的功能。開發過程中為了應對將來可能的提出的需求，提前開發一些功能進去，我們通常會花不少時間成本在這些過度設計的功能開發上，但可能未來的兩三年內這個設計根本沒有用到。應把更多的精力花在更重要的功能開發上，適度假設未來需求的規劃，加速後期功能迭代和程式碼維護。
總結
雖然上面提了很多原則和規範，但這些規範需要在長期在工作中的實踐才能有更深的理解的。希望您能從本文中了解一些基礎，最後，希望大家都能寫出優美、規範的程式碼。
