PHPStan+reviewdogでレビュー環境を整えた意図とその振り返り

はじめに

こんな感じでPHPStanの解析結果によりPRに自動でコメントがつくようにしました。

GitHubActionsのwfの記述に関してはこちらの記事を参考にさせてもらいましたので、本記事での詳細は省きます。
導入にあたって意識したことをまとめていけたらと思います。

背景

プロダクトを運用している中で、不具合に起因するインシデントが発生したこと。
静的解析によってリリース前に検知できるような初歩的なものでしたので、再発防止策として導入をしました。

導入に関して

解析範囲

静的解析ツールの組織的な導入は以前もフロントアプリケーションにおいてESLint+huskyで実施したことがありました。
ただ個人的には苦い思い出でして、その際は「pre-commit時に差分の存在するクラス単位で解析を実行する」という状態で導入を開始したので、導入後の開発においてメンバーには相応の負担を強いる形となってしまいました。
対象のプロダクトではローンチ後3年程が経過していたため、動作している既存のソースコードにおいて違反している箇所がかなり検知されてしまい、個人的に今では慣れているものの導入後すぐのタイミングでは生産性にも影響を及ぼしてしまったと感じています。
ただ、静的解析ツールを導入することで生産性にマイナスの影響を及ぼすのは、大局的に見るとおかしい話であるはずと考えています。
不具合発生の早期発見は回収のコストを下げるために重要であり、あらゆるところで語られていることかと思います。
こちらは製造工程がV字モデルという中での調査結果ですが、開発プロセス如何に関わらず早期発見が回収のコストを下げるというのは真なのではないかと思います。

出典：ソフトウェア品質保証の方法論、技法、その変遷

とはいえ当時の導入におけるインパクトは決して小さくなかったと感じており、その要因はソースコードの実態にもあったのだと振り返っています。
適切な粒度でのクラス設計・分割が十分になされていない状態で上記の形としてしまったので、差分の存在するクラス単位というのが、動作確認のテストも含めると想定以上の負担となってしまっていました。

これらに対し、今回は以下の点を決めて導入を進めていきました。

• 行差分単位での解析とすること
• Rule Level6からの導入とすること

Rule Levelに関しては、ゆくゆくMaxに引き上げていきたいと考えています。
ただ今回はCIに組み込むというだけではなくPHPStanの導入自体からまとめて進めていましたので、こちらも最初からMaxは負荷を感じてしまうと考え段階的に上げていく予定です。（実態としてRule Level6で解析を実行したところ、そこそこのボリュームで違反が検知されてしまったというのも一つの理由です。）
スタートラインを6に設定したのは、インシデントで発生した事象の再発防止には6までを設定する必要があったためです。（当初の目的をクリアするために必須でした。）

解析タイミング

タイミングに関しても、これまで運用していたフロントアプリケーションのようにpre-commit時のチェックとしていくことに課題を感じていました。

感じていた課題

• レビュワーと認識の統一を取るのが面倒（検知されたエラーがないにしろ、見送りが発生するにしろ）
• 性悪説となるが、ローカルでの設定に依存するので統制とはならない

静的解析ツールの運用として、リリース前に全ての違反を撲滅せよという統制の仕方をしようとしている訳ではありません。
インシデントの再発防止という目的が前提ではありますが、願っているのは静的解析ツールを導入することで、リスクの検知・議論をすることができるということです。
違反が検知されていたとしてもユーザーに迷惑をかけてしまうのか、運用していく中で問題が発生するのか、などとはまた別の話であり、それが許容されるものであれば対応を見送ることも良しと考えています。

そのためにはレビュワー・レビューイ間で共に違反を検知・認識することが必要であり、ここに統制をかける目的でGitHubActionsのwfを作成しました。
reviewdogを導入したのもCIでストップさせることが目的ではなく、コメントを該当箇所に対してつけることで違反に対する検討を活性化させたかったためです。あと可愛い🐶

振り返りまとめ

• 静的解析ツールの導入が生産性にマイナスの影響を与えていると感じるのであれば、どこか設計に歪みがあるかも。理想の設定・CI・運用ではなく、組織として運用に乗せるためにソースコードの実態をちゃんと見ることは大切だと感じました。
• 導入することで何を求めるのか？は、ちゃんと言語化するのが良いと感じました。経験を積むと直感的には「それは良いこと」「必要なこと」と感じるものも多くありますが、改めて自分で言語化することで気づくこともありました。

個人的には他の色んな組織のCIがどのように設計されているのかをもっと知りたくなった振り返りとなりました！

結果、良かったのか悪かったのか、みたいな話は3ヶ月後くらいにまた記事を書ければなーと思います。
特に以下の観点で改悪のようなものが発生していないかは気にしていこうと思っています。

• ボーイスカウト的に綺麗にできる範囲が少なくなっていること（クラス単位→行単位）
• 逆に捉えると議論の余地を残していることで、問題発生の要因になってしまわないか
• 段階的にRule Levelを上げるとしたことで、Maxとする機を逃してしまわないか（計画立案の見通しがつくか）

to be continued.