持續整合軟體開發/敏捷的實際應用
< 持續整合軟體開發
最近，我一直在思考當使用問題跟蹤來處理從功能需求到文件到缺陷跟蹤的所有任務時，哪個票據狀態可能是合適的。這讓我開始思考程式碼同行評審的必要性以及這些評審可能有多麼乏味。事實證明，至少有一個 Trac 外掛包含用於程式碼註釋的鉤子，以便進行同行評審。但是，它似乎不包含任何形式的正式簽字功能。
我開始考慮，如果有一個用於同行評審的外掛（用於 Trac 或 Redmine 或其他工具）會很好。但是，明智地使用它，以使同行評審過程成為工作流程中不可或缺的一部分的方式定義我們的工作流程，我們可能能夠簡化流程。我們真的需要一個外掛，或者我們是否可以使用“正在評審”狀態來實現相同目的？我想這個問題的答案取決於你想要多嚴格。
以下是關於票據（或問題、任務、工作項，或者我們選擇如何稱呼它）歷史的思考。
- 新建
- 進行中
- 已解決（或者，如果我們確定某個票據不應該完成，我們有其他選擇，例如延期、拒絕、重複等）
- 正在評審
- 已關閉
使用這樣的設定，我們可以使用“已解決”狀態作為指示問題已完成，但尚未準備好關閉的指標。只有在採取了適當的同行評審行動後，票據才會被關閉。誰來決定這些行動是什麼？這由專案經理（或團隊負責人）決定，並透過票據的適當路由來實施。負責同行評審的個人被分配到票據。看到“正在評審”狀態後，這位同事會審查程式碼變更（觀察附加到票據的變更集）並提出評論（在票據說明中）。
我知道這聽起來有點工作量，但我看到了這種方法的一些主要好處。
- 跟蹤 - 我們現在擁有所有同行評審評論的審計日誌。透過將我們的票據系統與配置管理整合，票據、變更集和評審評論將連結在一起，不會丟失在某些電子郵件執行緒或文件中。
- 節省時間 - 任何曾經參與過同行評審的人（我猜大多數專案經理和開發人員都參與過）都知道它們可能非常耗時。因為似乎沒有人有時間，所以我們試圖透過進行大量程式碼評審來節省時間；我們等了很長時間，然後我們面臨著要進行大量程式碼的同行評審。這導致了下一個好處…
- 更好的評審重點 - 我不知道你怎麼樣，但我發現自己更擅長評審少量程式碼或單個功能區域，而不是嘗試一次性評審數千行程式碼。我們都很忙，這種情況不會改變。當你發現自己需要在週末進行同行評審，並且必須閱讀和標記 5 個類檔案時會發生什麼？你會把正在做的事情都放下去做嗎？你會嘗試，但時間很短，所以你匆匆忙忙。
- 溝通 - 當我花時間審查變更集時，這對團隊和進行審查的個人都有益。現在我對其他人正在做什麼、它在哪裡實現、它是如何實現的等等有了更多瞭解。我不必再去麻煩 Joe 開發人員，問他是否完成了這樣那樣的事情。我已經知道他完成了，因為我審查了他的程式碼。
所有這一切都假設我們的團隊在處理問題跟蹤和版本控制方面遵循良好的專案管理。這意味著我們必須擁有組織良好的票據，並且必須以某種有意義的方式提交變更集。這應該是顯而易見的。