「開発プロセスを改善するときの折衷案を考える / phpcsのチューニングを行ったときの気づき」に関しての考えをまとめました。
目次
開発プロセスの改善と銘打ち、phpcsのチューニングを行った。コード規約が形骸化されてずっとWarningが発生している状態だった。またフックスクリプトにもphpcsが導入されていたが、現状エラーとなってしまいコミットができなくなってしまうので、コメントアウトされていた。本来はvscodeを用いてリアルタイムで赤線が引かれてエラーがわかるようになっているのだけど・・・。僕自身がそれを見落としてしまったのが、今回直そうと思ったきっかけだったりする。
シンプルに現状に沿ったルールに見直そうと思ったのだけど、実情を見ていくと、物事はどうもシンプルではなかった。
このときのフローについて、記録に残しておく
制約について
次の制約があった
- １．多くの場所でコード規約違反がある
・PSR2などを満たさないコードがいくつもあった。例えば、PSR2では関数名は、camelPaseでなければならないと名目があるが、一部のコードでは、これを満たしていない。また、クラス名もPascalCaseである必要があるが、これも過去のコードでは満たされていないケースもあった。もちろん当時は実装が属人的でありコード規約がなかったのだろう。開発速度を重視した結果か、当時にコード規約の意識がなかったのかはわからない。時間的制約があったに違いない。以前、「スタートアップでは開発プロセスの規約やテストなどといった環境をまず作ってしまう」ということを聞いた。なかなか品質や保守は後回しになってしまうことも実体験として非常によくあるので、この考えは意識したいなあと気づき・・・。
- ２．phpcsのruleset.xmlは変更できない
現在コード規約は導入されているが、これがどうもうまく機能していないのが問題だった。ヒアリングを行ってみると、開発チーム間で共通のルールを使用しているとのこと。規模間や開発にかかわるvendorも異なっているが、それでも同じルールを使っている。そのため、コード規約の変更はコンセンサスを取る必要があり、なかなか手間がかかってしまう。そうなると現実的ではない。。。
「手間がかかるから」とか「やる時間が取れないから」などという理由かと思っていたが、実際のところどうしようもない事情もあった。確かに、「すべてのエラーをなくしたリファクタリングを実現する」理想形を実現することばかりを考えていたが、それはどうも難しそうだ。そのあたりの折り合いをつけられる折衷案を考えることとした。
最初の案
まず考えた方法は、**ruleset.xml**を現状に即したルールに作り替えることだった。しかしこれは断念。理由としては（２）に挙げた通りだけど、このデータをコピーして自身のルールを作ることも考えた。ただ、重複管理になってしまうし、ほかの開発メンバーにローカルの開発環境を更新してもらう手間もあり、あまり現実的ではないように思えた。
最終的にphpcs.shを作った
解決策としてはphpcs.shを作り、独自オプションを導入した。
# もしFILEが＜＊＊＊＞.phpだったときは
# 次のオプションを付け特定のコード規約を除外する
# --exculude=<Sniffs>
# 実行
phpcs $FILE $OPTIONS
それぞれ引数としてFILEを読み取り、特定のファイルに対してはignoreやexcludeなどのオプションを加えてあげる。
その後、シンボリックリンクを張っている。ただ、開発環境ではほかの人の手間を煩わせるわけにはいかないので、フルパスで再定義した
余談
phpcs.shを作る前は、pre-commitにそのまま記載していたのだけど、コードレビュー時にご指摘いただいて分けた。今思うと絶対に分けておいたほうが良いと思う。 あと、最初に「phpcsをチューニング」したいといったが、後ほど「phpcsが動いていないので動かして開発品質を上げる」といったほうがウケが良かった。