デキるプログラマだけが知っているコードレビュー7つの秘訣

SonicGarden Study 11 #sg_study

いつまでクソコードを書き続けるの？

デキるプログラマだけが知っているコードレビュー7つの秘訣ソニックガーデン西見公宏

1


西見公宏 Nishimi Masahiro

2

自己紹介


西見公宏 Masahiro Nishimi @mah_lab 昭和58年生まれ東京育ち 2児（双子）の父親です

3

今日お話する内容

1. クソコードとは何か？ 2. 優れたプログラマとは何か？ 3. コードレビューが改善の近道 4. コードレビュー7つの秘訣

SonicGarden Study 11 #sg_study 4


1. クソコードとは何か？

5


「クソコード」とは・・・

6


「クソコード」とは・・・

読む人を怒りの渦に叩きこむコードである

7

つまり

•  「クソコード」とは読んだ人の怒りを体現した言葉である。


クソコード3つの特徴 1. 読めないコード

–  変数名が暗号／制御フローが無駄に複雑／メソッド名と処理の内容が合ってない etc...

2. 要領の悪いコード –  言語レベルで用意されている機能を素直に使わない（例：Go

を使っているのにゴルーチンを使わない） etc...

3. 意図がわからないコード –  フレームワークのレールに従っていない etc...


クソコードかどうかは読まれるまで分からない •  シュレディンガーの猫 •  読んだ人の当事者感によって度合いが変わる（例：「え、このコード、俺がメンテするの！？」）

•  自分で読んでダメだと思うなら、最初から直して・・・。



2. 優れたプログラマとは何か？

11

優れたプログラマ3つの特徴 1. 「読めないコード」を書かない。 –  読みやすいコードを書く。 2. 「要領の悪いコード」を書かない。 –  言語の特性を活かした要領の良いコードを書く。 3. 「意図のわからないコード」を書かない。 –  設計の意図が明確である。


優れたプログラマを見極める簡単な試験書いたコードの1行1行に対して、以下の項目を質問する。

l どういう処理なのか？ l どういう意図で書いたのか？



3. コードレビューが改善の近道

14

まずは読まれなければはじまらない


読む人に怒りをもたらすのがクソコード

ならば

読む人がいなくてははじまらない

誰に読まれるのがベストか？


優れたプログラマ

何故優れたプログラマが読むべきなのか？


•  単純に同じレベルのプログラマが指摘しても、指摘の内容に限界があるため。

限界の壁

優れたプログラマは限界を引き上げます


•  レビューの中で小手先のテクニックに終始しない「優れたプログラマの考え方」を伝えていくことで、チームの限界を引き上げていきます。

•  いくら優れたプログラマと言えども、闇雲にレビューをするのでは効果がありません。

ただし・・・


・・・

•  ソニックガーデンでも新しく入ったプログラマを教育する手段としてコードレビューを取り入れています。

•  その中で気付いたポイントをいくつかピックアップしました。

•  それが今からお伝えする「7つの秘訣」です。

より効果を上げるために



4. コードレビュー７つの秘訣

21

1. レビューの観点を明確にすること


1. レビューの観点を明確にすること •  リリース前レビューの話なのか、コード品質の話なのか。

•  読む側も漠然と読んで、漠然とコメントを書くのでは効果を生まない。 – 観点を明確にしてレビューすることで指摘する側の精度も上がります。


2. 我が身に返ることを恐れずに指摘すること


2. 我が身に返ることを恐れずに指摘すること •  自分のことは棚に上げる！ •  鋭くツッコミを入れられないなら、レビューの意味は無い。

•  指摘して自分の耳が痛いなら、自分にとっても成長のチャンスだと捉える。


3. 何故悪いコードなのかを論理的に説明すること


3. 何故悪いコードなのかを論理的に説明すること •  「何となく汚い」は指摘ではない。 •  悪いコードだと判断したなら、相手が納得できるように、論理的に説明する。

•  論理的に説明できないなら指摘をすべきではない。


4. 良いコードについて共通認識を持つこと


4. 良いコードについて共通認識を持つこと •  コードレビューのあとに雰囲気が悪くなるのはチームで「良いコード」の認識が揃っていない証拠。

•  「良いコード」を共有することでチームとして成長する。

•  認識を揃えるためには、あるコードを題材にディスカッションの機会を設けると良い。



チームでディスカッションの機会を持つ例

5. 小さい単位でレビューを繰り返すこと


5. 小さい単位でレビューを繰り返すこと

•  大きな単位だとレビューする側もされる側も出番が回ってきにくい。 – 機会を増やすことでみんながレビュー体験をする／小口化することで習慣化する

•  チーム全体で誰かの書いたコードをレビューするのも有効。


6. 指摘は素直な気持ちで受け入れること


6. 指摘は素直な気持ちで受け入れること

•  指摘を素直に受け止められないと成長できない。

•  受け入れた後は同じ失敗を繰り返さない。 – 漠然とコードレビューを受けて、その場はその場で何とかやり過ごして、また同じ失敗を繰り返すメンタルモデルではダメ。


7. 指摘は人格否定でないことを理解すること


7. 指摘は人格否定でないことを理解すること •  自分が一生懸命書いたコードに対して手厳しく指摘を受けるのは辛いこと。。

•  でも、指摘するのはコードであって、あなたの人格を否定しているわけではありません！

•  お互いに「コード」の話をしている、ということを理解した上で指摘をしましょう。



まとめ

37

今日お話した内容

1. クソコードとは何か？ 2. 優れたプログラマとは何か？ 3. コードレビューが改善の近道 4. コードレビュー7つの秘訣


今日お話した内容 •  クソコードとは読む人を怒りの渦に叩きこむコードである。

•  優秀なプログラマに読まれる機会があれば、その人のコードは劇的に改善する。　（※ 効用には個人差があります）


今日お話した内容 1. レビューの観点を明確にすること 2. 我が身に返ることを恐れずに指摘すること 3. 何故悪いコードなのかを論理的に説明すること 4. 良いコードについて共通認識を持つこと 5. 小さい単位でレビューを繰り返すこと 6. 指摘は素直な気持ちで受け入れること 7. 指摘は人格否定でないことを理解すること



ご視聴ありがとうございました！ 41

Engineering

デキるプログラマだけが知っているコードレビュー7つの秘訣