在功能分支中工作時,我發現應該重構的代碼與該分支無關,除了它與我正在使用的文件相同。如何解決功能分支中的切向重構代碼
我應該創建一個新的用戶故事嗎?
另外你如何寫一個重構代碼的用戶故事?
在小修復的情況下,是否有理由創建PBI和分支來修復?
嘗試和尋找最接近的相關用戶故事並在任務中實施一項任務難道不好嗎?
在功能分支中工作時,我發現應該重構的代碼與該分支無關,除了它與我正在使用的文件相同。如何解決功能分支中的切向重構代碼
我應該創建一個新的用戶故事嗎?
另外你如何寫一個重構代碼的用戶故事?
在小修復的情況下,是否有理由創建PBI和分支來修復?
嘗試和尋找最接近的相關用戶故事並在任務中實施一項任務難道不好嗎?
答案取決於球隊如何使用用戶故事和任務,以及他們的重構方法。
關聯的工作項目,以提交
如果他們有,迫使你的提交工作項關聯任意的政策,那麼你要麼需要重寫政策或相關聯。通常這種關聯對於某種發佈報告是必需的,以便可以看到發佈中的所有更改。 也許團隊正在使用關聯來跟蹤任務的時間?如果是這樣,請創建一個任務以將提交關聯到。
因此,答案取決於團隊如何使用關聯。 過去,我使用用戶故事「改進組件X」將重構關聯到。這個用戶故事仍然是一個追蹤改進的地方。 我的一般建議是避免不必要的努力(例如,在任務沒有實際使用時創建任務)並儘可能做到最簡單的事情。你想盡可能簡單地進行重構。
分支
是否重構需要進入主線在不同的時間比功能?如果是這樣,你需要一個單獨的分支。 如果重構可以與特徵同時進入,請保持簡單並重構特徵分支中的內容。我至少會使用一個單獨的提交重構。
嘿亞當,將你將你的答案複製到http://softwareengineering.stackexchange.com/questions/342503/how-to-address-tangential-refactorable-code-in-a-feature-branch 軟件工程SE對這個問題有更好的結果。 我欣賞你的KISS-esque解決方案,它是一個目前代表性的視圖。 –
已經發布了答案 - 謝謝 –
交叉貼:http://softwareengineering.stackexchange.com/questions/342503/how-to-address-tangential-refactorable-code-in-a-feature-branch –
@DanCornilescu感謝丹 –