2016の4日目です。LambdaとMackerelでプロットしてみよう」でした。コードレビューを行っていると、このようなコメントを一度はする・されると思います。インデントやスペースの抜け漏れといった、細かいコーディングスタイルに関する指摘ですね。人力でフォーマットの指摘をするのは見逃しが発生しやすく、細かい部分を確認するコストがかかります。小言のようなコメントになってしまいがちで、開発者・レビュアー双方に負担が増えてしまいます。このような作業は機械に任せましょう。RuboCopやPHP-CS-Fixer、ESLintといったコーディング規約チェックツール(Lintツール)が役立ちます。Lintツールを導入することでコーディング規約の実践にかかるコストを減らし、可読性・保守性の向上に貢献したり、より本質的な部分のレビューに時間を使えたりできることは、多くの方が実感していることでしょう。既存プロジェクトに導入する際の課題しかし、既存のプロジェクトにLintツールを導入するには課題があります。忘れる、面倒くさい、よくわからない→結局自分しかやってないとか......Lintツールを導入すること自体が目的ではありません。Lintツールの助けを得て、継続的に、将来にわたって読みやすいコードを作っていくことが目的です。導入しても開発サイクルの一部として定着しなければ意味がありません。無理なくチーム全員で取り組めるような仕組みを作り、段階的に導入していくことが必要になるでしょう。今回Lintツールを導入したチームも、上の課題に当てはまっていました。無理なくチーム全員で取り組めるような仕組みでは、「無理なくチーム全員で取り組めるような仕組み」とはなんでしょうか?様々あるかと思いますが、今回は以下の3つの対策を行うことで課題に対処しました。Request内で追加・変更したファイルのみを対象にチェックをかけ、段階的かつ確実に直していく言語をまたがってチェック・修正を一発でできるスクリプトを用意しておくCI中に実行することで目に見えてわかる結果を出し、強制力をもって開発サイクルに載せるでは、ひとつずつ紹介していきます。サンプルリポジトリは以下にあります。Request内で追加・変更したファイルのみを対象にチェックをかけ、段階的かつ確実に直していく全ファイルを対象にチェックをかけると大量の違反が見つかり、自動修正しても差分が多すぎて正しく動くかの検証が困難になります。そこで、新しく追加するコードに対してのみチェックをかけるようにします。diffのオプションを使って取得することができます。Yakst--diff-filter=ACMで追加・変更したファイルのみ抽出しますステータスはACDMRTUXB*がありますが、リネーム(移動)でチェックが走るのはどうかなということでACMとしてみました対象ファイルを限定することで、新しく追加するコード、および差分が出たファイルは確実にコーディング規約が守られた状態になります。ありますが、普段行う開発のついでに、無理なく自動的にコードがきれいになっていく世界を作ることができます。言語をまたがってチェック・修正を一発でできるスクリプトを用意しておく言語ごとにLintツールは異なるため、(共通点は多いものの)各ツールやコマンド体系を覚える必要があります。フロントエンドのコーディングであれば、PHPテンプレート・CSS・JavaScriptファイルを同時に編集する場合もあるでしょう。このときにLintツールをそれぞれで実行する必要があるのは面倒です。そこで以下のような一括チェック用のシェルスクリプトを用意しました。fiさらに各ツールのインタフェースを合わせるためのラッパースクリプトを用意します。これでbin/check-coding-ruleを実行すればすべてのLintツールでチェックが行われます。自動修正は--fixオプションで行なえます。スクリプトはもうちょっといけてる感じにできると思いますが、ツールを意識することなく、コマンド一発でチェック・修正を行えるようにできました。CI中に実行することで目に見えてわかる結果を出し、強制力をもって開発サイクルに載せる最後に、コーディング規約チェックをCIで実行し、規約違反があった場合はCIを失敗させるようにします。目に見えてわかるようにすることで、規約チェックがあることを意識でき、自然とチェック・修正を行えるようになります。CIでは以下のように設定できます。phpunit規約違反があるとこのようにCIが失敗します。Lintツールではどこがどのエラーなのか出力するようにできるので、設定しておくととても親切になります。強制力をもつことになるため、突然導入されて戸惑わないよう、チームメンバーへ事前共有しておくのがよいでしょう。ペパボではデザイナーがコーディングまで行うため、事前にデザイナーさんも交えて話を聞き、現状Lintツールが活用できていない要因と、このような対策をとろうと思いますということを話しました。READMEやWikiに、よくあるエラーとその修正方法をまとめておくことも重要でしょう。今回はESLintを新規導入したため、そのTipsもいくつか載せておきたいと思います。Requestのついでに修正するには厳しそうなためwarningに落としました今後も調整になるかと思いますが、.eslintrcはこのようにしましたまとめコーディング規約チェックを「無理なくチーム全員で取り組めるような仕組みを作る」ことを目指しました。そのために、以下の対策を行いました。Request内で追加・変更したファイルのみを対象にチェックをかけ、段階的かつ確実に直していく言語をまたがってチェック・修正を一発でできるスクリプトを用意しておくCI中に実行することで目に見えてわかる結果を出し、強制力をもって開発サイクルに載せる気になる結果ですが、ESLintの追加はマージできていないため、残念ながら結果はこれからとなります...。PHP-CS-Fixerは既に導入されており、非常によいサイクルが回っています。日常的にコーディング規約チェックを行うことができ、既に当たり前のようになっています。JavaScriptのチェックも同じコマンドで同時にできるようにしたため、同様に良い結果となることを期待しています。みなさんも、無理なく自動的にソースがきれいになっていく世界、作ってみませんか?おまけ記事の内容からは外れるため特に書いていませんでしたが、このタスクは新卒研修のOJTで配属されたチームで行ったものです。PHP-CS-Fixerの最初の導入は同期エンジニアが行い、ESLintの追加・チェックスクリプトの多言語対応を私が行いました。ペパボテックブログを見ていただけると様子がわかりますので、ぜひご覧いただければと思います。