業務也懂了，系統梳理了，要做的需求也弄懂了，是不是就該編碼了？

對的，確實該編碼了。但在寫之前，有以下三個方面要注意。

要和團隊統一格式。否則你在本地格式化一下，會有很多衝突，程式碼就很難管理了。一般團隊都會給你一個配置檔案。配置一下即可。

有一些編碼規範，就算公司沒要求，你對自己也要有要求。這方面的資料很多，我建議你在編碼時問自己幾個問題

1、我這樣寫，別人是否能透過命名看出程式碼的意思？好的命名可以傳遞大量的準確資訊。不好的命名不會傳遞任何資訊，糟糕的命名則會傳遞錯誤的資訊。

2、對於類中的每個方法，我有講清楚方法的目的、前置條件（傳入的資訊）、執行的結果、異常資訊嗎？

3、我的註釋是必要的嗎？它有傳遞正確的資訊嗎？新人最容易出現極端編碼，要麼不寫註釋，要麼全是註釋，註釋比程式碼還多。

檢驗方法：讓同事來看你寫的程式碼。你什麼都不講的情況下，對方能不能看懂，能不能提出改進意見？

1、在git上建立自己的工作區，哪怕團隊就你一個人，你也要建立自己的工作區。

2、提交程式碼前，先拉取從git上拉取程式碼，如果有衝突，根據程式碼邏輯解決衝突。如果拿不定注意找對應同事溝通處理。

3、解決衝突後，要進行簡單的測試。如：單元測試，功能測試。保證功能正常執行。

4、編寫程式碼過程中，養成Ctrl + S 儲存程式碼的習慣。避免突然斷電等突發事件。

5、提交git程式碼時，要寫清楚提交內容。不要全是什麼”修復bug“之類的籠統的描述。

6、每個上線版本程式碼都要打分支tag，偶爾會有需求在老分支上做修改。

接下來，可以開始編碼了。