做個有理想的精致碼農(nóng)，寫出行云流水的代碼

????《5分鐘從學生到程序員》第13課。

????初級工程師往往被人吐槽為代碼搬運工，大段大段的復制代碼過來用，自己只要做稍微的業(yè)務調(diào)整。這個是每個程序員都需要經(jīng)過的階段，所以沒什么好不舒服的。就算剛入行，不能行云流水的寫代碼，但還是可以寫出行云流水的代碼。

????行云流水的寫代碼，說明工程師的技術水平高，掌握眾多的開發(fā)技巧和駕馭框架的能力等。但是寫出的代碼，一定是行云流水的代碼嗎？不一定，有可能他們寫出的代碼很丑。行云流水的代碼，是代碼清晰，結構簡潔，易于維護，符合規(guī)范。

????行云流水寫代碼是高級工程師的事，我們在這里不探討。我們做為一個有理想的碼農(nóng)，一定是要能寫出行云流水的代碼。下面分享幾個寫高質(zhì)量代碼的技巧。

1. 一件事原則

????一件事原則，即一個文件只做一件事，一個類只做一件事，一個函數(shù)只做一件事，甚至一行代碼只做一件事。

????分享個案例：以前有做個餐飲系統(tǒng)，業(yè)務流程很復雜，我們采用小前端（服務號）+ 大后臺的結構實現(xiàn)，前端用VUE框架。應用已經(jīng)上線運營，有天客戶提要改需求，訂單功能要加內(nèi)容，業(yè)務內(nèi)容我就不講了，很復雜，采用智能分析，應用餐廳過往營業(yè)數(shù)據(jù)自動算出訂單的內(nèi)容。要改的內(nèi)容，本來很簡單，我估計也就一個小時搞定，就可以發(fā)個小版本，結果半天還沒搞出來。

????我就很奇怪，跑到工程師那里了解情況，工程師羅里吧嗦的給我講了好多，搞不清楚他在講些咋，直接看代碼，發(fā)現(xiàn)他生成訂單和查看訂單詳情做在同一個vue里，到處都是編輯和查看的判斷，把自己搞迷糊了。

????這種顯然是有問題的，一個文件做兩個功能，剛開始可能省事，但是你要祈禱客戶不改需求，不然后面你就會連想死的心都有。

????再分享一個函數(shù)只做一件事的案例：我有一次去朋友公司玩，他們正在討論接口，我就順便聽了一下，他們做在線教育app，在討論首頁接口，首頁有banner、推薦課程、推薦文章、熱門課程等，他們決定是首頁所有的數(shù)據(jù)都用同一個接口傳回來。給出來的理由是首頁只要一個接口，這樣就不會出現(xiàn)多次訪問網(wǎng)絡，多次解析數(shù)據(jù)的情況，體驗會更好。

????我當時也嘴賤，給他們建議說不要做成一個接口，首頁是經(jīng)常會變的，你們要是這樣做，到時這塊的維護成本就會非常高，他們的技術老大還是堅持用一個接口。這個事情就過去了，后來朋友給我電話，說當時沒聽我的，后來首頁改了幾版，工程師都快崩潰了。

????一行代碼只做一件事，這個好理解，如果把代碼寫復雜了，你到時調(diào)試都調(diào)不出來到底發(fā)生什么錯誤。

2. 編碼規(guī)范

????現(xiàn)在很多IDE都自帶編碼規(guī)范，網(wǎng)上也有很多大企業(yè)的編碼規(guī)范，有阿里的，有華為的。如果公司有編碼規(guī)范最好，按公司的編碼規(guī)范寫代碼。如果公司沒有，建議去找個編碼規(guī)范，不需要全部執(zhí)行，全部是執(zhí)行不下去的。

