良好的開發習慣助你一臂之力——程式員日常開發注意事項總結

作為一名剛入行不久的菜鳥 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 修複。這樣反而很影響我們的開發效率。

當我們在新分支上完成新需求開發時，應該先将目前版本分支合并到新分支上進行測試，沒有問題後再合并到目前版本分支上。

小結

在日常的開發中，養成良好的開發習慣不僅可以幫助我們提高開發效率，還可以降低開發過程中出現的一些不必要的失誤與錯誤，間接地也改善了我們的代碼品質。

是以，小夥伴們一定要養成良好的開發習慣喲，一起加油！歡迎補充。