您在平臺競標中中標了,或者,您已收到客戶的要求。
你做的第一件事是什麼?
有一本劇本很有價值。每次開始研究代碼中的新更改時都要遵循的過程。
它使您的工作更可預測、更完整和更正確。你會成爲更好的開發者。
需要發生什麼
讓我們以平臺中標中的項目爲例。這是最簡單的。
需要發生什麼?
- 編寫實現該功能的代碼
- 爲該功能代碼編寫測試
- 確保所有測試通過
- 打開拉取請求
- (通常)通過代碼審查
- 通過 UI 測試和 QA
- 成功部署到所有環境
好多啊!這不僅僅是“編寫代碼”的步驟。
您的操作手冊
每個人對如何構建劇本的偏好都會略有不同。但重要的是你有一個。
所有這些步驟都不會像預期的那樣落到實處!他們採取計劃和經驗來執行。
這是我開始一項新任務時所做的。也許它會對你有所幫助。
- 我開始一個新的 git 分支。這通常是我的第一步。
- 我找到了需要更改的代碼部分,但我還沒有進行更改。這可能需要一段時間,因爲代碼可能有多層,我可能需要在多個地方進行更改。
- 我爲我將要更改的功能尋找任何現有測試。如果我幸運的話,已經有很好的測試了!如果我沒有,我會編寫測試來幫助我確信我沒有破壞任何東西。我還通過首先測試代碼更好地理解了代碼。
- 現在,我準備好做出儘可能小的改變。不要讓拉取請求的範圍擴大。專注於你的任務和需要發生的事情。
- 當然,我也爲我的新代碼編寫測試。有時我使用 TDD。其他時候,我對何時以及編寫什麼測試更加寬鬆。
- 我在開發時經常運行單元測試。它們是我告訴自己過得如何的第一工具。好的編碼是反饋的問題。單元測試提供最緊密的反饋循環之一。
- 一旦單元測試通過,我就會將更改推送到 GitHub。我打開了一個拉取請求草案,這樣其他人就不會自動分配審查了。我讓我們的 GitHub 自動化負責運行完整的測試套件。
- 在完整套件運行的同時,我給自己進行了一次代碼審查。令人驚奇的是,當我在 GitHub 中審查自己的代碼作爲差異時,我看到了多少小錯誤或優化機會。在我請求審查之前,我希望我的代碼儘可能小和乾淨。
- 如果所有測試都通過,我會請求審查以從我的團隊那裏獲得反饋。
- 當我準備好部署時,我讓我們的 CI/CD 管道處理細節。但我立即對這些變化進行現場排查測試,因爲它正在通過環境。
常識
本操作手冊可能看起來像是常識。
當然你需要測試你的代碼!當然,您應該保持代碼更改乾淨且小!
不幸的是,常識並不那麼普遍。通過爲自己創建一個明確的運行手冊,我不會讓常識成爲偶然。
每次進行更改時,我都遵循相同的步驟。
每日清單
我每天早上都會爲軟件開發人員寫一些新東西。
如果你喜歡我的文章,點贊,關注,轉發!