yepで行っている内部品質向上のポイント
今回は開発をするうえで品質を高く保つにあたり基礎や柱の部分ともいえる「yepで行っている内部品質向上のポイント」について紹介します。
ポイントとしては以下の４つとなります。
- コーディングガイドラインに沿ってコーディングする
- 静的解析ツールを利用して警告出ている箇所を修正する
- リファクタリングする
- チームメンバーにレビューしてもらう
コーディングガイドラインに沿ってコーディングする
コーディングガイドラインやルールに沿ってコーディングします。
ガイドラインやルールが競合する場合は以下の優先度で適当します。
- プロジェクト内のルール
- 社内のガイドライン
- フレームワークのガイドライン／ルール
- グローバルスタンダードなガイドライン／ルール（PHPならPSR12準拠など）
一般的なガイドラインやルールは、プロジェクトによっては不適切なケースもあります。
そのため、プロジェクト内で必要に応じてルールの追加や削除を行います。
静的解析ツールを利用して警告出ている箇所を修正する
yepではphpでの開発においてはPHP_CodeSniffer(phpcs)とPHP Mess Ditector（以下phpmd）を利用しています。
推奨環境としてVSCodeにphpcsとphpmdを利用するためのプラグインを導入し各静的解析ツールの機能を利用します。
それぞれルールセットは社内向けのものを用意しており、場合によってはチーム内でルールセットを変更して利用します。
phpcs/phpmd導入前の古いプロジェクトの保守等では、追加変更箇所のみ対応するなどプロジェクトごとに個別ルールを決めて対応しています。
参考（外部サイト）
PHP_CodeSniffer
https://github.com/squizlabs/PHP_CodeSniffer
PHP Mess Ditector
https://phpmd.org/
リファクタリングする
yepではリファクタリングを積極的にしていく事が求められています。
新規開発中も保守開発中も他の機能が追加／修正されていきます。
そうした過程で設計実装当初と状況が変わってしまい現状にそぐわない設計実装になっていることも良くある話です。
現状にそぐわない状態のまま開発を続けていくと、多くの場合はソースコードが複雑になり、保守が大変になっていきます。
こうしてソフトウェアが劣化して行ってしまうことを防ぐためにリファクタリングが必要になってきます。
もちろん、リファクタリングにあたり実装済みの機能が壊れないことが前提です。
大きな範囲のリファクタリングになる場合は、チームのリーダーと相談し開発工数や納期も踏まえてリファクタリングする／しないの判断を行います。
納期やコストの問題もあるため、理想を切り捨てる判断も必要な時もありますが、実現可能な範囲で最高の状態を保って行きたいと考えています。
チームメンバーにレビューしてもらう
yepでは実装したソースコードについて第三者（主にチームメンバ）にレビューしてもらうことを推奨しています。
プログラムの実装作業を行うとどうしても視野が狭くなりがちです。
他の人の目で確認することで視野が狭くなって見逃してしまっていた問題を発見できるようにします。
できるだけ一人で開発ぜすソースコードはチームのものであると意識するためにも、チームメンバーがレビューし個人の責任ではなくチームとして責任を負う様にします。
レビューの観点としては「仕様通りの動作するか」という事も重要ですが私がレビューする場合は、以下の観点も踏あわせて見る／考えるようにしています。
設計：保守しやすさを重視する
- 自分が保守運用するとしたときに楽できそうかどうか
- 不具合が出たときに原因調査しやすいかどうか、出力するログは足りているか
- 不具合修正や機能追加時に影響範囲がすぐに明確に出来そうかどうか
実装：理解しやすさ（シンプルさ）を重視する
- 書くのは１回、読むのはｎ回、実装しやすさではなく読みやすさ／理解しやすさが重要
さいごに
今回はyepで行っている内部品質向上のポイントについて紹介しました。
内部品質の向上は外部品質の向上や保守運用していくにあたり土台とも言える重要な要素です。
2023年5月時点では今回記載した内容となります。
今後もエンジニア一同研鑽をし個人・会社ともに日々成長していきます。