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

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

（1）大型資料庫專案的磨礪。資料庫作為三大基礎軟體之一，複雜度不言而喻，而分散式資料庫將這個複雜度又提升了一個層次，因此嘗試這個領域的企業並不多。一畢業就有機會挑戰這個級別的難度，磨礪造就成長。

（2）有幸與一群實力超群的小夥伴一起工作，從他們身上能學習到太多東西了。

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

01

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

02

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

不向其它模組暴露任何不必要的資訊，也儘量不依賴其它模組，隱藏複雜性
儘量避免編寫相似的函式，讓複用變的容易。
儘量避免直接使用全域性變數。
編寫獨立的函式，減少函式間的依賴，函式解耦的一些技巧：

只呼叫物件自身的函式。
只呼叫傳入引數物件的成員函式。
只呼叫函式內部建立物件的函式。
減少函式的長度。

03

如果發現程式碼中不滿意的地方，早重構、多重構。儘量不要容忍軟體中的“垃圾”。重構前應該確保：

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

04

系統裡的每一項知識都是單一、無歧義、權威的，要與所有研發人員達成一致。避免合作者之間因為理解的差異，編寫出語義相悖的程式碼。

05

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

06

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

07

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

08

關於bug排查。

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

09

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

單元測試要覆蓋正向路徑和異常路徑，關注一些邊界條件，並且校驗結果。
模組測試、整合測試、壓力測試、效能測試都應該自動化。
不要忽略資源耗盡、故障恢復的測試場景

10

關於工具使用：

選擇一種強大的編輯器，儘可能學好它，利用它。
儘可能多的自動化，讓計算機去做那些重複的工作，顯然它們更擅長。這既避免了出現錯誤，又提高效率。
使用配置檔案，而不是整合在程式碼裡。把抽象放進程式碼，把細節放進後設資料。

11

做一個知識輸出者，多寫文章和總結，在自己常用的平臺分享，總結和覆盤能加快進步。不要害怕交流，不要害怕暴露缺點，有效的交流越多，你就越有影響力。

12

今天了不起的軟體，比明天完美的軟體更重要。

13

最後，多運動，保持頭髮和衣著整潔，保護好頸椎，保護好視力...

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

相關文章