團隊協做中，如何寫出讓同事讚不絕口的代碼

團隊中的每一個人都會用不一樣的視角來’審視‘你的」做品「，那麼咱們如何拿出一份像藝術品同樣的項目代碼，而後贏得得同事們的讚許呢？

做者/ 瓊虎(安增平)

編輯/ 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-