CSSがすごいことになっている。私はそう感じながらも業務に従事しておりました。
少しは改善できたと思う現時点でもCSSはすごい状態です…。
ある時、WordPressで管理されているCSSを1つに統一しました。
統一したことで問い合わせの時間が圧倒的に少なくなり、開発効率は上がったと考えています。
CSSを統一して良かったと考えていますが、段取りや実行方法は改善の余地があったのではないかとも考えています。
【こんな方にオススメ！】
・CSSがすごいことになっているのでどうにかしたいと考えている方
・CSSのリファクタリングしたくて、具体的な方法を思案している方
CSSのリファクタリングを事故なく終えたい方のためのヒントになれば嬉しく思います。
当時の状況を共有
長年のサービス運用でCSSはすごいことになっていました。
【すごいことになっているCSSの例】
- ルート階層にあるCSSフォルダで管理されているもの、個別のディレクトリで管理されているものなど管理方法に規則がない
- PCとSPで同じ要素でも実装方法が異なる
- gulpでコンパイルされたファイルも利用されている
- 開発環境が複数あり、基本スタイルは一緒なのにCSSファイルは別で管理されている
- SPだけにCSS設計が入っている（PCはSPの設計に沿って実装しているだけの雰囲気実装）
- ファイル間でのオーバーラードによる、!important地獄
- 統一されていないマージンルール
- radiusにもベンダープレフィックスが付与されているぐらい更新されてないCSSたち
- 詳細度が高すぎるCSSが多すぎる（idセレクタ、ネストの深いセレクタ）
- ときおり登場するインラインスタイル
- 度重なる改修でネームスペースがなくなり命名するのに10〜20分かかる
- 管理がバラバラのCSSファイルが同じHTMLファイルで読み込まれスタイルが競合している
一言で「苦しい…」につきる状態でした…
それでも施策のリリーススピードは落とせない状況の中、多くのフォロー工数を要しました。
【フォロー工数とは】
問い合わせに対する対応やコードレビュー、実装の相談がフォロー工数にあたります。
特に多い問い合わせは「ファイルがどにあるのかわからない」「CSSが反映されない」が当時の2トップでした。
なにをしたのか？
冒頭でも話した通りWordPressで管理されたページのCSSを1つにまとめました。
複数の開発環境があるうちの1つにWordPressが入っており、他の環境と同じスタイルを使っているのにもかかわらずCSSは別管理しているため問い合わせが横行していました…。
CSSのファイルを1ヶ所で行うことで修正ファイルが明瞭になり、スタイルの競合をなくしました！
具体的に実施したこと
CSSを1つにまとめるのは予報もなく作業と確認に時間がかかりました。
大きく2つのタスクがありました。
- 数百ページある記事で使われるCSSを移管すること
- まとめる先のCSSと競合しないように調整すること
CSS移管と調整の手順
CSSの移管や調整は膨大な作業でした。
作業を社員2人、確認など微調整を私1人で実施したら1カ月ほどかかりました。
※その間別の優先度の高いタスクを実施しながら少しずつ進めたためです。
詳細な手順
- アクセスログやGoogleでインデックスからページを洗い出し確認するページをリストアップします。
GoogleAnalyticsで流入が上位100の記事を参照し、確認範囲を決めました。 - PCとSPでデザインが異なるため全てのページで両方のデバイスを確認します。
- 漏れがあれば元ファイルからCSSを移動、調整します。
- 手順の2と3を繰り返し行い、修正漏れがないように完了させていきます。
CSSの移管と調整はなにをしたのか？
CSSの調整では以下のことを実施しました。
- 「!important」の削除
- classの読み込み順の入れ替え
- ネスト記法に直す（scssファイルにしたため）
- セレクタを短くする
全てを完璧に実施できたわけではありません。
時間の都合上、ネスト記法に直せなかったところもあります。
idセレクタをそのままにせざるを得ないところもありました。
それでも散らばるCSSが1つにまとまったことは自分の業務だけでなく、新規にジョインしたパートナーやアルバイトに対しての説明や問い合わせは少なくなりました！
対価として表示崩れとどえらいファイルが誕生
本当にやって良かったと今でも思いますが、**対価として、「表示崩れの発生」＆「どえらいファイルの誕生」**を余儀なくされました。
表示崩れの発生
流入が多い上位100記事ほどを確認していたため、流入の少ないページや主要ページの一部コンテンツで表示崩れが確認されました。
全てを漏れなく確認することは可能だったのか？は疑問に残るところですが、発生させてしまったことに違いはありません。
【教訓】
使われている膨大なCSSのセレクタを修正する場合、ページが膨大であるほど漏れなく確認することは難しくなります。
表示崩れを起こさないようにするには時間がかかりますが、新しいファイルを作成し対応範囲を広げていくのが安全で確実です。
CSSファイルをまとめる場合は下記の方法を検討していただきたいです。
- 新しくファイルを作成して、現在利用しているCSSファイルと並行で管理できないか
- 少しずつ対応範囲を広げることはできないか
どえらいファイルの誕生
結論からい言うと、10000行を超えるCSSファイルができてしまいました…。
予想していないほどの量を移管することになってしまいました。
CSSが膨大な量になっている原因
- 重複スタイル（オーバーライドも服も）
- 現在では不要なベンダープレフィックス（radiusなど）
- 不要になったセレクタや統合できるセレクタが多数ある
調査に時間がかかるため、調査できず判断なしに移管したセレクタもたくさんあります…。
さすがにサイトパフォーマンスにも影響するほどの量だと考えています。
ただ、1つのセレクタを削除するのに膨大な検証時間が発生するため、調整が止まってしまっています…。
【おまけ】最近Scriptもリファクタリングを始めた
CSSのリファクタリングには長い時間がかかることは説明させてもらったとおりです。
それと同じぐらいScriptのリファクタリングも大変です。
Scriptのリファクタリングは下記の方針で進めています。
- jQueryの脱却
- 処理の最適化
- Scriptを一元管理
と思ったのですが、4年ほど更新されてなかったwebpackまわりの修正が必要でした…。
webpackの更新で2つのことができるようになりました！
できるようになったのは下記の3点です。
- JavaScriptとjQuerを含んだScript2つを分けてコンパイルできるようになった
- CSSのコンパイルをgulpで行っていたのをwebpackで統一できた
- gzip圧縮できるようになった
新しいバージョンにすることでできることが増えるのは素晴らしいですね！
これまで複雑だったコンパイルコマンドがスッキリするなど設定ファイルもリファクタリングできたので良かったと考えています。
まとめ
リファクタリングしてわかったことは、目的を果たす以外のリファクタリングはしないが鉄則だということです。
レガシーな運用歴が長いサービスの場合はありがちだと思いますが、リファクタリングを始めると考えていた以外のところで調査や修正が必要になり、その度に時間を奪われます。
直接関係ないところはメモを残して次に進んでいくのが鉄則だと考えています。
また、レガシーな環境ではリファクタリングの終わりは遠く先になると思います。
この先半年、1年にとって最良の選択になりえるのかを十分に思考してから優先度を決めて取り掛かってもらいたいと思います。
私はまだまだ道半ばです。
ただ、少しずつ新しいものに置き換えられている実感を持っています。
lintを新しくする、JavaScriptで実装されている範囲を増やすなどサービスの安定運用と開発者の体験を上げるためにこれからも尽力したいと考えています。
この記事がリファクタリングする開発者の励みやヒントになれば幸いです。
そして、皆様が良いリファクタリングができることを願っています！