こんにちは。クルーズ株式会社CTOの鈴木です。
今回はSHOPLISTのリファクタリング作業第一歩として、不要ソースを削除して論理LOCを15%削減した話をします。
論理LOCってなに？
・LOC = Lines of Codeのことで、平たく言えば行数です。
昭和のSIerっぽいですね（笑）。この時代だとコード行数で会話することはほぼ無いのですが、不要ソースの削除の話なので今回はわかりやすい指標としてLOCを使って話したいと思います。
ちなみに、
・物理LOC = 単純なソースコードの行数
・論理LOC = コメントや空白行など機械的に省けるソース以外を省いた行数
という定義です。
詳細はWikipeadia のLOCの説明を見てください。あくまでもソースコードの規模を見る単位としてしか今回使わないので説明は割愛します。
不要なソースコードを削除する目的
まずリファクタリングの第一歩として不要なソースコードの削除を行うかについてですが大きく分けて２つの目的があります。
①狭義でのデッドコードを排除する前処理として、雑音となりそうなファイルやまったく使っていないソースコードの一部を先に消すことで、今後行うリファクタリング作業の効率を上げること（可読性を下げる要因を少しでも排除してこと）。
②未使用ライブラリであっても自動ロードの対象となっているディレクトリ内のものはフレームワークが実行時に読み込んでしまい、Webサーバのメモリを無駄に消費してしまうため、無駄なメモリ確保をやめてWebサーバのスループットを上げること。
②はどちらかというとおまけで今回は主に①がメインの目的です。
今回の作業を行う背景として、現在SHOPLISTで使用している自社で開発した独自フレームワークがSHOPLISTの前にCROOZ株式会社で運営していた公式コンテンツ、ブログやSNSでも使われていたものを機能拡張したもので、当時のコンテンツ運営に必要ではあるもののSHOPLISTのシステム運用では不要なライブラリなどを含んで自動ロードしてしまっていること。そしてSHOPLISTのソースコードにおいても、過去に運営していた姉妹サイトや、すでに終了した機能のソースコードがリポジトリのリリース対象ブランチ内に入っていることがあります。
今後のリファクタリング作業では、定数、変数、関数レベルで未使用、重複を分析していくことになり、その作業の雑音となる不要なソースコードの排除については一番初めに実施すべき内容なので今回行いました。
今回の不要ソースの削除にあたり、独自フレームワークのソースコード部分はCROOZ入社後携わっていた部分でありナレッジがあったため私が担当し、SHOPLISTのソースコード部分については、開発部の数名にリファクタリング時間の中で対応を依頼しました。
実施結果
以下、実施前後のファイル数と論理LOCの比較です。
１．実施前
13,274ファイル、1,998,657論理LOC
２．実施後ファイル数
12,475ファイル、1,699,309論理LOC
３．前後比較
・ファイル数：800ファイル、約6%分の削減
・論理LOC ：30万行、約15%分の削減
まとめ
実施してみて、リファクタリング作業が非常に行いやすくなったというのが所感です。
一方で、クラスファイルのメソッドの動的呼び出し箇所を不要なソースと誤って削除してしまい、その後のデバッグで気づくなど、機械的に未使用な処理をさがして消すということが難しいケースも体験し、なかなか難しいと感じた部分もあります。
ただ、リファクタリングで行う内容にもよるのですが、未使用の定数の検索や重複するクラスの把握する際に、今までは明確に使ってないソースであっても機械抽出で上がってきてしまうため雑音になっていたものがなくなったので本質的な処理の見直しに使える時間が増えるのは大きかったです。
今後は内部処理の見直し、特にDB呼び出しまわりに積極的に手を入れていこうと思います。
-------------------------------------------------------------------------------------------------
※2020年の内容を記事にしており、2020年11月以降PHP7サポート切れをはじめとした脆弱性リスクへの対処は完了しております。
