FLOCSSを書き始めて思ったこと
HTMLのレスポンシブ対応やsass形式で作ったサイトを
FLOCSSのCSS設計で書き換える際に使った外部情報や
感じたことを、備忘録としてまとめます。
FLOCSSとは何か？
FLOCSSは、CSS設計の一種で、これまで使われてきた
様々なCSS設計の思想のいいとこ取りをした手法であり、
現在も多くの現場で使われているそうです。
しかし、求人サイトを巡回して色々なWEB制作会社の制作実績や
企業自体のホームページのソースを見ましたが、このFLOCSSを
100%完全に採用しているWEBサイトは見つかりませんでした。
その一方で、部分的な命名規則は一部使われていたり、
クラス名の命名規則が似通っていたりということはあるので、
明確にここまでが規則、という境界線は引かれておらず、
現場次第で曖昧なものであるという印象があります。
恐らく、FLOCSSをガッツリ採用するのは、
外部非公開の大人数で開発する中規模以上のWEBサービス、
社内ITシステムの開発現場ではないかと予想しています。
（予算がより多く、納期が長く、エンジニアが入れ替わり
保守性がより重要になってくると思われるので）
FLOCSSはどうやって導入するのか
実際の現場では、FLOCSSの設計記法に最初から則って
CSSを書いていく形ではなく、適当な要素名を当てて
WEBサイト自体の全体の形を先に完成させてしまい、
後から修正をしていく流れが多いそうです。
なので、これに沿って自分でWEBサイトを作ろうとした時も、
まずはとにかくサイト自体を完成させることを優先しました。
次に、その既存のCSSをFLOCSS方式に
書き換えていくのですが、実際に自分で一通りやってみて
注意すべき点だと感じた事は、３つあります。
1.階層の順番に沿い、上から下へと書いていく
FLOCSSには、大きく5つの階層があり、
・Foundation
・Layout
・Compornent
・Project
・Utility
という順で連なっている層だと考えると、
上の階層のCSSで組んだサイトの部分に、
下の階層のCSSで組んだサイトの部分を
積木のように積み上げるような仕組みになっています。
図に表す場合は以下の記事先の画像が参考になります（かわいい）
CSS設計の概要の説明を受けた段階では
やることが膨大に感じるので、
一体何からやればいいんだろうと最初は思いますが
一つ一つ分解して考えれば
・Foundationに該当するCSSを上から下まで書く
・layoutに該当するCSSを上から下まで書く
・共通化できそうな部分をCompornentとして書く
・それ以外の部分は基本Projectとして書く
（CompornentとProjectは行ったり来たりする）
・細かいちょっとした部分のCSSはutiltyとして書く
これらを一つ一つ、上から下までやっていく、
今までやってきたことに比べると、機械的な作業です。
時間はかかりますが、WEBサービスの中身作りに比べれば
想像が全くつかない要素は少ないので、最初は面倒ですが
コツコツやれば、やっただけ確実に手応えがあるので、
PHPで何かを実装する事に比べたら精神衛生上は楽です。
ちなみに、現場の方々のCSS設計の初体験記を読むと、
一番多かった悩みが、CompornentとProjectの分類が
わかりにくい、曖昧であるという点です。
Compornent
モジュール単位
固有の幅や色の機能を持たない（共通化できる要素）
Project
基本はProjectで、繰り返される要素をcompornentとして切り出す
コンポーネントの方が上の階層
命名ルールは
「親となる要素__子要素—要素の変化した状態」
が基本の型です。
「子要素単体が階層で複雑になっている場合はどうするの？」
など、よく分かっていない部分は多いですが、
著者の方も、教材の中で唯一の決まった形は無いとか、
とりあえず困った場合はprojectに分類しましょう、
という旨を明言しており、今はそれを参考にさせてもらっています。
・FLOCSS公式ドキュメント
・芝犬のFLOCSS
あとはひたすらググって、書いてみて、
反映されるかどうかを確かめて、修正して…を
ひたすら延々と繰り返していました。
正直、細かい所まではよく分からないので、
一度一通り書いてみた今は、これ以上自分で悩むよりも
実際に書いたコードを現役の方に対価を払って
見てもらおうと思います
2.バックアップを取った方がいい
後から書き換える際にかなり難航するので、変更をする度に
画面表示を確認すると、思った以上に構成が崩れます。
自分は変更前のクラス名と変更後のクラス名を
毎回エバーノートに一つずつ貼り付けておき、
完全に書き換えが完了したら次へ、と慎重に進めました。
実際の開発現場や卒研でこの調子では日が暮れるので、
最初にHTMLとCSSを組み上げる時点で、変更しやすいように
命名を工夫しておいた方が書きやすくなると感じます。
もしくは、1機能書き換える毎に
都度gitに挙げて更新した方が良かったかもしれません。
後から変更前の状態に戻せるようなので。
それから、ゆるおじさんという方が以前Twitterで書いてましたが、
僕は実務に出るまで「コードレビュー」ってのをしてもらったことがなかったんだけど、独学してる人は変な癖がつく前にお金払ってでもコードレビューしてもらった方がいい。
— ゆるおじ@フロントエンド1年目 (@yuruoji) February 19, 2020
特にフロントの人はコードめちゃくちゃでも見た目だけそれっぽいもの作ることは出来ちゃうから危ない。
仰る通り、今の段階でどれだけ頭を捻っても
我流の変な癖が付きそうな予感がプンプンしているので、
MENTAを使って早めにコードレビューを受けようと思います
今は、現場に早く入りたい気持ちが日増しに強くなっています。
4月5月にガッツリ求人を漁って再び面談に臨みますが、
同期メンバーで現場に入っている人達の業務日誌を読むと、
1日8時間以上金を貰いながらコード書く環境に入らずに
どうやって追い付くんだろうというのを、今更ながら感じています
3.入れ子構造でCSSを書かないと死ぬ
例えば、以下のような画像、
お問い合わせフォームのCSSを当てる際ですが
・「お問い合わせ」の部分
・電話番号の部分
・営業時間の部分
・ボタン画像の部分
でそれぞれ、４箇所にCSSを当てる命令があります。
「よし、これまでheader-contact〜だったけど
今からp-header__contact--XXXXX という名前で統一しよう！」
となると、4箇所全てのCSS、4箇所全てのHTMLを
手入力もしくはコピペで変更する必要が出てきます。
まだ4箇所くらいなら何とかなると思いますが、
これが仮に10箇所20箇所の手作業になると、
どこかでうっかりミスをしたり、1箇所2箇所だけ
変更すること自体を忘れてしまう可能性は
十分に考えられます。
すると、仮に画面上の表示が崩れてしまった場合、
最悪の場合、その20箇所を一つ一つ目視で追って
間違い探しをしなければならず、結構な戻り時間が発生します。
ですが、sassの入れ子構造で、一番親の部分である
先頭のクラス名が変わった際、それに他の部分が追従する形の
CSS構造を最初にガッチリ組んでおけば、急なクラス名の変更や
まとまったパーツを丸々別の場所に引っ越す作業の際に
ミスや戻り作業が出る可能性を大幅に減らすことができます。
なので、sass形式でCSSを書くメリットは、
何故こんな面倒なことをやるんだろうと最初は思いましたが
使わないリスクの方が相当大きいだろうなと感じました。
逆に、個人で完結する仕事、短納期で完成まで短い仕事、
客先に一度納品してその後のメンテがほぼ必要ないサイトは
ここまでやらなくていいような気がします。
いずれにしても、現場に入らないと分からない事なので
この辺の詮索は程々にして、フレームワークのアウトプット、
来月からの面談に向け、引き続き取り組んでいきます
追伸1：
コロナの影響はかなり長引きそうなので
今後半年から一年にかけて、多くの会社が
求人や外注に回す予算をかなり絞ってくると思います。
仕事を探している人は、
早めに動き出した方が良さそうです。
追伸2：
CSSの名前を「親要素__子要素—変化」のテンプレに沿って
書き換えると、それだけでCSSが一切効かなくなる現象が
色々な箇所で発生しましたが、原因が全く検討がつきません。
今後もサイトを組む機会は何度かあるので、
今度は最初からこの記法に沿って組み上げていき、
何が効かない要因なのか切り分けをしてみようと思います。
レビューを受ける機会が先に来れば、
真っ先に確認したいところです
