Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

【デブサミ福岡B5】コードレビューの進め方~全員で行う品質の維持~

2.720 visualizaciones

Publicado el

Developers Summit 2015 FUKUOKA B5セッションきしだ様の資料です。

Publicado en: Tecnología
  • If you’re struggling with your assignments like me, check out ⇒ www.HelpWriting.net ⇐. My friend sent me a link to to tis site. This awesome company. After I was continuously complaining to my family and friends about the ordeals of student life. They wrote my entire research paper for me, and it turned out brilliantly. I highly recommend this service to anyone in my shoes. ⇒ www.HelpWriting.net ⇐.
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

【デブサミ福岡B5】コードレビューの進め方~全員で行う品質の維持~

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

×