工作流程，编辑当前任务中没有的内容

通常，当我编程时，我要完成一个明确的任务，但是会发现我想继续进行的烦人的事情要清理。

在这里，我看到三个选项：

• 以后再做（可能会忘记/不得不花费时间添加票证）
• 现在就做，并将其与我当前的工作一起提交（不清楚）
• 现在执行并分别提交（必须找到它，可能会犯一个错误，无意中选择了选项2）

这可能是相当基本的，但是有什么方法可以使用svn / git / other来规避呢？

我个人认为这取决于:-)。

• 对于较小的修订，最好使用选项三（现在在单独的提交中），因为稍后进行此操作的开销不值得。在这种情况下，您只需创建一个单独的提交即可。如何做取决于您使用的VCS，这是一个单独的问题:-)。

• 如果是较大的修复程序，则创建工单。否则，您可能会不断地偏离您的主要任务（“哦，看，另一个重构的机会，哦，还有另一个，在那里，那里...”）。

考虑一下。当您“发现烦人的事情（...）进行清理”并做出执行决定时，您会将其他团队从优先讨论和决定中剔除。你让你的，因为你的代码特殊关系议程胜过其他人。我认为那不好。根据经验，这也会引起团队/股东的不满。

而是，为清理/重构创建一个问题/任务。尽管这是新鲜的想法，但请列出它重要的原因：增加稳定性，易于维护等方面的估计。可能会根据您的团队工作方式估算出工作量。然后在下一次任务选择/分配/优先级会议中，展示您的重构任务并将其与其他任务相对应。作为团队，决定何时完成。

请不要以为我是在告诉您以原则的名义抛弃理性。动动脑筋。如果您正在编辑的函数中存在某些丑陋之处，则这不是一项新的重构任务。对其进行修复并检入所有内容。如果将您正在使用的属性重命名为更合理的名称会影响几个额外的源文件，那么这不是一项新的重构任务。修复它并检查所有内容。另一方面，如果您不喜欢其他开发人员（Mitch，我讨厌那个家伙）在不编辑的函数中执行某些操作的方式，并且说该函数似乎工作正常，暂时不要管它。创建一个重构任务，并向团队介绍您的案例。

如果您的团队总是反对使用新功能来进行重构，请开始寻找其他工作。如果已经有工作，找工作就容易多了。