本文由葡萄城技術團隊原創並首發程序員
轉載請註明出處:葡萄城官網,葡萄城爲開發者提供專業的開發工具、解決方案和服務,賦能開發者。設計模式
首先咱們會先提出這個問題,若是你向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原則是指在開發時只須要將應用程序必需的功能包含進來,而不要試圖添加任何其餘你認爲可能須要的功能。開發過程當中爲了應對未來可能的提出的需求,提早開發一些功能進去,咱們一般會花很多時間成本在這些過分設計的功能開發上,但可能將來的兩三年內這個設計根本沒有用到。應把更多的精力花在更重要的功能開發上,適度假設將來需求的規劃,加速後期功能迭代和代碼維護。
雖然上面提了不少原則和規範,但這些規範須要在長期在工做中的實踐纔能有更深的理解的。但願您能從本文中瞭解一些基礎,最後,但願你們都能寫出優美、規範的代碼。