レビューで気になったこと、指摘したこと、モヤモヤしたこと

UNIXコマンドを味方にしよう

UNIXコマンドを味方にしよう

今日はレビュー自体の話でなく、レビューを依頼する際にしておきたい事前準備の話をしたいと思います

IDEやGUIツールを窓から投げ捨てよう

IDEやGUIツールは非常に便利です。否定はしません
ただ、こういったツールには一つの弱点があります
それは、検索結果やなぜ不要なコードであると判断したかの基準が機械任せになることです
また、異なるIDEを使っている場合はその特性まで理解する必要があるかも知れません
更に不幸なのは、その結果が見やすいリストとして出現してしまうことです
それ自体は問題ありません、ただ、それをレビュアーにどう伝えますか？

UNIXコマンドは再実行可能

たとえば、障害対応のチケットに下記の調査方法があればレビュアーの負担が減ります
問題が起きたのでxxxでgrepした
git-blameしたところ、この変更点が問題の様だ
git-showしてみたが他にもバグにつながりそうな箇所はyyyとzzzだ
さらに調べたが、zzzには影響がありそうだがyyyは問題なさそうだ
上記を踏まえてyyyを実行するロジックはそのままにxxxとzzzを実行する処理を新たに作った
レビュアーはこれらのコマンドがチケットに記載されていればそのコマンドをまずレビューすることから始めます
そして、それらのコマンドが検証通りであることを確認して初めてレビューを始めることが可能となります
これらの情報がなければあなたはなぜ、その行動をとったのか説明せざるをえないでしょう

IDEの検索を使っている場合に起こること

説明責任を果たせない、もしくはスクリーンショットをとり貼り続ける日々を余儀なくされる
数年前までSIerにいたので、こういった仕事をしている方は何人か知っています
ただ、そういった仕事をされる方々はコードレビューを依頼する働き方をしている人間とは違う目的を持っています
また、コードレビューを依頼する側の人間がIDEの検索結果を頑張って貼り続ける姿はあまり見たことがありません
テキストのコピー&ペーストは簡単です
対して、画面のコピー&ペーストは今なお猥雑です

UNIXコマンドを活用しよう

もし、IDEの検索機能で調査しているなら今すぐにでもgrepコマンドに置き変えましょう
あなたが何を検索し、たとえば小文字の考慮が漏れているねといったことにはレビュアーが気付いて手戻りが減るかも知れません(たとえばPHPの場合は関数は大文字小文字を区別しません!!)
また、どのコードを探索し、その結果としてバグの原因であったかを数ヶ月後に知ることを可能にするパンくずともなりえます
grepコマンドを利用し、自分の足跡をしっかりとメモしましょう
ファイルの場所がわからない？findコマンドを使いましょう
同名のファイルがあるなら、パイプに食わせてxargsでgrepすればお探しの関数はすぐに見つかるでしょう
Gitを使っていて、変更点を探索したいのならばgit-logやgit-blameやgit-showが助けとなってくれます

UNIXコマンドを使った調査結果はテキストをもたらす

もはや、あなたはチケットにそのコマンドの実行結果をコピペするだけで説明責任の一端を成し遂げました
Macを使っているのであれば、パイプにpbcopyを食わせてやるだけでクリップボードに内容が記録されます
あとはペーストするだけです
調査結果を記録することはあなたが間違った時、どういう調査をしてもらいたいかを示したい時に役に立つでしょう
IDEやGUIツールはたしかにあなたの助けとなっているでしょう
ただ、そういったツールたちも内部的にはこの様なコマンドを叩いています
そういったツールが成し遂げる内相を理解して使いましょう
でなければ、あなたはチールを使う側でなく、ツールに使われる側です

伝えいこと

ツールが暗黙に行ってくれることに甘えず、記録者として振舞いましょう
ツールで調査した結果を横で見せられる時間を喜ぶエンジニアはそれほど多くはないでしょう
自身の調査を正確なテキストに落とし込むことであなたの同僚の費やす時間が減ります
また、あなたが説明に割く時間も短縮されるかも知れません
調査のログをとりましょう
そのログはきっとあなたの将来のなんでこの時にこうおもったんだっけ？を解決してくれます
そして、今から7年前に行動を元にこれを教えてくださったSさんにこの場を借りて感謝を。。