はじめに
前提として先人が死に物狂いで作り上げたサービス基盤を悪く言うつもりはありません。
むしろフレームワークやできることが少ない時代で今のサービス基盤を作り上げたことにリスペクトしかありません。
それでも長年の運用によって各所に無理が生じるのはどんなサービスでも変わらないとことだと考えています。
本記事はこれまでの改善活動によって生まれたコードの負債をどう解消してきたか、どう解消していくのかなどの思考や行動をまとめた記事です。
課題を抱えながら奮闘されているエンジニアの方にとって何かのきっかけになれば大変嬉しく思います！
状況の共有
基本構成はPHPにHTML、CSSで装飾しJSで動きをつけています。
サイトの運用は16年ほど経っており、その間「WordPress」や「Ruby on Rails」で構築された環境の追加、CSS設計が導入されるなどが行われてきました。
なんとなく察しがつく方もいらっしゃるかもしれませんが、とんでもなく複雑な構造で、煩雑な管理かつ見通しの悪いコードになっています。
あらゆるファイルにPHPのロジックや分岐処理が記述され、CSSはオーバーライドや重複定義、JSも同じような処理が複数ファイルで定義されるなどかなり辛い状況です。
課題は「属人化」
複雑な構成だからこそ新しいメンバーがジョインしづらく、誰か1人にノウハウや実務が偏る状況にならざるをえない状況だったと考えています。
当然リソースも不足しがちなのでリファクタリングに時間を費やすことはできません。
コードの負債はどんどん蓄積されていきます。
属人化はいけないのか？
ここで「属人化」について考えを述べておきます。
属人化は悪いことではないと思っています。
サービスが成熟していない段階では属人化しているのは効率が良い場合もあると思います。
ただ、サービスを拡大する場合やメンバーが増えた場合には足かせに可能性があるのも事実だと考えています。
リファレンスの充実や見通しの良い構造やコードで開発しておくことでいつでも誰もが開発に着手できる状態誰か1人によってチームが成り立つ状態を回避できているのが柔軟かつスピーディーな生産を継続できると考えています。
話を戻します。
属人化の原因は、一貫性がないことだと考えています。
いくつか例を挙げると…
- 取り組みの終わったあとのファイルがそのまま
- 独創性が高まり過ぎたWordPressが更新できない
- 開発環境が複数あり、それぞれ仕様が異なっている（フレームワークが違うなど）
- CSSやJSファイルがまとまっていない
- 画像ファイルの管理がまとまっていない
- バージョンの古いライブラリが使われ続けている
- ABテスト用のディレクトリやファイルがそのまま残されている
などが挙げられます。
どれも一朝一夕ではどうにもならないものばかりで何から改善していけばいいのかわからない状態でした。
調査や実装に多大な時間がかかります。
抱える課題をどのようなアプローチで改善していくのか？を思考も合わせてこれまでやってきたことを紹介します。
複雑な環境をシンプルに
不要ファイルを消していくだけでも骨が折れるので、それはやるとしてその他にどんなことができるのかを検討と実行しました。
共通パーツを一元管理
グローバルナビなどの全ページで共通するパーツを編集するのに知らない人がやると1〜2時間かかってしまうような状態でした。
完全なパーシャル化は無理でしたが、.incファイルとして切り出してファイルの呼び出し元でincファイル内で利用する変数に値を代入しておくことで実現しました。
共通パーツをパーシャルのように呼び出せるようにしたかったですが、PHPのバージョンが古い＆フレームワークは利用していないため断念しました。
headerやfooterも一度に全ては無理でも徐々に管理を一元化しています。
CSSやJS（jQuery）のコードをどうにかしたかった
改修の頻度から考えてHTML、CSS、JS（jQuery）の改善から検討を始めました。
HTML、CSS、JSの修正で一番課題だったのがCSSです。
CSSは改修の頻度も多いので問題が発生する割合が高かったです。
CSSでどんな問題が発生していたかというと…
-
!importantによるオーバーライド地獄 - 詳細度MAXのセレクターが数えきれないほどある（idセレクター）
- CSS設計は導入されているが、スマホにしか展開されていない
- CSSファイルがいろんなところで保存されているので修正・追加カ所がわからない
- モジュールを別のモジュール内でオーバーライドしている
- 不要になったCSSが残っている
- 同じようなモジュールが複数存在している
などが発生していました。
CSSを変更すると想定していない表示不備が発生することが多くあり、開発工数を肥大化する原因になってました。
第1弾としてWordPressで使っているCSSを1つのファイルにまとめました。
それによって開発工数や新規でジョインしたメンバーへの教育工数を圧縮することに成功しましたが、古いページで表示が発生することになりました…。
詳細は下記にまとめましたのでよろしければご覧ください！
WordPressをやめる？
結論、実行によるメリットが小さいと判断してやめました。
プラグインを利用しないカスタマイズによってかなり複雑になっています。
それらを正しく動くように修正することや膨大な記事を修正する時間を考えるとコストがかかりすぎると判断しました。
開発体制やその後のことを考えたときにCMSのメリットを受けられる状態にしておいた方が良いという考えにいたりました。
jQueryをVanillaJSに置き換える
これまでできていなかった要素指定がquerySelector()によって簡単にできるようになったのでjQueryを利用するメリットも少なくなってきたと感じています。
全てを一度に置き換えることはできないので、少しずつ置き換えることによってVanillaJSで記述されている範囲を拡大しております。
これによって1.7系のjQueryを利用していたのを刷新するための糸口になりました。
jQueryを置き換えるためのTipsを記事にしているのでよろしければ参考にしてください！
使っていない仕組み、ファイルを思い切って消す
長年運用したサイトのファイルを消すのは至難の技です。
レガシーな環境だとファイルのアクセスログを確認することすら難しいためです。
99％大丈夫だけど、誰に聞いても100％の確信がもてないのが辛いポイントです…。
ディレクトリ内検索やGoogleAnalyticsで調査しながら慎重に削除していきます。
加えて、使っていない仕組みなどは容赦無く削除していきます。
しばらく利用されなくなっていたStyleGuideを全て削除しました。
重複してヒットする項目を減らすことができ、作業効率を下げている原因を減らせました！
webpackの更新
4年間更新されていなかったものを大アップデートしました！
詳しい記述方法を知りたい方は別の記事にまとめているのでよろしければご覧ください！
CSSのコンパイルをgulpからwebpackへ統一
webpackの更新に伴い、これまでgulpでCSSをコンパイルしていたのをwebpackに一本化しました。
JSのコンパイルとCSSのコンパイルが1つにまとまりコードがスッキリしたのはもちろんですが、管理するモジュールが減ったことで運用コストを下げられたことがよかったと考えています。
Lintが機能するように修正
これまでLintが機能していなかったのでwebpackのコマンドを実行したのと同時にESLint、Stylelint、Prettierが実行されるように修正しました。
運用はこれからですが、コードレビューで指摘していたインデントや引用符の指摘からはせずともよくなり、より本質的なレビュー体制を整えるための基礎を作れたと考えています！
Lintの設定については別記事にまとめましたのでよろしければご覧ください！
まとめ
これまで設定ファイルなども合わせると数百のファイル、20000行以上のコードを削除していきました。
それでも氷山の一角なぐらい不要なコードは残っています。
ただ、ようやくこれまで漠然としていた負債の輪郭を捉えられたような感覚です。
リファクタリングは大きく前進することはないと思っています。
絡まった糸を解くように少しずつ、それでも着実に良くなっていくものだと考えています。
出口はまだまだ先ですが、サービスの明るい未来のために明日もリファクタリングを続けます。
より良い未来のために一緒に頑張りましょう！
余談
リファクタリングは事業の数値には反映されませんが、重要なものだと考えています。
生産性が下がるだけでなく、関わるエンジニアのキャリアやモチベーション、採用活動にもマイナスの影響を与えると考えています。
コードの保守はマイナスを0にするもの、必ずしも必要でないことや事業の数値には現れないことが多いため残念ながら後回しにされることが多いです…。
私からできるアドバイスは、諦めずに伝わるまで根気強く発信してください！
私の後悔としては開発環境の状況について伝えることを放棄してしまったことです。
まずは上長に、周りのメンバーに話して状況を知ってもらうことから始めてほしいと思います。
1日でも早くレガシーなシステムやコードが解消されることを心から祈っております。