プロダクトエンジニアリング部のえびさわです。
この一年でLIFULL HOME’Sのメイン開発サーバーのフロントエンド環境が大きく刷新されました。
以前は使えなかったSassも導入され、モリモリとDXが向上しております😭
今回はマークアップにフォーカスし、刷新前に感じていた課題とSass導入後に行なった改善策をご紹介します。
課題
カラーコードのtypo, 種類が多い
LIFULL HOME’S にはデザインガイドラインが存在し、使う色はある程度パターン化されています。
代表的なもので言うと弊社のコーポレートカラーでもある #ed6103 です。
CSSしか使えない場合、カラーコードは手打ちないしコピペするしかありません。
しかし、以下のような微妙な違いの場合はデザイナー・フロントエンドエンジニアともにレビューで見落とす可能性があります。
デザイン的にあえてずらしているのかtypoなのか、あとから開発している人間にはわかりません。 「すでに実装されているものだから正だな！コピペ実装したろ！」とかやっちゃうともう地獄です。秩序が崩壊します。
また、似たようなカラーコードも多いです。 例えば以下の図はすべて同じページで使われているグレーです。
特に #fafafa ~ #f5f5f5 は激戦区かつモニタ輝度によっては真っ白にしか見えないので誤実装が発生したり、
雰囲気で色を当ててレビューまで持っていってしまうことがあります（大抵デザイナーさんにしょっぴかれます）
同じスタイルのcssが大量にある、コピペが大変
LIFULL HOME’Sはモジュールという単位で各コンポーネントを管理しており、 それぞれ HTML + CSS (+ JS) が1セットになっています。
こちらの図は実際に使われているモジュールです。 少しわかりにくいですが、「物件の費用目安を見る」「お気に入りに追加」「シェア（LINE/メール）」の3モジュールに分割されています。
これらはボタンの見た目は同じですがHTML/CSSは完全に別となっており、いずれかのCSSを変更してもスタイルが同期することはありません。
そのため影響範囲を最小限に止めることができ、大規模開発においては大きなメリットとなっています。
一方で似たようなデザインでコンポーネントを作成する際はCSSも丸ごとコピペする必要があります。
その際に微妙な差異を生み出してレビューを通過してしまったり、UIリニューアルの際に大量のファイルを更新しないといけないなどのデメリットもありました。
「ここで実装されているやつと同じで」がしづらい
前述の通りLIFULL HOME'Sでは殆どの場合再利用性のあるコンポーネントは作られず、独立したモジュールになっています。
似ているけれど微妙に見た目が違うモジュールが存在していたり、インタラクションが異なったりしています。
歴史の長さ・開発者の多さ故にすべてを制御しきれておれず、どれが正なのかがわかりません。
そのため、「ここで実装されているやつと同じで」と言われても他のモジュールの方が正しいのでは…？と疑心暗鬼になりがちです。
改善策
共通変数・mixinの導入
まず「カラーコードのtypo, 種類が多い」に対して共通変数を用意しました。
変数を使うことによってtypo防止・色のリスト化が行えるため、野良色の発生を抑止できます。
命名は ${$prefixColor}-{$uniqueName} としています。
prefixは上記のカラーサークルに近いものを選び、uniqueNameはHexColorを参考につけています。
たとえば #d8d8d8 であれば $mono-gainsboro といった具合です。
名前がユニークすぎて色が想像できない、というのがデメリットですが $red-default , $red-lighter などの命名は中間色が来た場合が辛いですし
将来的にどんな色が追加されるかもわからないので、命名被りが起こらないことを重視しています。
また、UIでよく出るElements( background , border , box-shadow )は専用のcolor aliasを用意し、実装時にブレが出ないようにしています。
map-gettersの利用も検討しましたがタイピング量が増える割には恩恵が少なかったので、$bg-xxx など専用prefixをつける形で落ち着きました。
また、「同じスタイルのcssがたくさんある、コピペが多い」についてはmixinを作成しました。
この図のボタンについては以下のmixinで解決できます。
// mixin
@mixin white {
border: 1px solid #d8d8d8;
border-radius: 4px;
box-shadow: 0 1px 1px rgba(0, 0, 0, 0.3);
font-weight: bold;
}
// 使用時
@use 'path/mixins/buttons' as buttons;
.mod-meyasu {
&__button {
@include buttons.white;
text-align: center;
padding: 12px;
}
}
余白はあえて設定していません。
というのもボタン内のレイアウトパターンは無数のようにあり、強い制約も設けられていません。 使う場面によって全く異なるルールのため、mixinではスタイリングのみ提供するという形をとっています。 （引数で設定も検討しましたが、指定し始めるとキリがないのでやめました）
当初はごく一部の変数とmixinのみ提供していましたが、数ヶ月に一度のペースでアップデートを行い対応範囲を広げています。
スタイルガイドの導入
共通変数・mixinの可視化
共通変数・mixinを導入しても、使ったらどんな見た目になるかは自分で当ててみないとわかりません。
そこで、開発サーバー上にスタイルガイドを作成して共通変数・mixinをビジュアライズしました。 Usageに従ってコピペすればすぐに使えるため、実装時のブレも抑制することが可能です。
スタイルガイドに載せているものは実際に運用されているコンポーネントがベースになっていますので、どのスタイルが正なのかという指針にもなります。
そのため、「ここで実装されているやつと同じで」がやりやすくなります。
アクセシビリティに関する実装ガイドライン
また、Sass導入の文脈とは異なるのですが実装時の諸注意としてアクセシビリティに関する内容も記載しました。
LIFULL HOME'Sではアクセシビリティに関するコーディングガイドラインが存在せず、雰囲気で実装しているところがありました。
長年可動しているが故に最新の対応が出来ているところも少なく、以前の実装をそのまま流用してアクセシビリティが壊滅的……なんてこともあります。
そこで今回スタイルガイドにガイドラインを表記し、実装例を併せることで正しいアクセシビリティ対応をできるようにしました。
導入してみて
実装が爆速になった
全世界で500億回は言われていることだと思いますが、本当に実装が速くなりました。
今まで手作業で数行〜数十行書いていたものが1,2行で書けるようになったため、 ちょっとしたモジュールであれば一瞬で組めるようになりました。
変数・mixinが頭に叩き込まれているか否かで実装速度は前後しますが、 スタイルガイドの存在によって差は埋めやすくなっているとは思います。
レビューも楽になった
これも5000億回は言われていると思いますが、 レビュー時にスタイリングが正しいか否かに心血を注ぐ必要がなくなり、 他の事項に集中できるようになりました。
デザイナーさんとの意思疎通がしやすくなった
LIFULL HOME'Sは施策の規模によってはデザイナーさん無しで開発を進め、 フロントエンドエンジニアが組んだものをデザイナーさんにレビューしてもらいリリースする、ということがあります。 そういった場合に「この色とこのパーツで」とざっくり相談ができるので、意思疎通が楽になりました。
おわりに
Sass導入前に苦しんでいた問題が緩和され、大変快適なマークアップライフを送れるようになりました☺️
10年以上運用されている大規模サイトのためどこまでSassで対応していくかが大きな悩みでしたが、 周りのデザイナーさんやエンジニアさんに助けられ対応範囲を広げていくことができました。 この場を借りてお礼申し上げます🙇♂️🙇♂️ありがとうございました
引き続きアップデートを行い、より良いマークアップ体験を提供できるよう努めて参りたいと思います！
