HTMLとCSSをコーディングしている人は、行数の多いコードになってくると、DOM構造だったり、classの命名だったり、selectorの煩雑さがカオス状態になってしまった経験があると思います。
これはJavascriptやPHPをプログラミングしていても同じ事が起きます。
個人的にエンジニアのスキルは作れるプログラムの大きさに比例すると思います。
MVCとFLOCCS
そして、ある一定まで行くと、どんなに大きなプログラムになっても淡々と書き続けていくことができるようになります。
そんなプログラミングの構造思考として、
MVCという構造設計指針がありますが、
CSSにも似たような設計指針として、
FLOCCSというのがあります。
MVCやFLOCCSの実際の内容については、検索するとたくさん出てくるので、Webコーディング、プログラミングをすると言う人で、まだ知らないという人は是非一度は学習しておいたほうがいいでしょう。
これらを学習して自分でコーディングして一周した人たちの中で、「これらの設計指針って、ちょっと使いづらくない？」と気が付き始める人達がいます。
かくゆう自分もそのタイプだったので、今回はFLOCCSに関して、もっとこうすればいい的な自分思考をまとめておきたいと思います。
FLOCCSの基本
- クラス命名ルール
- オブジェクト分類(Component、Project、Utility)
- ファイル、フォルダ構成
- DOM(HTML)構成
- Javascript構成
- scssを使う
とにかく、コーディングルールやソースファイルの階層構造などを十分に気を使って構築をするという事がよくわかります。
たしかにこれを徹底していればどんなに大きな構造体になっても対応ができるようなきがしますが、個人的に最も気に入らなかった点がscssを使わなければいけないという事でした。
あと、FLOCCSについて書かれているブログには、どれも「FLOCCSのデメリット（課題）」という意見が書かれていて、どの記事もほぼ同じ内容で、「オブジェクト分類が判別しづらい」とのことでした。
MVCでも同じ課題が言われ続けているので、この手のコーディングルール指針は、おそらく初心者の思考を育てるための指針なのではないかとも考えられる。
ここから自分なりのルールを構築できるといいんだと感じました。
※決してMVCやFLOCCSを否定しているわけではないんですよね。
FLOCCSの自分アップデート
まず個人的に思ったのは、scssはいいツールなのだが、仕事の現場によって使うか使わないかを限定されるので、こうしたツールは考慮しないネイティブコーディング思考で考えたいと思います。
Selector命名ルール
Javascriptも同時にコーディングしてwebツールを作ることが多い自分としては、Javascript連携で、data属性連携が多いというのもfloccsに足りていない思考だと思います。
なのでselectorに対するルールとしての大きなくくりにした方がいいんですね。
classルールは、floccsそのまんまでも問題ないと思います。
でも、アンダースコア２つやハイフン２つは、ミスがミスが起きやすい可能性があるので、個人的には１つルールが望ましいのではないかと・・・
Element_Group-Modifire-additional
こんな感じで、それぞれのカテゴリルールがそろっていれば、おおよそ見やすいclass名になるはずです。
※大元のstyle.cssなどの冒頭にコメントでルールを丁寧に書いておくなんて言うのも非常にいいコーディングですね。
data属性に関しても似たようなルールで行えばいいかと思います。
data-Group-Modifire-additional
ファイル・フォルダ構成
これは、実は使用するフレームワークや、独自構築する階層構造に依存してしまうので、FLOCCSルールに従うことは厳しいと考えているため、次のようにルール化します。
個人的に使っているフレームワーク（自作したもの）では、webページ単体で管理できる構造のため、Webサイトの共通パーツと、個別ページの内容をフォルダで分けます。
次のような不フォルダ構造になっています。
Root/
├ assets/
│ ├ css/
│ ├ js/
│ └ php/
├ datas/
├ pages/
│ ├ index/
│ │ ├ css
│ │ ├ js
│ │ ├ php
│ │ └ index.html
│ ├ contact/
│ └ system/
└ index.html
上記の構成のcss/フォルダの内容をそれぞれしっかりと構築していくことになります。
多くのフレームワークはcssフォルダを単一化して、その中でサイト構造を作るようになっていると思いますが、実は上記の方式のほうがその後の修正や追加などの対応がやりやすいことに気が付き現時点では、この構造で構築することが多くなりました。
そして、cssファイルは基本的にstyle.css、javascriptは、main.jsを読み込むとその後はそのフォルダ内で独自に構成していくようにしています。
これでやると、似たようなページはコピペで作れてしまうし、ルール化するのも大規模になってもほぼ同じルールが適用できるので便利です。
あとがき
最近１ヶ月内に４つや５つのシステムやサイトを構築するお仕事を受けることが多くなってきたため、そろそろ一人では厳しいと感じ始めています。
他の人と同じ効率で作業を進めたければ、こうしたルールは必須になってくるし、もしかしたら、その後にもっと効率的な思考が生まれるかもしれません。
個人的には、好き嫌いという判断方法ではなく、より効率的を追求した思考で現在のルールに行き着いているので、もう少し細かなところまでルール化できたら、フレームワークとしてOSS化してもいいかもしれませんね。
こういう話が好きなエンジニア、学習してもっと自分のスキルを伸ばしたい初学者の方などいたら、是非お話しましょう。
0 件のコメント:
コメントを投稿