最近仕事をしている中で意識していることをまとめてみました。
Overview
- 前提をすり合わせること
- 細かいところにこだわってみること
- 意図を説明すること
前提をすり合わせること
PullRequestに対してレビューしてもらう場合にdescriptionをちゃんと書くようにしたり、レビューを依頼するときに、「どこにどんな変更を加えたのか」をチャットでも一言添えるようにしています。
と言うのも、設計やレビューを依頼するときに、レビュアーにとって、コンテキストがわからない状態でレビューするのはとても負荷の高い作業になるので、極力みてもらう場合には前段のコンテキストや前提を伝えるようにしています。
同じ土俵に立ってはじめて、身のあるレビューをしてもらえるようになっているし、チームで仕事をする以上、相手のことも考えながら仕事した方が全体としては生産性はプラスに働くと考えています。
(本当はそう言う小さい気遣いを評価してもらえるようになるともっといいんだろうなと思っています)
いいfeedbackをもらうには、同じ土俵に立ってこそだと思いますし、同じ土俵にあげる努力を怠らないようにしていきたいと思います。
余談ですが、同じ土俵に上げることを 巻き込み力 とか言うのかな？とちょっと思い始めました。
細かいところにこだわってみること
今まで意識してこなかったところ、もしくは脳死的、簡単にスルーしてきたことにちょっとこだわってみています。
commitメッセージにこだわること
- commitメッセージの内容
- なぜ？とか書いたコードの意図をなるべくコミットメッセージに込めてみること
- PullRequest全体のcommitの構成
- わかりやすい粒度でコミットを分けること
- それに伴ってgitの知識をつけること
- squash & merge で大きなコミットをみやすくする
コミットメッセージって自分がわかればいいかなと思っていた派ではあるんですが、少しでも粒度や差分を一言で表すように意識してみると、コードを書く前にどう言う粒度にしようとかとか考えるようになってきました。
その結果コード書く前に、これから書くコードについてある程度見通しを立てることができるようになってきたと思います。
reviewdogに従ってみること
プロジェクトでコードレビューするときに reveiewdog を使っています。これがすごく良くて、Go Wayに則ってなかったり潜在的なバグが潜んでそうなところを指摘してくれるので、コードレビューの負荷がすごく減っていると思います。
一方でレビュイーからすると結構細かいところまで指摘されるので、直すのがめんどくさかったり後回しになってしまうPullRequestもしばしば見かけます。
PullRequestをどう運用していくのはレビュイーに任されていると考えているので、reviewdogで指摘されたコメントはすぐに対応するか後でまとめて対応するかに意見はあまりこだわりはないんですが、自分はおおよそのケースで指摘された次のコミットですぐに対応するようにしています。
結果、常にreviewdog意識しながらコード書くようになったためか、犬に吠えられない（望ましい）コードをかけるようになってきました。
意図を説明すること
最近
- 「なぜその設計にしたのか？」
- 「なぜそのコードを書いたのか？」
- 「なぜhogehoge??」
をちゃんと説明できるようにしています。
意図があるから、設計レビューやコードレビュー時にfeedbackをもらったときにその意図を説明しますし、議論が生まれますし、結果新しい観点をinputできるようになりつつあるので、前よりもずっと開発するのが楽しくなってきました。
意図をもつなんて仕事するときに当たり前のことかもしれませんがどうしても仕事をしていると、現状の実装に合わせたり、特に考えず脳死的に要件だけを満たそうとしたりするので、難しですがなるべく意図を持ったと言い切れるように、説明できること、と言うことを意識しています。
まとめ
これは普段業務で意識していることの一例に過ぎませんが、ただ仕様を満たすのでなく、自分が どう言う意図を持って、どうその仕様を満たすのかと言うプロセスを言語化できる ようになっているのが少しわかるようになってきました。
そして、少しですが 細かいところを意識すると開発が楽しくなる と言うことを実感しています。
神は細部に宿る と言いますが、こう言うところもこだわっていくと少しいいことあるのかなと思います。
