ワークフロー、現在のタスクにないものの編集
通常、プログラミングをするとき、私は自分の前に明確なタスクがありますが、続けて片付けたい迷惑なものを見つけます。
ここには3つのオプションがあります。
- 後で実行する（チケットの追加を忘れるか、時間をかける必要がある場合があります）
- 今それをして、私の現在の仕事と一緒にコミットします（不明確）
- 今すぐ実行して、個別にコミットします（それを見つける必要があり、間違えて、意図せずにオプション＃2に進む可能性があります）。
これはおそらくかなり基本的なことですが、svn/git/otherを使用してこれを回避する方法は何ですか？
個人的に、私はそれが依存すると思います:-)。
小さな修正の場合、オプション3（現時点では別のコミット）が最適です。後で実行するオーバーヘッドは価値がないためです。その場合は、別のコミットを作成するだけです。その方法は、使用するVCSによって異なり、別の質問です:-)。
大きな修正の場合、チケットを作成します。さもなければ、あなたは常にメインタスクから脱線する危険を冒します（「ああ、見て、リファクタリングのための別の機会、ああ、そこにあり、そこにあります...」）。
このことを考慮。 「クリーンアップするために迷惑なもの（...）を見つけて」、それを実行するという経営幹部の決定を下すとき、優先順位の議論と決定からチームの残りの部分をカットしています。 yourのアジェンダは、コードとの特権関係のため、他の誰よりも優先されます。それはいいことだとは思いません。経験から、それはまたチーム/株主の憤慨につながります。
代わりに、クリーンアップ/リファクタリングの課題/タスクを作成します。心の中で新鮮ですが、それが重要である理由を挙げてください。安定性の向上、保守の容易さなどの見積もりです。あなたのチームがどのように機能しているかに応じて、努力の見積もりを含めるかもしれません。次に、次のタスクの選択/割り当て/優先度の会議で、リファクタリングタスクを提示し、他のタスクに対して配置します。チームとして、いつ完了するかを決定します。
原則の名の下に良識を捨てるように言っているとは思わないでください。頭を使え。編集している関数に醜いものがある場合、それは新しいリファクタリングタスクではありません。修正してすべてをチェックインします。作業しているプロパティの名前をより適切な名前に変更すると、いくつかの追加のソースファイルに影響する場合、それは新しいリファクタリングタスクではありません。それを修正してすべてをチェックインします。一方、編集していない関数で別の開発者（ミッチ、その人は嫌いです）が何かをしたくない場合 and上記の関数は正常に動作しているようですそれをそのままにしますとりあえず。リファクタリングタスクを作成し、ケースをチームに提示します。
チームが常に新機能を支持してリファクタリングに反対票を投じている場合は、別の仕事を探し始めます。すでに仕事がある場合は、仕事を見つけるのが簡単です。