加入阿里技術團隊三年，哪些習慣讓我在工作上持續受益？

本文作者：旺德，阿里雲高階開發工程師

2017年研究生畢業，我加入阿里巴巴資料庫技術團隊，從事分散式資料庫研發，如今算來已經有三年事件了，在這期間，我深度參與了雙十一背後的資料庫PolarDB-X從設計到實現的全過程。在這三年的時間裡，於我而言，最大的收穫來自兩方面：

根據工作經驗和觀察身邊優秀的同事，我發現優良的工作習慣是區別一般工程師和專家工程師的重要素質。想要提升自己，必要認識到哪些工作習慣會拖延工作效率，提升專案複雜度，增加溝通難度，甚至讓合作伙伴失望，然後改正它們。刻意練習那些被證明有效實用的工作方式，成為習慣。在阿里的這三年，我積累了這些工作習慣：

01

最基礎也最重要的習慣：想清楚再動手。大模組和功能，詳細的設計文件必不可少。小模組和功能，最好動手之前，在白板或紙上寫畫清楚，並記錄下來，千萬不要靠巧合程式設計，要理解正在做的事情，並全面考慮各種可能性。

設計、編寫正交性好的程式碼模組。這是大家公認的良好程式設計習慣，但說起來容易，做起來難。工程師可能會圖一時之快，編寫重複、複雜的“麵條程式碼”，隨著程式碼量膨脹，這無疑會是程式碼維護和問題排查的災難。平時最好能刻意練習編寫正交性好的程式碼（剛開始可能花時間，但要熟悉這種思維習慣），學習業界優秀的程式碼也是精進的方式。這裡簡單列四點實用技巧：

• 不向其它模組暴露任何不必要的資訊，也儘量不依賴其它模組，隱藏複雜性

• 儘量避免編寫相似的函式，讓複用變的容易。

• 儘量避免直接使用全域性變數。

• 編寫獨立的函式，減少函式間的依賴，函式解耦的一些技巧：

• 只呼叫物件自身的函式。

• 只呼叫傳入引數物件的成員函式。

• 只呼叫函式內部建立物件的函式。

• 減少函式的長度。

  
  

• 不要在重構的同時加功能；
• 重構前確保擁有良好測試，確保重構對系統重量的影響最小化；
• 採取短小、深思熟慮的重構節奏。

把低階的知識放在程式碼裡，註釋留給高階的說明，糟糕的程式碼才需要許多註釋，當然也不能沒有註釋。commit message也要認真寫。

時刻考慮併發對程式碼的影響，面向併發設計；時刻考慮空間和時間效率；時刻考慮Corner case。

為專案制定詳細的編碼規範，並嚴格遵守。精心的為你模組、檔案、變數和函式命名，意義清晰無歧義。合理佈局檔案和資料夾。

關於bug排查。

• 遇到bug，不要恐慌，相信自己能解決它。學會評估bug的影響面。
• bug是你的還是別人的沒有關係，不要抱怨，問題已經在那了，解決它。
• 如果排除一個bug花費了很長時間，思考能否做點什麼（例如增加日誌、總結文件、最佳化程式碼等），讓下次排查更容易。
• Crash early，一旦發生異常，立即崩潰，讓問題第一現場儘早暴露。如果認為什麼不可能發生，就用斷言確保它不會發生，不要自己說服和欺騙自己。

• 列印含有跟蹤資訊、格式統一規範的日誌，尤其是異常路徑的。

儘可能多、儘可能早、儘可能全面地測試。讓質量成為正式的需求。

• 單元測試要覆蓋正向路徑和異常路徑，關注一些邊界條件，並且校驗結果。
• 模組測試、整合測試、壓力測試、效能測試都應該自動化。

• 不要忽略資源耗盡、故障恢復的測試場景

關於工具使用：

• 選擇一種強大的編輯器，儘可能學好它，利用它。
• 儘可能多的自動化，讓計算機去做那些重複的工作，顯然它們更擅長。這既避免了出現錯誤，又提高效率。

• 使用配置檔案，而不是整合在程式碼裡。把抽象放進程式碼，把細節放進後設資料。