????給個建議，你從找來的編碼規(guī)范中，挑最重要的十到二十條來執(zhí)行，像注釋、命名規(guī)范、大小寫規(guī)范這些是一定要有的，這樣你才能寫出一致的代碼出來。不然從張三那里復制過來的代碼，采用的是匈牙利命名法printEmployeePaychecks()；從李四那里復制過來的代碼，采用的是下劃線命名法print_employee_paychecks()，那你的代碼就沒眼看了。

3. 提取工具類庫

????把一些常用的，比如字符串的處理、日期時間的處理、圖形圖像的處理、文件的處理等，提取出來做成工具類庫，隨著你的工具類庫的豐富，你寫代碼會越來越簡單，開發(fā)速度會越來越快。而且代碼也簡潔明了，本來可能是十幾行的代碼，現(xiàn)在只是一個函數(shù)調(diào)用就搞定了。代碼維護起來也方便。

4. 不要出現(xiàn)重復代碼

????我們直接復制代碼是最快的，所以很多工程師寫過一段代碼，再用到的時候，習慣把這段復制過來，改一改值，功能就成了。

????這種是非常不好的習慣，如果這段代碼是業(yè)務代碼，那就更麻煩，需求是隨時變的，業(yè)務調(diào)整很正常，甚至一天三變都有，如果業(yè)務代碼到處復制，剛開始你還記得幾個地方都改，后面改多了，可能就開始少一個，再往后少的地置就越來越多。這個就是傳說中的改一個bug，會產(chǎn)生更多的bug的一個方面。

????所以在你按ctrl+C的時候，想一想，有沒有可能做成一個函數(shù)？正常都是可以的，這樣你的代碼質(zhì)量就會高很多。

5. 看代碼像看書一樣方便

????我們對看書都有經(jīng)驗，翻開書是目錄，我們掃一下目錄，就知道這本書有多少章多少節(jié)，大概在講什么內(nèi)容，如果有某一節(jié)感興趣，直接翻到對應的頁數(shù)就可以。

????我們在看代碼，很多時候都不知道入口在哪里，好不容易找到入口，再一看，業(yè)務實現(xiàn)代碼，函數(shù)調(diào)用，都交叉在一起，一個函數(shù)幾十行、幾百行，甚至幾千行的都有。我真見過三千行的函數(shù)，這個不是吹的。你說這代碼怎么看，所以在前面講到程序員不喜歡看代碼。

????我在講功能開發(fā)那節(jié)課的時候，有講功能的實現(xiàn)步驟，也就是設計部分，你知道實現(xiàn)功能的步驟，在入口的地方，實現(xiàn)上是這幾個步驟的函數(shù)調(diào)用，就像書本的章節(jié)一樣，再用注釋標出來它們實現(xiàn)什么業(yè)務，業(yè)務在各自函數(shù)中實現(xiàn)，對哪個業(yè)務感興趣，就進到哪個業(yè)務中到看對應代碼。如果哪個業(yè)務出bug，只要到對應的函數(shù)中去找問題就可以，不需要把所有的代碼都看了，才知道哪里出問題，改的時候還要擔心會不會影響其它的地方。

????這樣，看你的代碼就像看書一樣方便，以后維護你代碼的人就不會罵你，你也會比較少耳朵發(fā)癢。

????你可能會說，這是結構化編程，現(xiàn)在用的是面向?qū)ο?，是設計模式。這又有什么關系，我講的是原理，是讓代碼容易編寫，容易閱讀，容易維護的原理。你可以把那些函數(shù)理解成是類的實例，是某個設計模式就行了。

6.總結

????這節(jié)課我們講如何寫出高質(zhì)量的代碼，這個不需要你有多高超的技術水平和框架能力，只要采用一些簡單的技巧，在按ctrl+C的時候想想能不能抽象出一個公共函數(shù)，在一個文件、類、函數(shù)，甚至一行代碼中，只實現(xiàn)一件事，有一個自己嚴格執(zhí)行的簡單的編碼規(guī)范，然后在寫代碼時，讓他看起來像看書一樣方便，那你的代碼質(zhì)量就已經(jīng)非常高了。