開發實務

根據完成的定義工作

每個團隊對「完成」的含義有不同的定義,但有一個定義並確保故事在被接受之前符合定義的標準非常重要。

團隊通常會指定的某些條件包括:

  • 已審核格式的代碼
  • 添加了注釋/Javadoc
  • 滿足要求的測試覆蓋級別
  • 通過單位和整合測試
  • 在QA環境中驗證
  • 已實作本地化

如果沒有定義明確的DoD,很容易在這樣一種情況下結束:許多事情都做到了一半,但什麼也沒有真正完成。

定義並遵守編碼和格式慣例

縮排層級和空白字元之類的內容似乎並不重要,但適當格式化的程式碼有助於提高可讀性和可維護性。 應以團隊身份討論並同意各項公約,然後在規則中加以遵循。

針對高測試覆蓋

隨著專案實作的規模增加,測試所需的時間也會增加。 如果測試覆蓋率不高,測試團隊將無法擴展,開發人員最終將陷入錯誤之中。

開發人員應該練習TDD,在生產代碼滿足其要求之前編寫失敗的單元測試。 QA應建立一組自動的接受測試,以確保系統從高層級正常運作。

有自訂架構可供使用,例如Jackalope和Prosper,讓對JCR API的嘲弄更簡單,以確保開發人員在編寫單元測試時能有效率。

保持演示就緒

系統應可在每次迭代結束時向企業演示。 將系統保持在可演示的狀態,團隊將始終處於可生產就緒的迭代過程中,並且技術負債可保持在可維護的級別。

實作持續整合環境並加以使用

實施連續整合環境可讓您輕鬆、重複地執行單元測試和整合測試。 它還將部署與開發團隊脫鈎,使團隊的其他部分更高效,並使部署更穩定、更可預測。

通過保持建置時間低來快速保持開發週期

如果單元測試需要很長的時間才能執行,開發人員將避免執行,而且會失去其價值。 如果建立和部署程式碼需要很長時間,人們的執行頻率就會降低。 將縮短構建時間作為優先事項,可確保我們投入測試覆蓋和CI基礎架構的時間將繼續使團隊更高效。

微調聲納和其他靜態代碼分析工具,並對其報告採取行動

程式碼分析工具可能很有價值,但唯有在其報表導致開發團隊採取動作時,才能如此。 若不微調這些工具所提供的分析,它們產生的建議將不相關,而會失去其價值。

遵循男孩Scout規則

男孩Scout有一個規則:「留下比你找到的好。」 只要開發團隊的所有成員都遵守這項規則,在遇到麻煩時收拾東西,程式碼就會不斷改進。

避免實作YAGNI功能

YAGNI(或You't Not Need It)功能是當我們預期未來需要某些東西時(即使我們現在不需要它)實施的。 理想情況下,我們應該實施當今最簡單的工作,並使用連續重構來確保系統的體系結構隨著時間的需求而不斷演化。 這可讓我們專注於重要事項,並防止程式碼膨脹和功能蠕變。

本頁內容