創建劇本以開始新的編碼任務

您在平臺競標中中標了,或者,您已收到客戶的要求。

你做的第一件事是什麼?

有一本劇本很有價值。每次開始研究代碼中的新更改時都要遵循的過程。

它使您的工作更可預測、更完整和更正確。你會成爲更好的開發者。

需要發生什麼

讓我們以平臺中標中的項目爲例。這是最簡單的。

需要發生什麼?

  • 編寫實現該功能的代碼
  • 爲該功能代碼編寫測試
  • 確保所有測試通過
  • 打開拉取請求
  • (通常)通過代碼審查
  • 通過 UI 測試和 QA
  • 成功部署到所有環境

好多啊!這不僅僅是“編寫代碼”的步驟。

您的操作手冊

每個人對如何構建劇本的偏好都會略有不同。但重要的是你有一個。

所有這些步驟都不會像預期的那樣落到實處!他們採取計劃和經驗來執行。

這是我開始一項新任務時所做的。也許它會對你有所幫助。

  1. 我開始一個新的 git 分支。這通常是我的第一步。
  2. 我找到了需要更改的代碼部分,但我還沒有進行更改。這可能需要一段時間,因爲代碼可能有多層,我可能需要在多個地方進行更改。
  3. 我爲我將要更改的功能尋找任何現有測試。如果我幸運的話,已經有很好的測試了!如果我沒有,我會編寫測試來幫助我確信我沒有破壞任何東西。我還通過首先測試代碼更好地理解了代碼。
  4. 現在,我準備好做出儘可能小的改變。不要讓拉取請求的範圍擴大。專注於你的任務和需要發生的事情。
  5. 當然,我也爲我的新代碼編寫測試。有時我使用 TDD。其他時候,我對何時以及編寫什麼測試更加寬鬆。
  6. 我在開發時經常運行單元測試。它們是我告訴自己過得如何的第一工具。好的編碼是反饋的問題。單元測試提供最緊密的反饋循環之一。
  7. 一旦單元測試通過,我就會將更改推送到 GitHub。我打開了一個拉取請求草案,這樣其他人就不會自動分配審查了。我讓我們的 GitHub 自動化負責運行完整的測試套件。
  8. 在完整套件運行的同時,我給自己進行了一次代碼審查。令人驚奇的是,當我在 GitHub 中審查自己的代碼作爲差異時,我看到了多少小錯誤或優化機會。在我請求審查之前,我希望我的代碼儘可能小和乾淨。
  9. 如果所有測試都通過,我會請求審查以從我的團隊那裏獲得反饋。
  10. 當我準備好部署時,我讓我們的 CI/CD 管道處理細節。但我立即對這些變化進行現場排查測試,因爲它正在通過環境。

常識

本操作手冊可能看起來像是常識。

當然你需要測試你的代碼!當然,您應該保持代碼更改乾淨且小!

不幸的是,常識並不那麼普遍。通過爲自己創建一個明確的運行手冊,我不會讓常識成爲偶然。

每次進行更改時,我都遵循相同的步驟。

每日清單

我每天早上都會爲軟件開發人員寫一些新東西。

如果你喜歡我的文章,點贊,關注,轉發!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章