Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コードレビューを支える技術
Search
ktrysmt
June 01, 2017
Technology
1
920
コードレビューを支える技術
6/1 2017 社内LT会で発表したときの資料です
ktrysmt
June 01, 2017
Tweet
Share
Other Decks in Technology
See All in Technology
テストプロセスで大事にしていること #jasstnano
makky_tyuyan
0
150
エンジニアのキャリアをちょっと楽しくする3本の軸/Three Pillars to Make an Engineer's Career More Enjoyable
kwappa
0
2.5k
Cloud Native Java with Spring Boot (CNCF Aarhus, April 2024)
thomasvitale
1
150
[PlatformCon 24] Platform Orchestrators: The Missing Middle of Internal Developer Platforms?
danielbryantuk
1
780
最近たまに見かけるTiDBってなんだ? - Findy
pingcap0315
2
740
EMとして2023年度に頑張ったこと / What we did well in FY2023 as a EM
pauli
1
140
20240418_Google ColabにLLMが搭載されたようなのでPython x データ分析の勉強方法を考えてみる
doradora09
0
120
MapLibreとAmazon Location Service
dayjournal
1
130
Postman v10リリース後を振り返る
nagix
0
170
ServiceNow Knowledge Learning Rise up
manarobot
0
190
生産性向上チームの紹介
cybozuinsideout
PRO
1
840
Delivering Millions of Messages within seconds @ Duolingo
pelelgrino
0
340
Featured
See All Featured
The Language of Interfaces
destraynor
151
23k
Debugging Ruby Performance
tmm1
70
11k
Why Our Code Smells
bkeepers
PRO
331
56k
Side Projects
sachag
451
41k
The Invisible Customer
myddelton
114
12k
BBQ
matthewcrist
80
8.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
354
18k
Rails Girls Zürich Keynote
gr2m
91
13k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
124
32k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
13
1.5k
Building Adaptive Systems
keathley
30
1.9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Transcript
コードレビューを支える技術 コードレビューを支える技術 Kotaro Yoshimatsu 6/1 2017
WHOAMI WHOAMI Kotaro Yoshimatsu @ktrysmt 学生時代 Perl monger 受託開発会社 5年くらい
リクルート 2年目 https://twitter.com/ktrysmt https://github.com/ktrysmt
みなさん
コードレビューしてますか。
わたしのある日のプルリクレビュー →
プルリクの本数 だいたいいつも6~8本 技術スタック JS,CSS(フロントエンド) PHP NodeJS Ruby Docker その他インフラ系いろいろ アサインされてないやつも時々巡回してたり...
問題点 1. 技術スタックが多岐にわたる 2. そもそも数が多い
対策します
1. 豊富な技術スタック 2. 数が多い
1. 豊富な技術スタック 1. 豊富な技術スタック
技術スタックが多岐にわたるのは どうすればいい か。
エコシステムが巨大で対応技術の多い, 安定した開 発環境が必要。
→ Vimでしょ。
(すみませんただの好みです) 一応弁明すると, Vimもプラグインが豊富にあり,CLIベースなので柔 軟。 大抵の言語は標準でサポート,それ以外もエコシステ ムがだいたい吸収してくれる。
Vimについては語りだすとキリがないので… コードレビューに役立ちそうなTipsなどを一部紹介。
プラグインマネージャ vim-fugitive ale vim-easymotion tagbar & ler auto-ctags 高速vimgrep(※後述)
プラグインマネージャ 使いましょう。 Dein, Plug, NeoBundle など
ありがちなのが...
「プラグイン入れすぎて重くなってきた」
(エディタやIDEによりますが) ファイルタイプや拡張子ごとに読み込むプラグインを 絞って速度を維持するなど Plug の例 Plug 'fatih/vim-go', { 'for': 'go'
}
vim-fugitive Vim上でGit操作いろいろできるやつ。 :Gdiff が便利, [c,]c でhunk単位で移動 レビューでは :Gblame がマジ便利
ale 最近の言語とそのエコシステムに一通り対応してる lint & static check の基盤。 主要言語の静的解析にだい たい対応してる。 非同期対応なので作業の邪魔をせず,快適。
特別な設定なしにプラグインを入れるだけでいいのが Good。
vim-easymotion コード上を縦横無尽に動き回れるようになる
tagbar & ler IDEチックに
auto-ctags ctagsのタグファイル自動生成。 :Ctags でOK let g:auto_ctags = 1 で保存時に自動生成
ctagsとは auto-ctagsはこのタグファイル生成をVimから操作し やすくしてくれます。 変数・関数・DOCコメント等の定義リスト(タグファイル)をソ ースコードから生成するツールで,IDEでよくある宣言ジャンプや 呼び出し元への復帰を助ける仕組み。
ctagsについて補足 ctagsはメンテされていないらしいので... universal-ctags を使いましょう
universal-ctags ビルドインストールを推奨 ちゃんとメンテされてる(モダン言語にも対応し てる) 前述のauto-ctagsで,Vimが更に便利に。
豊富な技術スタック対策のまとめ 巨大なエコシステムに乗っかりましょう Vim以外にも色々 IntelliJ,Emacs,Atom,VSCode... 最近だとVSCODEもいいですね 開発が活発 IDEらしさもちゃんとあり プラグインが豊富 意外と軽い 無料
自分の手に馴染むものを選び,育てましょう
次。
2. 数が多い 2. 数が多い
→ 気合で。
2. 数が多い → 気合 (!?) 2. 数が多い → 気合 (!?)
というのは(半分)冗談で…。
高速化・効率化できる工夫をしていきましょう。
効率化できる余地を探す
私の環境の場合 zsh, vim, tig, tmux etc... という感じなので...
この辺の手入れをしてみる git tig zsh grep それぞれ高速化・効率化できそうな箇所を探していき ます
git
レビューでよくつかうコマンド 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
alias gdw="git diff --color-words" インラインdiff spaceやインデントをスルーしてくれるので変数名・ 関数名の変更などが見やすくなる 通常のgit diffと適宜使い分け。
alias glogg='git log --graph --name-status -- pretty=format:"%C(red)%h %C(green)%an %Creset%s %C(yellow)%d%Creset"'
tigがめんどくさいときに。--prettyは表現力が高い ので自分の使いやすいように加工すると良い。
b4b4r07/git-br gbr(git branch --remote)の出力をfuzzy nderで絞込選 択し,選択後自動的に当該ブランチをチェックアウト します。 マジ便利。 特に,ブランチ名が長い・リモートブランチ数が多い リポジトリにおすすめ。
元ソース(小さなShellScript)を,少しいじって使っ てます https://github.com/b4b4r07/git-br
tig
私の.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
こういうことやってる split表示時の幅をもう少し広く g,G を使ってより移動をVimっぽく 任意のログ行で Shift + R すると git
rebase -i 起動 行頭にコミットハッシュ値を6文字表示 diff閲覧時の差分の前後を3行→6行に増やす
zsh
いろいろあります 高速プラグインマネージャ 各種プラグイン zzy nder との組み合わせ zshのパフォーマンス計測
高速プラグインマネージャ antigen, zgen, zplug など zsh使うならぜひ使いましょう これがないと生きていけない...
各種プラグイン oh-my-zsh/plugins/* zsh-users/* だいたいこの辺入れとけばいい感じになります (特に補完系) それぞれかなり量が多いので,使えそうだなと思った ものから一つずつ試してみると良いです (特に補完系)
zzy nder との組み合わせ ghq + peco powered_cd + fzf
ghq + peco history | peco と似たような感じ リポジトリで管理されているものは全部 ghq get
で取 得するようにすると,幸せになれます alias gh='cd $(ghq list -p | peco)' ghq管理下のリポジトリ一覧から pecoで選んで cd
powerd_cd + fzf powered_cd は,薄いshellscript enhancdと似てますが,enhancdはちょっと高機能す ぎるというときに リポジトリ管理外の書き捨てのコードや一時的に落と しただけのソースがある場所も含め,全体的にcdの 履歴管理をしてくれます
alias c="powered_cd" は必須です マジ便利 http://qiita.com/arks22/items/8515a7f4eab37cfbfb17
zshのパフォーマンス計測
zshを色々いじりだすと,zshの起動時間の遅さが気に なってくる
特に私はtmuxを多用するので,zshの起動時間はでき るだけ速いほうが嬉しい...
計測をしたい
単純な例
で,Initializeにかかる時間を計測 (↑起動してすぐexitしてる) $ time (zsh -i -c exit)
遅い箇所をもうちょっと特定できないか
できます
こういうのを仕込むと # .zshenv zmodload zsh/zprof && zprof # .zshrc の末行に
if (which zprof > /dev/null) ;then zprof | less fi
起動時に計測結果が表示される 使わないときは .zshenv のほうをコメントアウト
話はわかったが
めんどくさい!
...というあなたに sh & sherman おすすめ
ほぼ設定不要 軽い デフォルトの状態でかなり便利 補完 履歴管理,などなど プラグインマネージャーも安定( sherman) http:// shshell.com
高速grep
高速grepといえば ag, pt, ack いろいろありますが...
ripgrep
インストールしておくといいです 並列処理で,めちゃくちゃ速い https://github.com/BurntSushi/ripgrep
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>
注意点 デフォルトでは出力結果がsortはされないので, --sort-files をつけるか, | sort するとよいです --sort-files はシングルスレッドになるので, パフ
ォーマンスに注意。
数が多い対策のまとめ 速いは正義 工夫の余地はいろいろあります (それでも気合は必要)
コードをがっつり追いかけるときのレビューが主題だ ったので今回は割愛しますが, プルリク文脈での OSSもいろいろあります。 楽しそう https://github.com/facebook/mention-bot http://haya14busa.com/reviewdog/
まとめ 本当にその作業は必要ですかという業務ハックも, もちろん大事ですが… 一技術者として, 手に馴染んだ道具を手入れしたり,工夫したりするこ とも大切なことだと思います。
普段から手入れをしておくと, 本当に困ったとき=緊急時,救われます。
引き続き,作業効率が改善する仕組みやツールを探し 中です。 みなさんも「これ便利だよ」というものがありました ら教えてください。 泣いて喜びます
EOD