コードレビューをテーマにしたLT会に参加してきました。ラクス主催イベント コードレビューLT会 Vol.2
お久しぶりです。ジミーです。
今年最初の記事は、ラクス主催イベント コードレビューLT会 Vol.2の参加レポートです。
コードレビューLT会とは？
タイトルの通り、コードレビューをテーマにしたLT会です。
参加目的
自動テストスクリプトのレビューをした経験がありました。その時に、「こんなレビューで良いのだろうか」というモヤモヤがありました。
そのため、このイベントに参加し、他の方のレビュー方法を知ることで、何か活かすことはできないだろうかと思い、参加しました。
おことわり
今回のレポートは非公式なものであり、自分なりに整理したものです。
また所感の内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。
「こんなこと言っているんだな~」と思ってみていただければと思います。
各セッションの概要と所感
レビューガイドラインで技術力を見える化する
スライドは公開されています。
【主張】
コードレビューの観点をグループ化し、開発チームの特徴を可視化することで、効率よく改善が出来る
【概要】
コードレビューの観点をグループ化し、開発チームの特徴を可視化したお話。
レビュー指摘時のコメントを以下の重要度と観点でグルーピングを行った。
＜4つの重要度＞
MUST/SHOULD/IMO/NITS
＜7つの観点＞
Desgin/Functionality/Simplisity/Style/Naming/Tests/Document
これらをコードレビュー時にPrefix（重要度×観点）として使用し、Gitlabで集計を実施。
その結果、開発チームはテストコードの実装と設計力に課題があると判明（TestsとDesignのコメントが多いという結果から原因を調査）
その後、この課題解決に注力した施策を考えることができた。
【所感】
もう少しはやめに聞きたかったな～と思いました。
カイゼンの第一歩が見える化と言われているため、今回の事例はとても良い取り組みであり、集計を自動で行っている所も魅力的でした。
以前コードレビュー業務をしたときは、重要度にしか着目していなかったため、集計してもあまり活用できなかったです。
今後のコードレビューには、今回紹介された観点を参考にしていきたいと思います。
「レビュー指摘は財産」は確かにそうだなと思いました。
コードレビューする時に、実践している方法と意識していること
【主張】
確認する内容を段階的に分けることで、指摘もれを減らせることができる。
またレビュー時に感じた不明点はすべて解消し、第三者の視点で考える事が大事。
【概要】
登壇者自身がコードレビューしている時に実践していることと意識している方法を共有。
＜実践していること＞
指摘する箇所を3段階に分けた。
■ 第1段階（ざっくりとした全体像）
・規約違反/変数のスコープ/関係ない部分を変更していないか等
■ 第2段階（コードの内容が理解できるかどうか）
・コードだけで、処理を理解できるか/変数の名前は適切か等
■ 第3段階（ロジック面に着目）
・もっと良い処理方法/条件はないか
＜意識していること＞
3つ共有
・後から読む人がコードを理解できるか意識する
・レビュー時に違和感が少しでもあれば、すぐに伝える
・指摘の理由を伝える（なぜ、この処理では良くないのか）
【所感】
レビュー実施時にいきなりすべての観点で見るのではなく、段階的に確認することは自分も意識している事だったため、「やはりこれは大事なんだぁ~」と感じました。
また、意識していることの2つ目については、意外と「ま、いっか」になりがちだぁと思いました。やはりこういう違和感を感じたら、すぐに伝えることが大事なんだなと改めて感じました。
トランクベース開発と機能トグル
【主張】
トランクベース開発と機能トグルを用いると、コードレビューの効率性および品質を向上することが出来る
【概要】
コードレビューのありがちな問題の1つである「コードレビュー量」を、トランクベース開発と機能トグルを用いて解決したお話。
＜トランクベース開発＞
小規模なマージを頻繁に行う
＜機能トグル＞
有効/無効を切り替えることで、開発途中の機能をエンドユーザーに見えないようにするもの
これらを用いると小範囲での開発ができるため、コードレビュー量も減る
その結果コードレビュー時間が少なくなり、かつ集中的に行えるため、品質向上につながる
【所感】
このやり方は、手動テストする側にもやさしいものだと感じました。
こういうお話は以前WACATE2021冬のセッションで聞いたことがあり、懐かしいなと感じました。
ただ、このあたりの知識はまだ定着できていないのでこのあたりも理解できるようにしないといけないなと危機感を持ちました。
過去のコードレビュー時をふりかえってみた
【主張】
レビュー指摘の中には明文化されていないものがあり、人によって指摘のブレがある
【概要】
過去のコードレビューを受けた時をふりかえったお話。
指摘内容の中には、明文化されているものとそうでないものがあった。
明文化されていないものは、暗黙知になっている可能性があるため、明文化するべき。
【所感】
発表時間としては1～2分と非常に短かったですが、レビューにおける問題を定義しており、印象に残る発表でした。
確かに、人によってブレがあるな～と思うときはよくあり、人がやる作業だからしょうがないという気持ちで流していました。
ただ、今回の発表を聞いて、明文化できるところはどんどん明文化すべきだなと感じました。
あと、ふりかえりは大事だなぁと思います。
ちょうどふりかえりカンファレンスありますね。（笑）
プルリクへのセルフコメントという小技
スライドが公開されています。
【主張】
違う視点に立てるような仕組みを設けることで、個人コードレビューの指摘抜け漏れの防止だけでなく、第三者のレビュー容易性の向上につなげることが出来る。
【概要】
個人のレビュー時に、githubのプルリクを用いてレビューアになりきったお話。
レビューアになりきり、1行ずつ丁寧にコメントを付けていくことで、いままで見落としていた指摘を見つけることができる。
またコメントを残しておくことで、以下のメリットもある。
・作成の意図が伝わりやすくなる
・ドキュメント代わりになる
・コメント部分周りを注意深くレビューしてもらえる
【所感】
この発表で他の参加者がつぶやいていた例えがしっくりきました。
"スポーツで自撮りした自分のプレーをみてつぶやくのと同じかな"
確かに、自分の感覚と実際の出来は異なることも多いなと思います。
私もよく業務で指摘をもらうので、プルリク以外で出来ないか検討しようと思います。
コードレビューしたら苦しかったお話
このお話はイベントの発表限りとのことでしたので、今回は記載しないですが、結構共感できるものが多かったです。
今後も「この場限り」の発表もあると思うので、実際に参加することをお勧めします。
ちなみにこの発表資料は5分でつくったとのこと（私には考えられない。。）
全体の感想
コードレビューという結構狭い分野だと思っていましたが、発表内容はかぶることなく、バランスよく聞けたので良かったと思います。
今回、拝聴したものはコードレビュー以外にも活かせるものが多いと思ったため、自分の職場でも試していきたいと思います。
自分も自動テストスクリプトのレビューをやったので、いつか発表とか出来たらいいなーと思います。
このLTイベントはさまざまなテーマで開催されているので、興味があれば聞いてみてください。
この記事が気に入ったらサポートをしてみませんか？