レビュアーとして 成長するには

エンジニアのためのスキルアップ勉強会#1「妥協しないコードレビュー」
上記イベントでの発表資料です

Transcript

1. レビュアーとして 成長するには エンジニアのためのスキルアップ勉強会#1 「妥協しないコードレビュー」 橋本遼太(hassy)
2. 今回話すこと レビュアーとして、早く成長する方法 新人プログラマは自分の成長方法の一例として ベテランの方は若手の育て方の一例として 参考にしてもらえればと思います
3. 橋本遼太( はっしー)/hassy X(Twitter): @samayou12 1996/12/21 生まれ(26 歳) 出身地 名古屋生まれ→ 川崎育ち→ 岡山市(2022/10~) 趣味 サウナ、読書、音楽、ゲーム、外で飲む事、競馬、 服、サイクリング 前職 Youtube 広告ディレクター → 個人営業
4. 自分のスタート地点 2022 年4 月にソニックガーデン入社 情報系の学校を出たわけでもなく、未経験でプログラマになった 文系学部出身（一般教養でruby, python, LISP, MATLAB をやった程度） 情報系のバックグラウンドがなく、そもそも何が良いコードかわからない！
5. もくじ なぜレビュアーとして成長するべきか 1. レビュアーとして、どう成長するか 2. コードレビューをしよう 3.
6. なぜレビュアーとして成長するべきか 1.
7. 二つの理由 チームに貢献できる プログラマとしての力が伸びる
8. チームに貢献できる
9. チームに貢献できる 新人のうちはどうしても頼ることが多い でも「頼られてこそ頼れるし、頼ってこそ頼られる」 give されたなら、give を返そう 新人にとってもコードレビューはgive する手段の一つになる →give できていれば、頼る時も申し訳なさが減る
10. チームに貢献できる（自分のためにも） 自分の場合 自分が貢献できていない時に頼るのって申し訳ない でも、早く聞けば一発で終わることも多い 自分に貢献意識があれば遠慮なくさっさと聞けた チーム貢献が自分のためになった
11. プログラマとしての力が伸びる
12. プログラマとしての力が伸びる 悪いコードの例 DRY なプログラムでなく、プロジェクト内に同じコードが何ヶ所もある hiduke = 12 のような、わけのわからない変数がある 世の中にはいいコードと悪いコードがある
13. プログラマとしての力が伸びる 「機能を実装する」「メンテナンスしやすく機能を実装する」 この二つの間には大きな隔たりがある 世の中にはいいコードと悪いコードがある
14. プログラマとしての力が伸びる レビュアーとして成長する ⇩ 「良いコード/ 悪いコード」が分かるようになっていく ⇩ ひいては良いコードが書けるようになっていく
15. レビュアーとして 成長しよう！！！
16. 2. レビュアーとして、どう成長するか
17. Q. どうすればレビュアーとして成長できるの？
18. A. 技術書とレビュー
19. レビューの大前提 自分の持っている引き出しでしか指摘ができない。 ⇩ 引き出しをいかに多く、すぐに取り出せるようにするかが大事
20. 技術書を読む
21. 方法１: 技術書を読む 技術書は引き出しを増やす効果が高い
22. 方法１: 技術書を読む 技術書は筆者がある分野について、情報を体系的にまとめた物 ⇩ その分野についての引き出しを、広く体系的に習得できる
23. 方法１: 技術書を読む( 注意点) 本には読むための要求ステータスがある。 ⇩ いかに名著であっても、いきなり理解できるかは別 背伸びしすぎると効率が悪い ※ 一年後に読み返して、内容が腑に落ちたということが普通にある
24. 技術書を読む( 実例)
25. 方法１: 技術書を読む( 実例) ネットで「エンジニアは読むべき」 と書かれていたので買った ⇩ 入社直後の自分では読めなかった ⇩ 一年後読み直してみたら、 読めるし面白く感じた
26. 方法１: 技術書を読む( 実例) 一方で、レビュー指摘されたことが あることも多く書かれていた ⇩ 本を読んでいれば早く気がつけたことも多かったはず ⇩ 最適な読むタイミングがあるはず
27. 技術書を読む、最適なタイミング 本を理解できない まだ読むべきではない 本を楽しく読める すでに知っていることが多いから「楽しい」 ⇩ 自分の場合は、「理解できるが、読むのが少し苦しい」 くらいの頃に読むのが一番良さそう
28. レビューを受ける/ 読む
29. 方法２: レビューを受ける 題材が自分のコード ⇩ 自分が“ 今” 必要な引き出しを増やしてくれる 自分のコードの悪い点を改善できる
30. 方法３: レビューを読む 題材がチーム、会社のコード ⇩ チームのコードの価値観がわかる 量が多いので、多くインプットできる 同じ間違いを事前に防げる
31. レビューを受ける( 実践編)
32. レビューを受けるだけの時から、 レビュアーとしての成長は始まっている
33. レビューを受ける( 実践) レビューをもらったら、まず意味を理解しよう
34. 「修正します」だけではダメ レビューを受けて初めの頃は、修正して終わりにしてしまうことがある ⇩ なぜそうなのか？を理解したり議論することが大事
35. 「修正します」だけではダメ Q. 内容を理解しろってことでしょ？
36. 「修正します」だけではダメ A. そうだけど、それが新人には難しい......
37. 「修正します」だけではダメ レビュアーにとっては当たり前過ぎて、伝える必要がな いと思っている情報がある（可能性がある） そもそも、何がわからないのか伝えないとレビュアーは 何を教えるべきかわからない なぜ難しいのか
38. 「修正します」だけではダメ つまり、レビューのコメントはいつも完全な物ではなく、 時には自分で情報を取りに行く必要がある ⇩ 分からなかったら、コミュニケーションをとろう。 わかった気になって終わるのは止めよう
39. 「修正します」だけではダメ そして、「なぜ？」まで理解して落とし込めれば応用が効く ⇩ 逆に言えば、「なぜ？」まで落とし込めないと、 単なる一対一対応の間違い探しから抜け出せない
40. 「修正します」だけではダメ もし可能であれば最初の頃は 対面、zoom などリアルタイムでレビューを受けると良い ⇩ テキストで質問するより、時間がかからない エディタの使い方や、ショートカットなどプログラムだけで はわからない改善点を教えてもらえる
41. 3. コードレビューをしよう
42. 小さく始めよう いきなり全部やろうとするとパンクする、かも知れない
43. 小さく始めよう 例えば、自転車の練習をするときどうしたか？ ⇩ まずは補助輪使ったり、足をつけて地面を蹴るところから始めるはず
44. 小さく始めよう（失敗例）
45. 小さく始めよう（失敗例） 新人僕「とりあえずコードを読んで気がついたことを指摘しよう！」 ⇩ 全部読もうとするが、少しづつ集中力が落ちる ⇩ 最終的にはコードが目を滑っていく......
46. 小さく始めよう（失敗例） 15 分後
47. 小さく始めよう（失敗例） こうならないためには？
48. まず、1 行でわかる事から始める '( シングルクォート) 、 "( ダブルクォート) を使い分けているか ファイルの最終行は改行で終わっているか puts やconsole.log のようなデバッグ用コードが残っていないか Article.writers.each のような時にorder をつけて順番を担保でき ているか こういう点は、その1 行のみで独立しているので、単なる間違い探しとして発見できる
49. 引き出しからすぐ取り出せるように 何度も指摘していると、コードレビュー時に自然と気がつくように ⇩ オートモードになるので、他の部分に意識が割ける ⇩ 引き出しの量だけでなく、スピードも上がっていく
50. 1 行から複数行へ 1 行でわかることを意識することに慣れる ⇩ 自然と複数行のコードもレビューできるようになっているはず
51. 設計、メンテナンス性はどうなる 本で読んで知識を入れるのも良い ⇩ でも結局、DRY にしておくことの良さとか、 読みにくいコードのクソさを実感しないと必要だと思えない ※ 多くの人間は、必要だと思うまで本当の意味で認識できない
52. 設計、メンテナンス性はどうなる 自分でアプリを１から作ってメンテナンスをする ⇩ クソコード/ クソ設計に困ってキレるので、 次回から気をつけるようになる
53. わからないなりに、貢献する方法
54. 「ここがわかりにくい」 良いコードとは理解しやすいコード ⇩ 新人でも理解できるコードであれば、理解しやすいコード ⇩ 「ここがわかりにくい」というコメントも役にたつ
55. 終わりに
56. 終わりに 結局、「本読んでコード書いてレビューもらってレビューして」 これをやった分だけ伸びていく 今日の話はその効率を上げるための話にすぎない
57. 終わりに ただ、間違いないのはプログラマという職業は プログラミングという面では、努力が成果に結びつきやすい だから成長している実感が持てて楽しい 逆に言うと、成長している実感があれば楽しめると言うこと
58. 終わりに 今日の話が、皆さんが停滞を打ち破り、楽しく成長するための ひとかけらのヒントになれば嬉しく思います