怎樣才能算作是一名優秀的程式員?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原則，僅在需要時才構建和發布每個組件，
撰寫干凈易懂的代碼聽起來簡單，實際做起來卻并不容易，如今，這已經成為一項必不可少的要求了，我們需要不斷實踐，必須慢慢改變處理問題的方式，并以一種清晰的方式得出解決方案，這不是一夜之間的過渡，而是需要幾個月和幾個專案的積累，
編程是一項團隊合作任務，專案成功與否很大程度上取決于團隊表現，在爭取不做“豬隊友”的基礎上，努力去做那個帶飛團隊的大神吧!
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/250515.html
標籤：其他