|
原標題：加入阿里技術團隊三年，哪些習慣讓我在工作上持續受益？ 2017年研究生畢業，我加入阿里巴巴數據庫技術團隊，從事分布式數據庫研發，如今算來已經有三年時間了，在這期間，我深度參與了雙十一背后的數據庫PolarDB-X從設計到實現的全過程。在這三年的時間里，于我而言，最大的收獲來自兩方面： （1）大型數據庫項目的磨礪。數據庫作為三大基礎軟件之一，復雜度不言而喻，而分布式數據庫將這個復雜度又提升了一個層次，因此嘗試這個領域的企業并不多。一畢業就有機會挑戰這個級別的難度，磨礪造就成長。 （2）有幸與一群實力超群的小伙伴一起工作，從他們身上能學習到太多東西了。 根據工作經驗和觀察身邊優秀的同事，我發現優良的工作習慣是區別一般工程師和專家工程師的重要素質。想要提升自己，必須要認識到哪些工作習慣會拖延工作效率，提升項目復雜度，增加溝通難度，甚至讓合作伙伴失望，然后改正它們。刻意練習那些被證明有效實用的工作方式，成為習慣。在阿里的這三年，我積累了這些工作習慣： 01 最基礎也最重要的習慣：想清楚再動手。大模塊和功能，詳細的設計文檔必不可少。小模塊和功能，最好動手之前，在白板或紙上寫畫清楚，并記錄下來，千萬不要靠巧合編程，要理解正在做的事情，并全面考慮各種可能性。 02 設計、編寫正交性好的代碼模塊。這是大家公認的良好編程習慣，但說起來容易，做起來難。工程師可能會圖一時之快，編寫重復、復雜的“面條代碼”，隨著代碼量膨脹，這無疑會是代碼維護和問題排查的災難。平時最好能刻意練習編寫正交性好的代碼（剛開始可能花時間，但要熟悉這種思維習慣），學習業界優秀的代碼也是精進的方式。這里簡單列四點實用技巧： 1、不向其它模塊暴露任何不必要的信息，也盡量不依賴其它模塊，隱藏復雜性 2、盡量避免編寫相似的函數，讓復用變的容易。 3、盡量避免直接使用全局變量。 4、編寫獨立的函數，減少函數間的依賴，函數解耦的一些技巧： （1）只調用對象自身的函數。 （2）只調用傳入參數對象的成員函數。 （3）只調用函數內部創建對象的函數。 （4）減少函數的長度。 03 如果發現代碼中不滿意的地方，早重構、多重構。盡量不要容忍軟件中的“垃圾”。重構前應該確保： 1、不要在重構的同時加功能； 2、重構前確保擁有良好測試，確保重構對系統重量的影響最小化； 3、采取短小、深思熟慮的重構節奏。 04 系統里的每一項知識都是單一、無歧義、權威的，要與所有研發人員達成一致。避免合作者之間因為理解的差異，編寫出語義相悖的代碼。 05 把低級的知識放在代碼里，注釋留給高級的說明，糟糕的代碼才需要許多注釋，當然也不能沒有注釋。commitmessage也要認真寫。 06 時刻考慮并發對代碼的影響，面向并發設計；時刻考慮空間和時間效率；時刻考慮Cornercase。 07 為項目制定詳細的編碼規范，并嚴格遵守。精心的為模塊、文件、變量和函數命名，意義清晰無歧義。合理布局文件和文件夾。 08 關于bug排查。 1、遇到bug，不要恐慌，相信自己能解決它。學會評估bug的影響面。 2、bug是你的還是別人的沒有關系，不要抱怨，問題已經在那了，解決它。 3、如果排除一個bug花費了很長時間，思考能否做點什么（例如增加日志、總結文檔、優化代碼等），讓下次排查更容易。 4、Crashearly，一旦發生異常，立即崩潰，讓問題第一現場盡早暴露。如果認為什么不可能發生，就用斷言確保它不會發生，不要自己說服和欺騙自己。 5、打印含有跟蹤信息、格式統一規范的日志，尤其是異常路徑的。 09 盡可能多、盡可能早、盡可能全面地測試。讓質量成為正式的需求。 1、單元測試要覆蓋正向路徑和異常路徑，關注一些邊界條件，并且校驗結果。 2、模塊測試、集成測試、壓力測試、性能測試都應該自動化。 3、不要忽略資源耗盡、故障恢復的測試場景 10 關于工具使用： 1、選擇一種強大的編輯器，盡可能學好它，利用它。 2、盡可能多的自動化，讓計算機去做那些重復的工作，顯然它們更擅長。這既避免了出現錯誤，又提高效率。 3、使用配置文件，而不是集成在代碼里。把抽象放進代碼，把細節放進元數據。 11 做一個知識輸出者，多寫文章和總結，在自己常用的平臺分享，總結和復盤能加快進步。不要害怕交流，不要害怕暴露缺點，有效的交流越多，你就越有影響力。 12 今天了不起的軟件，比明天完美的軟件更重要。 13 最后，多運動，保持頭發和衣著整潔，保護好頸椎，保護好視力... 上云就看云棲號，點此查看更多：https://yqh.aliyun.com/?utm_content=g_1000100940 本文為阿里云內容，未經允許不得轉載。 |
- 關注天氣:
