既存プロジェクトに Prettier を導入したけど、コードレビューが辛すぎる件（ラノベタイトル風）

お気持ち表明（いわゆるポエム）です。

前置き

現在関わっている JavaScript プロジェクトには Prettier が入っていません。また、ESLint は入っていますが（Standard）、--fix をしていない状況です。そして、Vue.js を利用してしますが、eslint-plugin-vue が入っていません。

あ、プロダクトの中で上記が入っているのはソースの一部です。それ以外は webpack すら通していません。移行中です。ひとまず現状何もやっていないところは置いといて。

そのままでは厳しいということで、上記 2 つを導入することになりました。

導入手順における「3. コマンドラインでフォーマットを実行する」部分に差し掛かっているのですが、ここで辛みが発生しました。

前提として、弊社で master ブランチにマージするには 1 人以上にコードレビューで LGTM をしてもらう必要があります。

そのため、今回のフォーマットしたコードを誰かに見てもらう必要があります。全ソースを一度にフォーマットしてしまうと、コードの全体を見るのに数日、下手をすると数週間かかってしまいます。

ですので、複数に分けてコードレビューを行っているのですが、毎回そこそこ多い量のコードレビュー依頼が来るため、見るのがとても大変です。

（ここまでコードレビューを依頼する側の想像）

コードレビューを出す対象も複数人いるのですが、毎日全員にコードレビューをお願いするのは気が引けます。

他の作業もあるのに、毎日毎日同じようなコードレビューをするのは嫌だと思うので、日替わりとか隔日とかでコードレビューを依頼しています。

メンバーには申し訳ないのですが、こうするしか方法がなかったんや……

ということでいざコードレビューを出そうとするも、ツールを使ってのフォーマットになるので、「こういう変更を行いました」という単位で分割ができません。

コミットの例としては、「インデントを修正しました」「オプションの順番を変更しました」「長い行を折り返しました」などです。これを分解して出せれば、各コミットごとに比較的楽にコードレビューができるかと思います。

しかし、Prettier とか ESLint は一括で変換をしてしまうので、「フォーマッタを実行しました」というコミットしか作れません。分解してしまうと、手動で直したのか自動でツールがやってくれたのかがわからなくなるためです。

したがって、コードレビューに出す際にはどでかいコミット 1 つで見てもらうしかないのです。見る方は辛いと思います。

そのような意見があることも確かです。 Prettier と ESLint を信じるべきなのは同意です。

しかし、それらを導入したことによって変わったソースが、このプロジェクトにマッチするかどうかということを確認する必要があると思います。「このような整形がされてしまうのなら、Prettier は導入するのやめようか……」といったイメージです。実際にこうなりかけました。

よって、コードレビューは、少なくともある程度はしたほうがいいと思いました。

Prettier とか ESLint は最初から入れておきましょう（もしくは入れない理由付けをしましょう）。そうすれば上記のようなことを考えなくて済みます。

もし途中で入れる場合、コードレビューの文化があるとそれが導入の障壁になりえます。メンバーとよく話し合った上で、コードレビューをするかしないか決めましょう。

コードレビューをすることになったら、すべてのコードを一気に見てもらえるか打診しましょう。

だめだった場合は、ファイルやディレクトリ単位でフォーマットをしてコードレビューしてもらいましょう。

と、自分は思いました。