「別でやります」を絶対にやる

「考えたことを何らかの形でOutputしておかないと、いざという時に出てこない！」シリーズです。

プルリク

プルリクエストの大きさは小さい方が良いと思っている。

まずレビューがしやすい。レビューがしやすいというのは、レビュアーがコード自体や変更の目的を理解しやすいということでもある。結果としてバグの発見や、わかりにくいコードの指摘につながる。

「設計の考え直し」のような大きな手戻りが発生しにくいというメリットもある。初期段階で誰か（レビュアー）の目が入るからである。これはそもそも実装前に話しておくべきことではあるが、「これの実装方針は明確だろう」と思って着手したものが意外とそうではない、ということはよくある。

小さい規模のプルリクエストを積み重ねることで、着実に前に進める。

「別でやります」

プルリクエストを小さく保つには、1つのプルリクエストに複数の変更点を混ぜない、という点も意識する必要がある。せめてコミットが分かれていれば良いが、あまりに大きな変更が2つ、3つと入っているとレビューしにくい。

実際に実装をしている最中に、本筋の修正ではないがリファクタリングしたい部分を見つけた、ということはよくある。そのときに大体「別でやろう」と思う。別で、というのはプルリクエストを分けよう、ということだ。

また、レビューでそのような指摘を受けることもある。もしくは、これでも良いと思うがもっと良い変更方法があるんではないかといったIMOなコメントをもらう場合だ。

※IMO: In my opinion. 自分ならこう書くけどどうだろうか？という緩やかな提案。

このような時に「別で対応します」としてこのプルリクエストをマージすることもあると思う。（どこまでをこのプルリクエストで対応して、どこからを別にするかは人それぞれだと思うし、絶対同じプルリクがいいという方もいる。私の経験ではよくあることなので、それをベースに話をさせてもらいたい。）

絶対にやる

こういうちょっとしたことをやれるかどうかもとても大事なことだと思っている。私はボーイスカウトルールが大好きだ。

「来た時よりも美しく」というボーイスカウトのルールになぞらえて、たとえ自分が書いたコードでなくても実装する際に気づいた点を改善しよう、という考えだ。大きなリファクタリングをしなくてもよくて、変数名の変更やコメントの追加など小さなことで良い。それが積み重なれば大きな改善となる。

そしてこれも信頼貯金の一つかなと思っている。たとえなんらかの事情で実装が出来なくなったとしても、タスクとしてあげるだけでも良い。それくらいしていくことで改善の文化もできていくのではと思う。