「きれいなRailsのコード」と少し離れたトピックですが…。
僕はコミットメッセージをなるべく詳しく書くのは開発を円滑に進めるために有用なお作法だと思っています。が、現場を見るとコミットメッセージとして意味をなさない
のようなものでコミットしてしまう人がそれなりにいるようです。また、コミットの粒度もまちまちで、コミットメッセージと関係ない修正が入り込んでいることも度々目にします。
おそらくこのようなコミットをつくる人たちはコミットメッセージを普段見ないので、コミットをきれいにつくるメリットを感じていないのではないかと想像しています。そんな人たちにコミットを丁寧に書いてもらう効果的な方法はなにかないでしょうか。
「いいね!」 2
けっこうコストかかる対応ですが、自分がやってるのは以下のような感じです。(チーム開発している前提で書いています)
- ①丁寧なコミットメッセージを書くメリットを感じていない
- ②適切なコミット粒度のメリットを感じていない
- 適切な粒度じゃないと丁寧なコミットメッセージも書きづらいので、この理解も重要
- ③コミットの修正の仕方を知らない(gitに詳しくない)
という要素があると思っています
①②に関しては、
ブログとかの資料などで説明も当然必要ではありますが、
「コミットメッセージを普段見ない」という要素が同じく大きいと思っています。つまり「レビュアーの経験がすくない」とイコールかと思っています
なので、
- ペアレビューをする
- どういう観点・流れでレビューしてるか、ペアプロと同様にペアでレビューすることで伝達する
- 本人が昔書いたPRがあれば、それが1番効果的。自分が書いたコードでも忘れるので。
- 他のメンバーのPRのコードレビューをしてもらう
- 必要に応じて、approveはしなくても、LGTMコメントなりをつけてもらう
- 他人のコードを読んで理解するのはムズいので、コミットメッセージやコミットの粒度の適切が重要であることを体感してもらう
- 他の人のコミットを見る機会が増えることで、コミットメッセージの付け方や粒度の参考にしてもらう
- PRのレビュー依頼を投げる前に、自身で見直す(セルフレビューをしてもらう)
- 取り組みとして効果的かはわからないのですが、自身が作ったのを見直すのベテランになっても重要でお作法としても大事なのでやってもらっています
という取り組みで、他人のコミットを見る機会を増やす以外ないんじゃないかなぁと思っています。
メリットを感じてもらう説明として、「調査がしやすいか(履歴をおいやすいか)」「revertがしやすいか」で話することありますが、運用経験とかがないとあまりピンとこない話かとは思うので、うまく伝わっているかは悩ましいなと思っています…
③に関しては、
コミットの修正の仕方は、実際やろうと思ったらいろんなやり方でできちゃうので(使うgitクライアントにもよりますし)、調べにくいんじゃないかなぁと想像しています。
使うツールによりますが、 rebase -i
add -p
あたり相当の操作を覚えてもらう必要があるはずなので、ツールによってはできないし、素のgitコマンドでここにたどり着くのもちょっと難しいですし。
なので、とりあえず1つやり方をお伝えするのが手っ取り早そうだと思っています。
画面共有しながらペアプロで伝えちゃっています。