作爲一名剛入行不久的菜鳥 Java 程序員，經常被自己的一些不好的開發習慣給坑，導致明明運行好好的項目突然出現意想不到的 Bug。然後，我就被導師叫過去進行了一番細心的指導，這裏要特別感謝一下我的導師，可以說他是我目前開發路上的指路明燈。
注意事項
這裏，我總結了幾條開發中我認爲比較重要的注意事項：
1. 完善代碼註釋
我相信很多小夥伴跟我一樣，自己寫的代碼過一段時間去看就不知道是怎麼回事了，而且經常發出疑問，“咦，這是我寫的代碼嗎”。所以，註釋是一個很好的東西，它不僅可以幫助我們理解程序中的每一行代碼在做什麼，而且可以降低代碼的維護成本。
但是，註釋也不能隨隨便便的寫，任何地方都寫。這樣會讓代碼顯得冗餘繁雜，反而降低了代碼的可讀性和維護性。
我們在寫註釋時要講究簡明扼要，突出含義。對於類的註釋，要表明類的功能和副作用（即使用該類時會不會出現一些異常等）；對於方法的註釋，要表明方法是幹什麼的，每個參數的含義以及方法的副作用。
2. 完善單元測試
單元測試可以幫助我們發現程序中一些的 Bug，提升代碼質量，提高開發效率。
很多小夥伴應該和我一樣也會時不時偷懶，沒有去寫單元測試，覺得很麻煩。但是，我在導師的督促下也補上了單元測試，後來我每次改了 Bug 後都用單元測試跑一下，就檢查出了問題，比之前自己人工測試要快的多。突然就發現了單元測試的好處，雖然前期寫單元測試有點麻煩，但是後期的收益是槓槓的，真香。
3. 過時的方法代碼不要急着刪除
在項目迭代中，我們會不斷重構一些之前寫的不是很好的方法。但是，過時的方法不應該馬上刪除，而是應該等重構的新方法上線運行一段時間，沒有出現異常後纔將過時的方法刪除。
爲什麼要這樣做呢？因爲我們並不能保證重構的新方法上線後一定能穩定運行。如果上線後新方法在運行的過程中出現 Bug，並且影響了用戶的部分操作。那麼，過時的方法就可以作爲一種應急的替代方法，將新方法換下來，以保證用戶正常操作。之後，我們再進行新方法的 Bug 排查與修復。
4. 在一個版本的迭代中，項目的 API 只能增加不能刪除
在前後端分離的項目中，當需要修改項目 API 地址時，應該是在舊的 API 地址上再添加新的 API 地址，舊的 API 地址應保留至項目迭代幾個版本後，沒有出現問題才進行刪除。
爲什麼要這樣做呢？因爲隨着時間的推移，我們可能並不清楚到底有多少地方調用了舊的 API 地址。所以，當我們用新的 API 地址替換舊的 API 地址時，並不能保證所有的地方都完成替換了或者在替換時因爲一些其他因素而漏掉了一些。如果此時就把舊的 API 地址刪除了，那麼上線後會存在很多風險。
比較好的做法就是讓舊的 API 地址隨着項目一起迭代幾個版本後才刪除，這樣我們有足夠的時間去發現遺漏的地方，減小項目上線出現的風險。
5. 請新建一個項目分支來修復 Bug
當項目出現 Bug 需要進行修復時，應該從當前版本分支（確保此分支沒有進行任何更改）上新開一個新分支來進行 Bug 修復，最後再合併回原分支上。
這樣做有什麼好處呢？首先，不會影響我們正在開發的內容；同時，我們在修復 Bug 時，並不能保證修改後的程序沒有副作用，這樣也便於我們進行測試。
6. 新建一個項目分支來完成項目新需求開發
當項目有新需求要進行開發時，應該在 Git 上新建一個項目分支來完成新需求的開發，並將分支命名成 version_版本號_需求名 這種形式。
爲什麼不直接在當前版本分支上開發呢？如果我們在當前版本分支上進行開發，當項目出現 Bug 需要馬上修復並上線時，而當前版本分支上還有我們沒有開發完的新需求，根本不具備重新上線的條件了。此時，只有重新從遠程倉庫將當前版本的內容下載到本地，再進行 Bug 修復。這樣反而很影響我們的開發效率。
當我們在新分支上完成新需求開發時，應該先將當前版本分支合併到新分支上進行測試，沒有問題後再合併到當前版本分支上。
小結
在日常的開發中，養成良好的開發習慣不僅可以幫助我們提高開發效率，還可以降低開發過程中出現的一些不必要的失誤與錯誤，間接地也改善了我們的代碼質量。
所以，小夥伴們一定要養成良好的開發習慣喲，一起加油！歡迎補充。