ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

ルール19作り直しは並列で行うこと

　ほとんどの時間帯では、プログラマーがやる仕事の大半について、主要なコードベースから離れるのはごく短時間にすぎない。問題を調査し、その問題の解決に必要なファイルをチェックアウトし、変更のテストとレビューを行ってから、変更したファイルを元の基幹（main）ブランチにコミットすることになる。このサイクル全体を1日で完了させることもできるが、テストをやらなきゃいけない状況だと1日はかなり早い方だ。それよりは、ファイルがチェックアウトされた状態で何日かかけて完了させる方が普通だろう。

　でもやがては、こういう単純なモデルが破綻するような仕事に出くわす。例えば、他のプログラマーとチームを組んで何かやるとする。単独で作業してると、進行中の作業内容は自分のマシン上にしか存在しないが、誰かと組んで作業するとそうはいかない。進行中の作業内容の共有バージョンを、2人で維持しなきゃいけない。

　そういう場合の標準的な答えは、2人が計画した作業用に、ソースコードコントロールシステムで新しいブランチを作成することだ。このブランチは、最初は基幹ブランチのコピーとして作成されるが、作業が進捗するにつれて基幹ブランチの内容からすぐに離れていく。基幹ブランチの変更を自分のブランチに統合し、チームの他のメンバーが行っている作業に追いつき、基幹ブランチでの変更のせいで生じた競合を解決するという、時々訪れる機会をおそらく探ることになる。やがて作業が完了するので、最後にもう一度基幹ブランチと統合し、最終テストを行い、自分の作業分をレビューにかけ、チェックインする。

道の途上で起こる小さな問題

　以上のようなアプローチは機能する。標準的な答えになってるのは、それなりに機能するからだ。でも問題がないわけじゃない。 ...