お久しぶりです。

今回は何年も運用されているFuelPHPのソースに、PHP-CS-Fixerを導入しましたのでその話をしたいと思います。

はじめに

PHP-CS-Fixerは簡単に言うと、PHPのソース整形をしてくれるものです。設定で色々と調整できるので、細かい設定は下記の公式ドキュメントを読むのが一番手っ取り早いです。

https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/master/doc/rules/index.rst

今回はGit hooksのpre-commitフックを使い、コミット時にPHP-CS-Fixerを実行させるようにしました。

PHP-CS-Fixer導入の流れ

ここではPHP-CS-Fixer導入でやったことを簡単に説明したいと思います。

最初に今回のフレームワークがFuelPHPでしたのでそのコーディングルールに合わせるのが良いと考え、 FuelPHPの公式ドキュメントのコーディングルールを確認しました。

http://fuelphp.jp/docs/1.8/general/coding_standards.html

次にPHP-CS-Fixerの公式ドキュメントのルールの一覧を確認し、FuelPHPのコーディングルールと照らし合わせ、使えそうなルールは設定していくという作業を繰り返しました。

PHP-CS-FixerをFuelPHPで使うのはレアケースなので、インターネットに中々有益な情報がないので、地道な作業ですがこれが結果的に一番早い方法だったと思います。

PHP-CS-Fixerの公式ドキュメントのルールを一通り目に通すことができたので、今回は既に動いているソースなので導入すれば便利ですがリスクがあるため見送ったルールも10個以上あったので、改めてPHP-CS-Fixerの便利さを感じることができました。

一通りルールの設定が完了した後は幾つかのテストケースを作り問題ないかを確認し、その後実際に動いているソースで幾つか確認し問題ないかを確認しました。

気を付けたこと

ここからは幾つかPHP-CS-Fixer導入時に気を付けたことを説明したいと思います。

一つ目ですが PHP-CS-Fixer導入したら、それを全ファイルに適用しそれを一括でリリースするのか、全ファイルではなく案件単位でリリースするかの問題です。

前者は一括で適用されるので、PHP-CS-Fixerのルールが適用されていないファイルがないのは魅力的ですが、 PHP-CS-Fixer適用による不具合があった時に修正量が膨大になる可能性があります。

後者は案件単位なので PHP-CS-Fixer適用による不具合があった時の修正量が膨大になることはないのは魅力的ですが、全ファイルにPHP-CS-Fixer適用までに時間がかかるのと、修正されないファイルはPHP-CS-Fixerが一生適用されない可能性があります。

今回は色々なリスクを考え、後者を選択しました。

それに伴い作業ブランチに本番ブランチを取り込む時に競合が発生した時にPHP-CS-Fixerを実行させないようにする必要が出てきました。

上記の状態でPHP-CS-Fixerを実行させてしまうと、プルリクを作成した際に案件とは関係ない差分が出てしまう問題があるためです。

二つ目はFuelPHPのviews直下のファイルですが、if文やループ文等の書き方がたくさんあるので全ファイルを同じルールにすると、色々問題がありそうな点です。

pre-commitでviews直下のファイルである時と、そうでない時で呼び出すファイルを出し分けるようにしました。差分ですが、views直下のファイルでない時は下記の4つの設定をしました。

・statement_indentation(各ステートメントはインデントする)

・spaces_inside_parentheses(括弧は改行する)

・braces_position(中括弧の設定で、改行する)

・control_structure_continuation_position(if文の設定で、改行する)

views直下のファイルで、下の3つの改行を有効にすると予期せぬバグが起きましたので、特に注意が必要です。

最後に

PHP-CS-Fixer導入後ですが、プルリクを作成した際に自動整形の処理も差分として表示されるので、ソースレビューは大変になった点もあります。

しかし以前は目視でソースレビューしていた箇所が多数ありましたが、目視で確認する箇所が大幅に減り、プログラムを書く際に意識することもかなり減りましたので、結果的にはプラスになったことが多かったと思います。

新規案件でPHP-CS-Fixerを導入するのはそこまで難しいことではないですが、すでに動いているもので導入するには色々と考えないといけないことが増えますので難しくなりますが、品質や生産性をあげるのはリードエンジニアの役目でもあるので、今回チャレンジしてみました。

今回はこれで失礼します。