【デブサミ福岡B5】コードレビューの進め方～全員で行う品質の維持～
•
19 likes•3,266 views
Developers Summit 2015 FUKUOKA B5セッションきしだ様の資料です。
![自己紹介
きしだ なおき
開発センター 開発室
就職して半年以上が過ぎました。
とりあえず午前中に出社
できるようになってきました。
][](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to 【デブサミ福岡B5】コードレビューの進め方～全員で行う品質の維持～
Similar to 【デブサミ福岡B5】コードレビューの進め方～全員で行う品質の維持～ (20)
More from Developers Summit
More from Developers Summit (20)
Recently uploaded
Recently uploaded (12)
【デブサミ福岡B5】コードレビューの進め方～全員で行う品質の維持～
- 1. ⓒ 2015 LINE CORPORATION コードレビューの進め方 〜全員で行う品質の維持〜 2015/9/14 LINE Fukuoka きしだ なおき
- 3. 今日の話 • LINE Fukuokaで行っている開発者 同士によるコードレビューについて • どのようにコードレビューをするか • どのようなコードレビューをするか • 注意点 • 得られたもの • など
- 5. コードレビューの目的 すでに存在する問題を排除する 今後問題が入りこむ可能性を削減する • コードの見やすさ • コードの構造 • コードの統一性 • 気持ちよさ プロダクトの品質を改善する
- 6. 前提となるプロセス 分散バージョン管理(Git/Mercurial)と Pull Requestに対応したツールが必要 GitHub+Work in Progress(WIP)パターン
- 7. Work In Progress(WIP)パターン • ブランチを作る • とりあえず空コミット • リモートへプッシュ • Pull Requestを作る(WIP) • 作業する • コミット • プッシュ • セルフレビュー • Pull Request更新(WIPをはずす) • レビュー • マージ
- 8. 言語はどうする？ 日本語がわかる人だけで開発する - 日本語 • プルリク名やコミットコメントなどの言語をどうするか • プロジェクト依存 多くの人にわかる言語で少ない情報を書くより、 自分のわかる言語で多くの情報を書くほうがいい - 書いてあればだれかが翻訳できる。 - 書いてなければ誰にも補完できない。 • 本人でさえ！ 日本語が苦手な人と開発する - 英語
- 9. プルリクやコミットコメントで 英語を練習しないほうがいい • 英語で書くために余分な時間がかかる • 英語で書けない情報が欠落する • 最初はコミットコメントを書くこと自体に不慣れなので 日本語でまず書けるのが大事 • そのコストを支払うなら、オンライン英会話で英語を 勉強したほうがいい - 会社としてオンライン英会話を受けさせてもらってます
- 10. だれがレビューするか • 2人以上がいい • 同じプロジェクトの技術者が理想 • いないときは他のプロジェクトの人 • Javaのコードは最初は全部レビュー していました
- 11. いつレビューするか • 気が向いたとき • 仕事を始めるときと3時くらい、とか • マージを急ぐときにはチャットか物理で 連絡がくる
- 14. コーディングガイドライン • コーディング規約 - フォーマット - 命名規約 - 用語集 • 対応英語を決めておく • 迷ったときの基準 • 新メンバーが入りやすく • すべての人が自信をもってレビューできるわけではない ので、指針があるとやりやすい
- 15. 静的コード解析ツール • フォーマッタ - Checkstyle • コードチェック - FindBugsなど • 機械的なレビューを減ら す
- 16. 何に注目するか • 読みやすさ • 統一された形式 • 適切なコメント • 言語機能・APIの適切な利用 • ロジックの正しさ • 構造が適切か • 仕様にあっているか • テストの妥当性 • パフォーマンス • セキュリティ
- 18. 読みやすいコードは コードレビューの負担をさげる • コードレビューには時間がかかる - レビュワーの数だけ • レビューしやすいコードで時間を節約する • もちろんメンテナンスの負担もさげる
- 20. 驚きがないコード • ありそうなところにありそうなコードが書いてある • それっぽい名前のメソッドがそれっぽい動きをする • それっぽい名前の変数にそれっぽい値が入っている • いつもと違うことをするときには、いつもと違う書き方 になっている
- 21. 統一された形式 • インデントやカッコの位置、スペース、改行の規則 • 名前付け規則 • 統一された順番 • コードを書いた人の好みも尊重するので自分の好みと 違ってもいいけど、統一すること
- 22. 改行 • 右に長過ぎない - GitHubではみ出さない程度に • 文脈を考えて改行する - SQLの改行は句単位で - はみ出さないことが主目的では なく見やすくすることが主目的
- 23. SQLの改行 × SELECT shohin.name, bunrui.name FROM shohin LEFT JOIN bunrui ON shohin.id=bunrui.id ○ SELECT shohin.name, bunrui.name FROM shohin LEFT JOIN bunrui on shohin.id=bunrui.id
- 24. 用途の決まった名前 • 変数 - i 整数 - e 例外 • メソッド - getで始まるメソッドはイミュータブルに • 通信したりデータベースに書き込んだりしない • クラス - XxxErrorはextends Errorっぽい
- 25. 統一された順番 • 識別情報(id/名前/カテゴリ) 実データ → メタデータ (登録日付など) • オーバーロードは引数の少ないほうから多いほうへ • 引数順と値設定順をあわせる • ifとelseで同じことをするなら同じ順に処理を行う
- 26. オーバーロードは 引数の少ないものから some(String name){ some(name, false); } some(String name, boolean flag){ // proc }
- 27. 引数順と値設定順をあわせる some(long id, String name, boolean enabled){ this.id = id; this.name = name; this.enabled = enabled; }
- 28. ifとelseで同じことをするなら 同じ順に処理を行う • 順番が違うと間違いやヌケに気づきにくい if(exist){ this.id = id; this.name = name; this.enabled = enabled; }else{ this.id = 0; this.name = “”; this.enabled = false; }
- 29. 適切なコメント • 適切にソースコードを書けばコメントは不要？ - ソースコードが何をしてるかはわかりやすくなるけど、 何をしようとしてるかはわからない • コードレビューはソースを解析して何を してるか把握する活動ではない • ソースコードが意図通りになっているか 確認する - コメントで意図を書く
- 30. 適切なコメント • JavaDoc - publicなメンバにはJavaDocコメントを書く • @paramなどを埋める必要はない - 戻り値booleanにはJavaDocを書く • true/falseの意味するところはコンテキスト依存 • 処理に従ったコメント - if( data.isEmpty()) hoge() • ×データがあるときにはhogeをしない • ○データがないときにhogeをする • なにもしないブロックにはdo nothing等 • いつもと違うことをするときにはコメント - forEachのラムダ内でのreturn
- 31. forEachのラムダ内でのreturn void foo(List<Item> list){ list.forEach(item -> { if(!item.isEnable()){ return; // ループを続ける } someProc(); otherProc(); }); } • ラムダ内でのreturnはメソッド本体を抜けない
- 32. 言語機能・APIの適切な利用 • Java5以降のAPI - try-with-resource - 数値リテラルの区切り - isEmpty • String/List - Files - Objects • Java8
- 33. Files/Objects • Files.copy • Files.lines • Files.newBufferedReader • Objects.requireNonNull • FilesとObjectsはひととおり 確認しておくといいです
- 34. Java8 • Stream • Optional • Map
- 35. Stream • ソース・中間処理・終端処理を意識する • ソース - stream() / Arrays.stream() / Stream.of() • 中間処理 - map() / flatMap() / filter() • 終端処理 - anyMatch() - collect • toList() / toMap() / joining()
- 36. Streamの改行 • ソースまでは一行にする - stream()を単独行にしない • 改行をいれるなら終端処理は単独行に • List<String> items = list.stream() .filter(item -> !item.isEmpty()) .map(item -> item.toLowerCase()) .collect(Collectors.toList());
- 37. Optional • return nullを書かない • isPresentでの判定をなるべくさける - ifPresentを使う - if(optFoo.isPresent()){ someProc(optFoo.get()); } - optFoo.ifPresent(foo -> { someProc(foo); });
- 38. Map • getOrDefault - 値がないときにデフォルト値を使う - value = map.getOrDefault(key, “”) • computeIfAbsent - 値がないときに処理した値をMapに設定して返す - value = map.computeIfAbsent(key, k -> db.find(key));
- 39. ロジックの正しさ • 条件の不備 - (name != null && name.isEmpty()) || name != null - コピペミスだった • 値設定もれ • ぬるぽ - メソッドに渡ってこないはずだとしても nullには気をつけたほうがいい。 - あとで他から呼び出されることもある
- 40. 構造が適切か • 設計を反映した構造 - ビューに業務ロジックを置かない • 意味を反映した構造
- 41. 意味を反映した構造 • 変数名はポジティブに - 例えば、表示できるかどうかをinvisibleで表すと • if (!invisible) { 表示できる } • 「表示できない、ではない」という二重否定になる
- 42. • 例外処理を条件処理して通常処理は インデントなるべくしない - × if(exist){ 長い処理 } return; - ○ if(!exist) return; 長い処理 意味を反映した構造
- 43. 仕様にあっているか • 仕様どおりの動きか • 漏れはないか • テンプレート中の金額計算は注意する • 日本語が正しいか - 結構typoがある • 少数→小数 • サーバ → サーバー
- 44. テストの妥当性 • テストはコードレビューでしか品質担保できない • テストにはコメントを書く - テストは開発者の裁量が大きいので、コメントがないと 意図がわからずレビューできない • SQLには疎通テストを書く - 静的文法チェックがないので、テストで代用する - 文字列でのフィールド指定してるところも • テストが多すぎない
- 45. パフォーマンス/セキュリティ • パフォーマンス - データベースアクセス回数は問題ないか - 計算量として大丈夫か • セキュリティ - HTML出力する文字がエスケープされているか - SQLの組み立ては大丈夫か
- 46. コードレビューの効果 • コード品質向上 • 仕様共有 • 小さなノウハウの共有 • コードレビューのやりかたの共有 • コードの健全性をたもつ - 動くんだけど死にそうなコードとかがないように • 自分の考えを明確化できる • ブログの間違いに気づく - もっといいAPIがあると指摘したら、 「きしだのはてな」に書いてあったと返される
- 47. コードレビューの注意 • 事実のみを指摘する • 対案を提示する • 結構時間がかかる
- 48. GitHubが使えない場合 • よそのサーバーに置けない - GitHub Enterprise - Backlog Enterprise • お金かけれない - BitBucket • 5ユーザー無料 - Backlog • 10ユーザー無料 • よそのサーバーに置けな い。お金もかけれない - GitLab - GitBucket
- 49. Gitが使えない場合 • 会議 - 一日一時間とか • メール - メーリングリストを使う • チケット - タスク管理・バグ管理システムを使う • ソースのコメントに記述 - http://d.hatena.ne.jp/camlspotter/20120814/1344919762 • レビューツールを使う - ReviewBoardなど • がんばってGitを使う • LINE Fukuokaに転職する
- 51. Thank you.