開發實務

根據Done的定義工作

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

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

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

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

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

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

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

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

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

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

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

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

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