大きいプルリクはつらい
チームで開発をする場合、 GitHub 等のサービスを利用してコードを管理することが多いと思います。 既存のコードを変更する際は、GitHub であればプルリクを出して、他の開発者にレビューをしてもらい OK が出ればマージするといったフローが生じます。 レビューにより、複数の視点からコードが吟味され、一人では気づかなかった点に気づくことができます。
つまり、この「他の開発者にレビューをもらい OK が出れば」 を経ることで、コードの品質が悪くなることを防ぎやすくなります。 さらに、レビューを受ける側の成長にもつながります。
そのため、開発においてレビューはとても大事な存在です。
レビューは大変
レビューには時間がかかるし、見落としもしてはいけないので集中力も必要になり、大変と思う方が多いと思います。
小さいプルリクであればまだ良いのですが、大きいプルリクの場合は、変更点が複雑になり全体を把握しづらくなりますし、集中力が持たずにつらくなってしまいます。
そのため、レビューする側の負担が大きくならないようにする工夫が必要です。
小さいプルリクを出す
工夫としては、変更点が小さくなるように気をつけてプルリクを出すことが効果的かと思います。
そのようにプルリクを出すことで、何を変更したかを把握しやすくなりますし、一回のレビューにかかる時間が短くなり負担を抑えることができます。
気をつけることの例としては、以下が挙げられます。
- ついでの変更をしない。
- 大きくなりそうな場合は、開発まとめブランチを用意する。
- レビューにより修正点が多くなる場合は、再度適した粒度でプルリクを出しなおす。
偉そうに述べましたが、自分もできていなかったので自分への戒めとして書きました。