團隊協作中，如何寫出讓同事讚不絕口的程式碼
團隊中的每個人都會用不同的視角來』審視『你的」作品「，那麼我們如何拿出一份像藝術品一樣的項目程式碼，然後贏得得同事們的讚許呢？
作者/ 瓊虎(安增平)
編輯/ hjy
00 前言
在加入了擁有較高技術底蘊的有道精品課團隊後，發現自己在前面的職業生涯中養成的一些『作坊』習慣必須得到糾正。
在日常工作中，研發同學只在coding階段中不需要別人關心自己的程式碼，其他需要將自己的產出展示給別人的場景變得十分常見。
簡單舉幾個例子：
-
feature准入後，同產品業務線的同事需要trans-review
-
mentor每個季度要Lint-review
-
測試二輪後要diff-review
-
……
團隊中的每個人都會用不同的視角來「審視」你的」作品「，那麼我們如何拿出一份像藝術品一樣的項目程式碼，然後獲得同事們的稱讚呢？
保持在項目中做到以下幾點，便可收穫殿堂級的藝術程式碼。
以下幾點是在接手銷售轉化系統及質檢系統等幾個項目後，針對自己的不a足和團隊成員交流得出的結論。
01 使用meaningful的變數命名
在聲明一個變數的時候，儘可能的將其作用和充當的角色注入其中：
聲明一個函數，使用組合動詞而非名詞：
聲明一個集合內部包含多項內容的時候，要記得使用複數形式：
在使用數學計算公式的時候盡量提前聲明好常量，常量的注入有助於提升你在維護程式碼階段的可讀性：
在回調函數或者函數聲明的形參中，盡量保持形參的語義化，避免後期維護過程中看到前面隨意聲明的i，j，k後，又要折返到原回調處進行查看，影響開發效率：
（同時在使用TS的過程中也盡量避免使用any類型，使用這種類型在codeReview過程中可能會被靈魂拷問）同時在聲明boolean類型的時候要以is作為開頭：
做到以上這些，在codeReview中就可以保持一個自信的狀態去接受同事們領導們的審閱，因為沒有犯低級錯誤可以讓查看你程式碼的人保持心情愉悅，同時這種心情可以對你產生正回饋。
02 每個函數只做一件事
每個函數盡量保持其職責的單一性，不要出現一個非常強健的函數做了很多事情：
And這種單詞本身就不是函數的一部分，他會導致添加過多的業務依賴或職責到當前的函數中，從長遠的角度看這絕對是弊大於利的。
03 讓函數保持”純潔”
在函數外的任何東西，任何變數都不是他的業務，所以好的函數應該和函數外的任何變數保持好隔離。
下面這段程式碼可能只有剛入門的新手才會寫出來，但是這種混亂的邏輯在業務複雜了之後，很可能會混入『你』的程式碼中：
上面的例子可以改成下面這樣：
當然在ES6的使用過程中上述問題普遍已經不存在了，但純函數的思想需要時刻謹記。
04 模組化業務邏輯
當你在創建了一些函數之後，發現他們在當前的業務中做了一些比較類似的行為。例如，驗證用戶登陸的用戶名和密碼，那麼我們最好可以將其歸類為一個模組中。
這裡我們可以稱之為驗證模組，而不是簡單的使用一個util或者server將其集中起來就完事了：
05 簡化條件邏輯
如果一個業務中出現了大量的if else這種內容，想必開發人員看到會十分頭痛。
舉個簡單的例子：
仔細看下這裡的else其實是不需要的，我們可以通過提前返回來remove掉：
06 enrich u Error log
當我們瀏覽某個App或網站時，經常會在點擊某個按鈕彈出「An Error Occurs」這種提示，這種提示很不友好，我們無法排查到底出現了什麼原因，用戶更是一頭霧水，但是假如在出現這種錯誤的時候將描述資訊填充的完整些，對用戶或是技術支援都會有一個很棒的使用體驗。
例如：當用戶在表單中沒有輸入資訊：
當用戶此時網路出現了故障：
對開發者而言，一個詳盡的提示能讓你輕鬆定位到問題，節省了大量的時間：
包含但不限於這幾種錯誤格式，還有showMessage等方法可以提供……
07 利用好編輯器中的插件
在VSCode下開發的同學，可以通過安裝prettier來保持漂亮的程式碼。同時藉助ESLint可以讓你在開發時注重縮進、空格這些格式化的內容。
假如在開發過程中注入了TS，那麼開啟typescript-eslint會幫助你規範自己的類型定義，塑造一個風格嚴謹的程式碼style。
藉助這些插件讓我們的程式碼格式化時間大大降低，從而我們可以將更多的時間放在提升程式碼品質上。
08 總結
以上列舉的幾個例子較為簡單。通過這些通俗易懂的例子，大家在工作中根據自己的理解舉一反三的運用起來。那便是起到了作用。
在開發中切勿眼高手低，在編碼上做到一絲不苟，對我們技術的成長會有很大幫助。
唯有持之以恆，幾十年如一日的訓練才能見證技術圈的匠人誕生。共勉！
-END-
