本文經四猿外（id:si-yuanwai）授權轉載
如若轉載請聯絡原公眾號
我總結了 10 個程式設計師的好習慣，今天分享給大家。
1. 引入新的技術棧的時候，要以官方文件為主
在專案裡，無論使用新的 jar 包，還是用新的中介軟體，一定要去看官方文件。
現在網上的技術文章魚龍混雜，再加上國內那個不咋地的搜尋引擎，所以在網上搜靠譜的技術文章，就相當於在屎坑裡撈金子。
比如，如果你想要對 SpringBoot2 寫的程式碼進行單元測試，JUnit 版本你可能已經是 5 了。但你搜到的網上文章很可能會告訴你測試用例需要註解:
@RunWith(SpringRunner.class)
但是官方文件說了，其實如果你用 JUnit5，就不用加這個註解了，加了反而可能引起不必要的衝突。
所以，官方文件對新技術的引入是唯一的參考金標準。
2. 一定要悄悄地把程式碼測的沒問題了再交付
在職場上，什麼樣的人才能快速成長、快速得到重用？答案是可靠的人。
那就程式設計師來說，什麼樣的人才算是可靠的人？答案是交付可靠的技術產品。
那可靠的產品第一評估標準就是 bug 少。這個 bug 少是別人評估的，而不是自己評估的。
無論咱們自己程式碼實現成什麼樣子，哪怕是程式碼寫的還不完美，但是，只要咱們透過自測，在提交之前儘可能把問題解決掉，讓別人少發現你的錯誤，尤其是低階 bug，那麼你才是一位可靠的程式設計師。
所以，交付任務前，一定要自己把程式碼全方位地測試一遍，保證自己有著優秀的口碑才好。
3. 打日誌的時候儘可能把輸入、輸出以及耗時都打印出來
我們打日誌的目的是什麼？是為了定位問題的。
問題有哪些？其實大體就兩種，邏輯問題和效能問題。
邏輯問題，我們如果列印了輸入和輸出，那麼根據業務規則，這麼一對照就能很容易定位到問題。
效能問題，我們無論是透過像 grep、sort 等 shell 命令去直接對日誌做個過濾加排序，還是透過日誌蒐集加日誌搜尋等工具，都能很容易的發現到問題。甚至還可以和監控系統聯合起來，直接做預警。
所以，打日誌的時候，我們要記得把輸入和輸出以及時間都打印出來。
4. 學好 Git
Git 這東西太重要了。現在的團隊開發，用 Git 管理各種程式碼版本，程式碼分支。如果你用不好 Git，很容易就會因為合併程式碼、升級版本等情況，產生出許多沒必要的 bug。
一個用不好 Git 的團隊，可能每次上線，都會帶來那麼幾個莫名其妙的問題。
給大家分享一本非常不錯的 Git 開源手冊。
這本手冊在豆瓣上評價極高，之前 9.3，現在也有 9.1 的高分，其作者是 GitHub 的員工，內容主要側重於各種場合中的慣用法和底層原理的講述，手冊中還針對不同的使用場景，設計了幾個合適的版本管理策略。
簡而言之，這本手冊無論是對於初學者還是想進一步瞭解 Git 工作原理的開發者都非常合適。
5. 優先實現功能，效能問題或許沒那麼著急
我在帶團隊的時候，經常發現有些剛入行的同事，會邊寫程式碼邊糾結自己寫的程式碼效能是否有問題。其實真的不必這樣。像我們這些老程式設計師，都知道過早最佳化有時候可能白花費功夫。
像咱們如果寫一個批處理的定時任務，這個任務要求只要在凌晨執行，在大家上班前任務完成就行。那麼，這個任務從凌晨兩點執行到六點和執行到四點，有什麼區別嗎？
最佳化程式碼一定要適度，要在寫完功能之後，看功能會怎麼被使用，根據實際的要求，去最佳化真正需要最佳化的地方。
6. 先實現最確定的需求，不確定或者模糊的需求先往後放
實現需求的先後順序，注意一定要以需求的可靠程度為準。
在分配給我們的需求裡一般分兩類：
- 有的需求是我們和產品經理都非常明確的需求；
- 也有的需求比較模糊：開會討論時大家都覺得沒什麼問題，但是一到程式碼實現的時候，就發現還存在很多問題。
這時候，咱們應對的技巧是，先對這些需求搭一個統一的架子，把已經非常明確的需求先開發出來。
由於架子搭建出來了，這時候再和產品經理討論那些模糊的需求，很容易就能讓產品明白困難的地方，這樣就可以把溝通難度降到最低。
7. 主動找專案裡的問題並給出解決方案
問題是什麼？問題就是在實踐過程中需要解決的東西。
把這些問題一個個找出來，解決掉，這些解決問題中產生出來的方案，全會形成推動專案前進的推動力。那麼產生這些推動力的你自己，一定會從中獲益良多。
8. 評估開發週期，要留出冗餘時間
留出冗餘時間的目的很明確，在咱們開發的時候，遇到的意外情況太多了：
- 需求又雙叒叕變了
- 團隊人員有變化
- 當初估算的時間樂觀了
- 這個功能需要動老程式碼
- 需要跨團隊合作開發
- 領導說“加個小功能”，領導認為這個小功能不影響開發週期（此處省略二百字）
- ……
所以，冗餘時間是要留出來的。
留出的冗餘時間不等於摸魚時間，開發還是按照正常的節奏幹，早做完早交付。
9. 不要光看書去學習技術，要把感興趣的技術透過程式碼實現出來
咱們程式設計師最重要的就是實踐，能把學到的知識轉化為實踐用到工作上。
光看書學習技術，很可能只會讓咱們產生出已經學會的錯覺。只有透過程式碼把感興趣的技術實踐練習了一遍，咱們才真正能明白這技術實際用起來是什麼樣子，需要注意什麼。
動手實踐的重要性就不多說了，我之前也寫過一些文章介紹過如何動手實踐，比如這篇透過模擬環境來學習高併發：我招了個“水貨”程式設計師
10. 英語還是挺重要的
你不得不承認，IT 這行，基本所有的創新都誕生於英語的世界。
比如 k8s，就我所知就是國內英語好的技術人員從英語社群逐漸在國內推廣開來，而這些推廣了 k8s 的先驅也自然掌握了 k8s 的話語權。大家可以看看 k8s 在市場上的流行程度，也可以看看一位 k8s 專家的工資大概是多少。
而且，我前面說過，大家引入新技術一定要看官方文件，官方文件百分之八十都是英語的，所以英語確實重要。
如果英語不好，是不是就沒機會了？沒這麼絕對。
就說我吧，不瞞大家，我英語四級沒過，但還是照樣能看英語資料，照樣和別人一起翻譯了國內的第一本 Hibernate 技術書。
當初我用 Hibernate 在國內算是比較早的一批程式設計師了，也經常去論壇回答問題，所以後來就有人找我一起翻譯書。我最開始是抗拒的，覺得自己英語太爛了，翻譯不好。後來我又想，既然我能看著英語文件學 Hibernate，要不就試試。於是就這麼著幹了一把。
作為一個過來人，我想說的是，技術文件沒有特別複雜的語法、生僻單詞，而且現在還有翻譯軟體、外掛可以幫我們閱讀。即使英語基礎一般，也沒什麼大不了的。
