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