先日、技術グループで愚痴の投稿を見ました。投稿者は、プロジェクトのリリース前にツールでCSSを圧縮したところ、翌日同僚がスタイルシートを開いたら、画面一面がぎゅうぎゅうに詰まった文字だらけで、その場で怒り出したそうです。「これ誰が書いたの？人間が読めるものじゃない！」と。投稿者は、圧縮はビルドプロセスの一部で、自分にもどうしようもなかったと不満そうに言っていました。
この件は実に典型的で、ほとんどすべてのフロントエンドチームで議論になったことがあるでしょう。今日は、CSS圧縮後に同僚が読めない問題、この責任は一体誰が取るべきなのか、じっくり話しましょう。
まず、CSS圧縮が何をするものか説明します。要するに、コード内のスペース、改行、コメントをすべて削除し、変数名をできるだけ短くして、ファイルサイズを小さくし、ウェブページの読み込みを速くするためのものです。これ自体は悪くありません。本番環境ではパフォーマンスを追求するので、圧縮は標準的な操作です。しかし問題は、多くの人が圧縮後のファイルをそのままコードリポジトリにコミットし、元のファイルを上書きしてしまうことです。同僚がコードをプルすると、目にするのは「a{b:c;d:e}」のような暗号だらけで、混乱しないわけがありません。
では、この責任は誰にあるのでしょうか？圧縮ツールのせいだと言う人もいます。あまりに「乱暴」だと。しかしツールは無実です。それは単にコマンドを実行するプログラムであり、圧縮を指示されたら、とことん圧縮するだけです。包丁で野菜を切って手を切ったとしても、包丁が鋭すぎるせいにはできないでしょう。
同僚のせいだと言う人もいます。フロントエンドエンジニアが圧縮コードを読めないのは基礎力不足だと。これは少し無責任な意見です。圧縮後のコードはそもそもブラウザ向けであり、人間向けではありません。小説をモールス信号に翻訳して友人に送り、友人が理解できなくても、友人の国語力が足りないと責められますか？人間の通常の読解習慣は、インデント、コメント、改行があるコードであり、圧縮コードは人間の習慣に反しています。同僚に圧縮コードを無理やり読ませるのは、能力を鍛えるのではなく、苦痛を与えることです。
私の考えでは、本当の責任はプロセスと規範にあります。つまり、チームが「何をコミットすべきか、何をすべきでないか」を決めていないのです。正しい方法は、ソースコード（つまり人間が読むためのCSS）をリポジトリにきちんと置き、圧縮はビルド段階で自動的に行い、圧縮後のファイルはdistディレクトリに出力するか、リリース成果物に直接バンドルし、バージョン管理にコミットする必要はありません。しかし多くのチームは手間を省くために、または最初に考えが及ばず、圧縮ファイルもコミットしてしまい、問題が発生します。
「でも、会社が圧縮ファイルのコミットを要求する場合はどうすればいいの？」と言う人もいるでしょう。例えば、静的ホスティングプラットフォームや、バックエンドがリポジトリ内のファイルを直接参照する場合です。確かにそういう状況はありますが、解決策がないわけではありません。圧縮を独立したビルドステップとして、リリース前に実行するようにすればいいのです。コードを変更したらすぐに圧縮してコミットするのではなく。あるいは、pre-commitフックなどのツールを使って、コミット前に自動処理し、リポジトリには常に読める未圧縮バージョンが存在するようにします。方法は問題より多いものです。重要なのは、チームの誰かがリーダーシップを取って規範を確立することです。
もう一つ見落とされがちな点は、コードコメントです。多くのCSS圧縮ツールはデフォルトでコメントも削除するため、圧縮ファイルに手がかりを残そうとしても残せません。したがって、重要な、後で理解する必要があるロジックは、必ずソースファイルに書くべきであり、圧縮後も見えると期待してはいけません。これがソースファイルを保持することが重要である理由です。それはチーム協力の「本体」なのです。
結局のところ、CSS圧縮自体は悪いことではありません。悪いのは、それに伴う管理習慣が欠如していることです。同僚が読めないのは、彼が劣っているからでも、ツールが愚かだからでもなく、ワークフローに一部が欠けているからです。これは料理のようなものです。包丁は良い包丁ですが、食材をわざわざペースト状に潰してテーブルに出すなら、客が「見た目が悪い」と言っても、包丁のせいにはできません。
だから、このことで喧嘩するのはやめましょう。次回同じことが起きたら、堂々と「プロセスが未整備だった」と認め、すぐに規範を整えましょう。ソースファイルはリポジトリに入れ、圧縮はビルドに任せ、誰も圧縮成果物を直接コミットしないように。もし最初からそうしていたら、こんな責任を取る必要もなかったでしょう。つまり、技術的な問題の背後には、しばしば管理の問題があるのです。あなたもそう思いませんか？