《5分鐘從學生到程序員》第13課。
初級工程師往往被人吐槽爲代碼搬運工，大段大段的複製代碼過來用，自己只要做稍微的業務調整。這個是每個程序員都需要經過的階段，所以沒什麼好不舒服的。就算剛入行，不能行雲流水的寫代碼，但還是可以寫出行雲流水的代碼。
行雲流水的寫代碼，說明工程師的技術水平高，掌握衆多的開發技巧和駕馭框架的能力等。但是寫出的代碼，一定是行雲流水的代碼嗎？不一定，有可能他們寫出的代碼很醜。行雲流水的代碼，是代碼清晰，結構簡潔，易於維護，符合規範。
行雲流水寫代碼是高級工程師的事，我們在這裏不探討。我們做爲一個有理想的碼農，一定是要能寫出行雲流水的代碼。下面分享幾個寫高質量代碼的技巧。
1. 一件事原則
一件事原則，即一個文件只做一件事，一個類只做一件事，一個函數只做一件事，甚至一行代碼只做一件事。
分享個案例：以前有做個餐飲系統，業務流程很複雜，我們採用小前端（服務號）+ 大後臺的結構實現，前端用VUE框架。應用已經上線運營，有天客戶提要改需求，訂單功能要加內容，業務內容我就不講了，很複雜，採用智能分析，應用餐廳過往營業數據自動算出訂單的內容。要改的內容，本來很簡單，我估計也就一個小時搞定，就可以發個小版本，結果半天還沒搞出來。
我就很奇怪，跑到工程師那裏瞭解情況，工程師羅裏吧嗦的給我講了好多，搞不清楚他在講些咋，直接看代碼，發現他生成訂單和查看訂單詳情做在同一個vue裏，到處都是編輯和查看的判斷，把自己搞迷糊了。
這種顯然是有問題的，一個文件做兩個功能，剛開始可能省事，但是你要祈禱客戶不改需求，不然後面你就會連想死的心都有。
再分享一個函數只做一件事的案例：我有一次去朋友公司玩，他們正在討論接口，我就順便聽了一下，他們做在線教育app，在討論首頁接口，首頁有banner、推薦課程、推薦文章、熱門課程等，他們決定是首頁所有的數據都用同一個接口傳回來。給出來的理由是首頁只要一個接口，這樣就不會出現多次訪問網絡，多次解析數據的情況，體驗會更好。
我當時也嘴賤，給他們建議說不要做成一個接口，首頁是經常會變的，你們要是這樣做，到時這塊的維護成本就會非常高，他們的技術老大還是堅持用一個接口。這個事情就過去了，後來朋友給我電話，說當時沒聽我的，後來首頁改了幾版，工程師都快崩潰了。
一行代碼只做一件事，這個好理解，如果把代碼寫複雜了，你到時調試都調不出來到底發生什麼錯誤。
2. 編碼規範
現在很多IDE都自帶編碼規範，網上也有很多大企業的編碼規範，有阿里的，有華爲的。如果公司有編碼規範最好，按公司的編碼規範寫代碼。如果公司沒有，建議去找個編碼規範，不需要全部執行，全部是執行不下去的。
給個建議，你從找來的編碼規範中，挑最重要的十到二十條來執行，像註釋、命名規範、大小寫規範這些是一定要有的，這樣你才能寫出一致的代碼出來。不然從張三那裏複製過來的代碼，採用的是匈牙利命名法printEmployeePaychecks()；從李四那裏複製過來的代碼，採用的是下劃線命名法print_employee_paychecks()，那你的代碼就沒眼看了。
3. 提取工具類庫
把一些常用的，比如字符串的處理、日期時間的處理、圖形圖像的處理、文件的處理等，提取出來做成工具類庫，隨着你的工具類庫的豐富，你寫代碼會越來越簡單，開發速度會越來越快。而且代碼也簡潔明瞭，本來可能是十幾行的代碼，現在只是一個函數調用就搞定了。代碼維護起來也方便。
4. 不要出現重複代碼
我們直接複製代碼是最快的，所以很多工程師寫過一段代碼，再用到的時候，習慣把這段複製過來，改一改值，功能就成了。
這種是非常不好的習慣，如果這段代碼是業務代碼，那就更麻煩，需求是隨時變的，業務調整很正常，甚至一天三變都有，如果業務代碼到處複製，剛開始你還記得幾個地方都改，後面改多了，可能就開始少一個，再往後少的地置就越來越多。這個就是傳說中的改一個bug，會產生更多的bug的一個方面。
所以在你按ctrl+C的時候，想一想，有沒有可能做成一個函數？正常都是可以的，這樣你的代碼質量就會高很多。
5. 看代碼像看書一樣方便
我們對看書都有經驗，翻開書是目錄，我們掃一下目錄，就知道這本書有多少章多少節，大概在講什麼內容，如果有某一節感興趣，直接翻到對應的頁數就可以。
我們在看代碼，很多時候都不知道入口在哪裏，好不容易找到入口，再一看，業務實現代碼，函數調用，都交叉在一起，一個函數幾十行、幾百行，甚至幾千行的都有。我真見過三千行的函數，這個不是吹的。你說這代碼怎麼看，所以在前面講到程序員不喜歡看代碼。
我在講功能開發那節課的時候，有講功能的實現步驟，也就是設計部分，你知道實現功能的步驟，在入口的地方，實現上是這幾個步驟的函數調用，就像書本的章節一樣，再用註釋標出來它們實現什麼業務，業務在各自函數中實現，對哪個業務感興趣，就進到哪個業務中到看對應代碼。如果哪個業務出bug，只要到對應的函數中去找問題就可以，不需要把所有的代碼都看了，才知道哪裏出問題，改的時候還要擔心會不會影響其它的地方。
這樣，看你的代碼就像看書一樣方便，以後維護你代碼的人就不會罵你，你也會比較少耳朵發癢。
你可能會說，這是結構化編程，現在用的是面向對象，是設計模式。這又有什麼關係，我講的是原理，是讓代碼容易編寫，容易閱讀，容易維護的原理。你可以把那些函數理解成是類的實例，是某個設計模式就行了。
6.總結
這節課我們講如何寫出高質量的代碼，這個不需要你有多高超的技術水平和框架能力，只要採用一些簡單的技巧，在按ctrl+C的時候想想能不能抽象出一個公共函數，在一個文件、類、函數，甚至一行代碼中，只實現一件事，有一個自己嚴格執行的簡單的編碼規範，然後在寫代碼時，讓他看起來像看書一樣方便，那你的代碼質量就已經非常高了。