コードレビューを支える技術

6/1 2017 社内LT会で発表したときの資料です

Transcript

1. コードレビューを支える技術 コードレビューを支える技術 Kotaro Yoshimatsu 6/1 2017
2. WHOAMI WHOAMI Kotaro Yoshimatsu @ktrysmt 学生時代 Perl monger 受託開発会社 5年くらい リクルート 2年目 https://twitter.com/ktrysmt https://github.com/ktrysmt
3. みなさん
4. コードレビューしてますか。
5. わたしのある日のプルリクレビュー →
6. プルリクの本数 だいたいいつも6~8本 技術スタック JS,CSS（フロントエンド） PHP NodeJS Ruby Docker その他インフラ系いろいろ アサインされてないやつも時々巡回してたり...
7. 問題点 1. 技術スタックが多岐にわたる 2. そもそも数が多い
8. 対策します
9. 1. 豊富な技術スタック 2. 数が多い
10. 1. 豊富な技術スタック 1. 豊富な技術スタック
11. 技術スタックが多岐にわたるのは どうすればいい か。
12. エコシステムが巨大で対応技術の多い， 安定した開 発環境が必要。
13. → Vimでしょ。
14. （すみませんただの好みです） 一応弁明すると， Vimもプラグインが豊富にあり，CLIベースなので柔 軟。 大抵の言語は標準でサポート，それ以外もエコシステ ムがだいたい吸収してくれる。
15. Vimについては語りだすとキリがないので… コードレビューに役立ちそうなTipsなどを一部紹介。
16. プラグインマネージャ vim-fugitive ale vim-easymotion tagbar & ler auto-ctags 高速vimgrep（※後述）
17. プラグインマネージャ 使いましょう。 Dein, Plug, NeoBundle など
18. ありがちなのが...
19. 「プラグイン入れすぎて重くなってきた」
20. （エディタやIDEによりますが） ファイルタイプや拡張子ごとに読み込むプラグインを 絞って速度を維持するなど Plug の例 Plug 'fatih/vim-go', { 'for': 'go' }
21. vim-fugitive Vim上でGit操作いろいろできるやつ。 :Gdiff が便利， [c,]c でhunk単位で移動 レビューでは :Gblame がマジ便利
22. ale 最近の言語とそのエコシステムに一通り対応してる lint & static check の基盤。 主要言語の静的解析にだい たい対応してる。 非同期対応なので作業の邪魔をせず，快適。 特別な設定なしにプラグインを入れるだけでいいのが Good。
23. vim-easymotion コード上を縦横無尽に動き回れるようになる
24. tagbar & ler IDEチックに
25. auto-ctags ctagsのタグファイル自動生成。 :Ctags でOK let g:auto_ctags = 1 で保存時に自動生成
26. ctagsとは auto-ctagsはこのタグファイル生成をVimから操作し やすくしてくれます。 変数・関数・DOCコメント等の定義リスト（タグファイル）をソ ースコードから生成するツールで，IDEでよくある宣言ジャンプや 呼び出し元への復帰を助ける仕組み。
27. ctagsについて補足 ctagsはメンテされていないらしいので... universal-ctags を使いましょう
28. universal-ctags ビルドインストールを推奨 ちゃんとメンテされてる（モダン言語にも対応し てる） 前述のauto-ctagsで，Vimが更に便利に。
29. 豊富な技術スタック対策のまとめ 巨大なエコシステムに乗っかりましょう Vim以外にも色々 IntelliJ,Emacs,Atom,VSCode... 最近だとVSCODEもいいですね 開発が活発 IDEらしさもちゃんとあり プラグインが豊富 意外と軽い 無料 自分の手に馴染むものを選び，育てましょう
30. 次。
31. 2. 数が多い 2. 数が多い
32. → 気合で。
33. 2. 数が多い → 気合 (!?) 2. 数が多い → 気合 (!?) というのは（半分）冗談で…。
34. 高速化・効率化できる工夫をしていきましょう。
35. 効率化できる余地を探す
36. 私の環境の場合 zsh, vim, tig, tmux etc... という感じなので...
37. この辺の手入れをしてみる git tig zsh grep それぞれ高速化・効率化できそうな箇所を探していき ます
38. git
39. レビューでよくつかうコマンド alias gdw="git diff --color-words" alias glogg='git log --graph --name-status -- pretty=format:"%C(red)%h %C(green)%an %Creset%s %C(yellow)%d%Creset"' b4b4r07/git-br
40. alias gdw="git diff --color-words" インラインdiff spaceやインデントをスルーしてくれるので変数名・ 関数名の変更などが見やすくなる 通常のgit diffと適宜使い分け。
41. alias glogg='git log --graph --name-status -- pretty=format:"%C(red)%h %C(green)%an %Creset%s %C(yellow)%d%Creset"' tigがめんどくさいときに。--prettyは表現力が高い ので自分の使いやすいように加工すると良い。
42. b4b4r07/git-br gbr(git branch --remote)の出力をfuzzy nderで絞込選 択し，選択後自動的に当該ブランチをチェックアウト します。 マジ便利。 特に，ブランチ名が長い・リモートブランチ数が多い リポジトリにおすすめ。 元ソース（小さなShellScript）を，少しいじって使っ てます https://github.com/b4b4r07/git-br
43. tig
44. 私の.tigrc bind generic g move-first-line bind generic G move-last-line bind main G move-last-line bind main R !git rebase -i %(commit) bind diff R !git rebase -i %(commit) set main-view = id:width=6 date author commit-title:graph=yes,refs=yes set diff-context = 6 set split-view-width = 70% set line-graphics = utf-8
45. こういうことやってる split表示時の幅をもう少し広く g,G を使ってより移動をVimっぽく 任意のログ行で Shift + R すると git rebase -i 起動 行頭にコミットハッシュ値を６文字表示 diff閲覧時の差分の前後を３行→６行に増やす
46. zsh
47. いろいろあります 高速プラグインマネージャ 各種プラグイン zzy nder との組み合わせ zshのパフォーマンス計測
48. 高速プラグインマネージャ antigen, zgen, zplug など zsh使うならぜひ使いましょう これがないと生きていけない...
49. 各種プラグイン oh-my-zsh/plugins/* zsh-users/* だいたいこの辺入れとけばいい感じになります （特に補完系） それぞれかなり量が多いので，使えそうだなと思った ものから一つずつ試してみると良いです （特に補完系）
50. zzy nder との組み合わせ ghq + peco powered_cd + fzf
51. ghq + peco history | peco と似たような感じ リポジトリで管理されているものは全部 ghq get で取 得するようにすると，幸せになれます alias gh='cd $(ghq list -p | peco)' ghq管理下のリポジトリ一覧から pecoで選んで cd
52. powerd_cd + fzf powered_cd は，薄いshellscript enhancdと似てますが，enhancdはちょっと高機能す ぎるというときに リポジトリ管理外の書き捨てのコードや一時的に落と しただけのソースがある場所も含め，全体的にcdの 履歴管理をしてくれます alias c="powered_cd" は必須です マジ便利 http://qiita.com/arks22/items/8515a7f4eab37cfbfb17
53. zshのパフォーマンス計測
54. zshを色々いじりだすと，zshの起動時間の遅さが気に なってくる
55. 特に私はtmuxを多用するので，zshの起動時間はでき るだけ速いほうが嬉しい...
56. 計測をしたい
57. 単純な例
58. で，Initializeにかかる時間を計測 （↑起動してすぐexitしてる） $ time (zsh -i -c exit)
59. 遅い箇所をもうちょっと特定できないか
60. できます
61. こういうのを仕込むと # .zshenv zmodload zsh/zprof && zprof # .zshrc の末行に if (which zprof > /dev/null) ;then zprof | less fi
62. 起動時に計測結果が表示される 使わないときは .zshenv のほうをコメントアウト
63. 話はわかったが
64. めんどくさい！
65. ...というあなたに sh & sherman おすすめ
66. ほぼ設定不要 軽い デフォルトの状態でかなり便利 補完 履歴管理，などなど プラグインマネージャーも安定（ sherman） http:// shshell.com
67. 高速grep
68. 高速grepといえば ag, pt, ack いろいろありますが...
69. ripgrep
70. インストールしておくといいです 並列処理で，めちゃくちゃ速い https://github.com/BurntSushi/ripgrep
71. Vimmer向け 外部vimgrepにripgrepを設定するとマジで幸せになれ ます！ if executable("rg") set grepprg=rg\ --vimgrep\ --no-heading set grepformat=%f:%l:%c:%m,%f:%l:%m endif command! -nargs=* -complete=file Rg :tabnew | :silent grep <args>
72. 注意点 デフォルトでは出力結果がsortはされないので， --sort-files をつけるか， | sort するとよいです --sort-files はシングルスレッドになるので， パフ ォーマンスに注意。
73. 数が多い対策のまとめ 速いは正義 工夫の余地はいろいろあります （それでも気合は必要）
74. コードをがっつり追いかけるときのレビューが主題だ ったので今回は割愛しますが， プルリク文脈での OSSもいろいろあります。 楽しそう https://github.com/facebook/mention-bot http://haya14busa.com/reviewdog/
75. まとめ 本当にその作業は必要ですかという業務ハックも， もちろん大事ですが… 一技術者として， 手に馴染んだ道具を手入れしたり，工夫したりするこ とも大切なことだと思います。
76. 普段から手入れをしておくと， 本当に困ったとき＝緊急時，救われます。
77. 引き続き，作業効率が改善する仕組みやツールを探し 中です。 みなさんも「これ便利だよ」というものがありました ら教えてください。 泣いて喜びます
78. EOD