コードの作者がいるうちに聞こう
>100 Views
June 03, 24
スライド概要
Mobile Application Programmer
関連スライド
各ページのテキスト
コードの作者がいるうちに聞こう KAWASHIMA Yoshiyuki YUMEMI.grow プルリクエストとコードレビューで開発を加速させるLT会 2024.6.3
伝えたいこと • コードの作者がいなくなっても永く保守するためのコードレビュー • コードレビューを最優先にするのは永く保守する上で最小のコスト
情報源 Googleのソフトウェアエンジニアリング 持続可能なプログラミングを支える技術、文 化、プロセス 2021年11月発行 https://www.oreilly.co.jp/books/9784873119656/
情報源 Googleのソフトウェアエンジニアリングから学ぶコードレビュー https://zenn.dev/yumemi_inc/articles/google-code-review
前提 コードレビューは 11年くらい前から GitHub 上で OSS PR で チーム開発のプロセスとして導入したのは 6年くらい前から それまでは一人開発が主流 3年くらい前からチーム開発でのコードレビュープロセスに加えて、採 用や育成のコードレビューも
コードの作者がいなくなる？
離任
引き継ぎ 最初からいない…
どういう意図でそのコードが書かれたのか誰もわ からない
影響範囲がわからないのでそのままにしておこう
影響範囲を調査してコードを理解して修正するとな るとちょっとの修正のはずが、多くの時間を要する
PR を作成して1週間後にレビュー
コードを書いた本人でも思い出す のに時間がかかる
コードの作者がPRを作成した今聞 いてしまうのが一番コストが小さい
コードの作者が今目の前にいてコード について聞けるのはとても貴重な時間
どうやってレビューする
Googleのソフトウェアエンジニアリングから影響を 受けた言葉の紹介
情報源 Googleのソフトウェアエンジニアリング https://www.oreilly.co.jp/books/9784873119656/ 第9章コードレビューからここで紹介するのはご く一部なので気になった人はぜひ書籍を手に 取ってみてください
通常はコードレビューが、作者以外の者が コード変更を検証する初めての機会である Googleのソフトウェアエンジニアリング 9章コードレビュー p.204
こうした観点によってレビュワーには、最も優 れたエンジニアですらできないことができる ようになる Googleのソフトウェアエンジニアリング 9章コードレビュー p.204
それは、コード作者の観点から生じるバイアス に影響されないフィードバックを提供すること だ Googleのソフトウェアエンジニアリング 9章コードレビュー p.204
コードレビューは、ある変更がより広い対象に とって理解可能かどうか試す最初の試練であ ることが多い Googleのソフトウェアエンジニアリング 9章コードレビュー p.204
コードは書かれるより読まれる回数が多くなる ため、この観点は生死を分けるほどに重要であ り、理解と意味の把握が決定的に重要である Googleのソフトウェアエンジニアリング 9章コードレビュー p.204
コードレビューは、コードの正しさについての万能の解決 策でも唯一のチェック方法でもなく、ソフトウェアをめ ぐるそのような問題に対抗する多層防御の一要素である Googleのソフトウェアエンジニアリング 9章コードレビュー p.203
結果として、コードレビューが成果を上げ るためには「完璧」である必要はない Googleのソフトウェアエンジニアリング 9章コードレビュー p.203
実は意外なことに、コードの正しさのチェックは、コー ドレビューのプロセスからGoolgeが得る恩恵の首位では ない Googleのソフトウェアエンジニアリング 9章コードレビュー p.203
時間が経ちコードベース自体がスケールした場 合もコードの変更が理解可能で意味を成すと 保証することの方が、意義が大きい Googleのソフトウェアエンジニアリング 9章コードレビュー p.203-204
具体的にどうすれば？
質問する
特に新しくチームに参画したメンバーはバイ アスがないのでコードレビューの効果が高い
そのアプローチが間違っていると決めてかかる 前に、何故そのようなアプローチが採られた かについて質問した方がよい Googleのソフトウェアエンジニアリング 9章コードレビュー p.209
どう質問する
コードの作者がいなくなっても自 分が保守できるか
今いるメンバー（自分を含めて） いなくなっても保守できるか
そうはいっても指摘が多くなる
前提として、Googleにはリーダ ビリティレビューがある
読みやすさのための徹底した新人 研修のイメージ
情報源 Googleのソフトウェアエンジニアリング https://www.oreilly.co.jp/books/9784873119656/ リーダビリティについては第3章知識共有で詳し く書かれています
私たちはGoogleではない
ペアプログラミング
ガイドライン作成
まとめ コードの作者はいなくなります 物理的にも時間的にも コードを作成した直後にしかそのコードの作者はいません そのコードを永く保守していくためには、その作者がいるうちにどう いう意図でその変更をしたのか確認して理解しておくことが大事 わかりにくいコードであれば、修正やコメント、ドキュメントなどの 加筆をお願いする
まとめ 理解と意味の把握が重要である 正しさについて「完璧」であることを求めない 動いているからOKよりは意味がわかったからOKとする 指摘よりも質問を心がける 指摘が増えてしまうのは、チームの状態の凹凸を示している ペアプログラミングやガイドラインを作成して知識の共有を行う