本付録は、メインシリーズであるWordPressのテーマ作成に役立ちそうな情報を補足していくパートだ。
前回は前々回から引き続き、8つの考え方の最後一つである拡張しやすいという部分を解説した。
これで8つ全て出てきたが、まだ実感が湧かなくても大丈夫だ。
次回以降で具体的な手法を紹介する予定なので、それを通してそれぞれが何を言っていたか確認していこう。
以下がその記事だ。
さて、今回はもう一つ、設計手法の前提となる話をする。
以前の中で軽くモジュールという単語を紹介してそのまま使っていたが、そこの部分を深掘りしていこう。
まずはそもそもモジュールって何だろうかという部分を改めて定義し、その後このモジュールの粒度をどう決めるか考えていく。
この粒度は設計手法によっては明確に定義されているもがあったりなかったりするが、やはり共通して考える必要があることには変わりない。
もちろん、具体的な考え方も前回までと同様実際の設計手法で身に付けてもらえれば大丈夫だ。
今読んで分からない、となっても不安にならないでほしい。
なお、本付録は以下の本を参考にしている。
気になる方は、実際に本屋で中身を見てみたり、買ってみたりしよう。
改めて、モジュールとは
さて、まずはここから。
モジュール(module)という単語を調べてみると、意味としては部品と出てくる。
もうほぼそのままの意味で、今回で言うモジュールとは、様々な場所で使いまわすことのできる一部分のことだ。
これを使うことで、同じ部品を複数個所で使ったり、あるいは移動させたりなんかが楽になるよ、ということだ。
なお、前回までの具体例では分かりづらいが…あるモジュールは、他のモジュールを含むこともできる。
次の粒度の話では、それを前提としているので覚えておこう。
モジュールの粒度
使いまわせるのはいいが、どの単位までをモジュールと呼べばいいのだろうか。
これは、考え方によって異なるだろう。
確かに、同じものは使いまわしたいというのは多くの人にとって共通の認識だ。
しかし、じゃあどこまでが一つのモジュールなのか、という部分は人によって変わってきてしまう。
例えば、ボタンが入ったメディア領域。
前回までのサンプルの中に、ボタンが入っているところを想像してみよう。
この時、捉え方としては以下二つが挙げられるだろう。
- メディア領域全体を一つのモジュールとする
- ボタンのモジュールが入ったメディア領域のモジュールとする
前回までの内容を思い出してもらうと、この二つの捉え方によってクラス名が変わってくるのが分かるだろうか。
前者で捉えたとすると、例えばボタンのクラス名はbl_mediaButtonのようになるかもしれない。
しかし、後者で捉えればこのボタンも一つのモジュールなので、bl_buttonとかになるだろう。
で、これが例えば一人で作っているのであればどちらか一つに統一されるはずなので、そこまで大きな問題とはならない。
ところが、二人以上で作っていて、その中に認識が違う人がいたらどうなるか。
それぞれがそれぞれの捉え方で設計するので、ある部分は全体を一つのモジュール、またある部分はモジュールを含むモジュールの形で実装してしまうことになる。
こうなると、またしても地獄の完成だ。
そのため、前提として複数人数で作る場合には、明確にどの単位をモジュールとするかを決めておく必要がある。
モジュール粒度の考え方
では、どうモジュールの単位を決めていくか。
これには、残念ながら常に最適な答えというのはない。
どんなページを作りたいか、どんな設計手法を使うかなどの要因によって、最適な考え方も変わってくる。
じゃあお手上げかというと、そんなこともない。
やはりこれにも共通した内容があるのだ。
参考書の記述を引用しよう。
ただし筆者の経験上最低でも
CSS設計完全ガイド ~詳細解説+実践的モジュール集
・最小モジュール……ボタンやラベル、タイトルなどのシンプルな要素
・複合モジュール……いくつかの子要素をもつ、ひとかたまりの要素
というふたつの単位を強く意識することをオススメします。
このように、最小単位でそれ以上分けられないような部分を意識するといいようだ。
これを基に、先ほど例に挙げたボタンを含むメディア領域を見てみよう。
すると、ボタンはそれ以上分けられないので最小モジュールになる。
他にもタイトルや本文があり、それらをまとめて複合モジュールとしてメディア領域が構成されることが分かるだろう。
また、幾つかの記事を並べているようなリストで考えてみる。
このリスト全体もやはりモジュールなのだが、そのリストに含まれる記事一つひとつも独立したモジュールであると考えられるだろう。
その記事一つのモジュールも、さらに細かい単位のモジュールに分割できることだってあると思う。
このように、それ以上分けることができるか、という観点でモジュールを考えていくといいようだ。
なお、例えばPRECSSなど、具体的にどんな部分を一つのモジュールとするかが定義されている手法もある。
それを使う場合は、やはりそれに合わせて分解していこう。
おわりに
今回は、モジュールとその粒度について解説した。
ちょっと短くなってしまったがやはり重要な箇所なので、そこも考えなければいけない、という部分はしっかり把握しておこう。
次回から、いよいよ具体的な設計手法を紹介していく。
まずは、OOCSSというものから見ていこう。
前回まで見ていた8つの考え方との関連も提示するので、そこと結び付けて理解していきたい。
2021/3/15追記
次回の内容、OOCSSを解説した。
具体的な設計手法、と言いながら実際はこれも前提知識のようなもの。
これ単体で使うことはあまりなく、他の設計手法にこの考え方が取り入れられている、というイメージだ。
小規模であればこの内容だけでもいいかもしれないが、実践に向けてその後解説する他の設計手法も理解しておきたい。
オマケ：改めて考えるCSS設計の必要性
さて、ここからはちょっとオマケで、CSS設計がなぜ必要かをもう一度考えてみよう。
前々回から今回まで、3回にわたって基礎となる考え方を書いてきた。
しかし、それを見ると考えることが多く、余計に複雑になっているように思われるかもしれない。
…ぶっちゃければ、CSS設計が不要な状況だって存在する。
例えば、1週間限定で公開する、1ページのみからなる特設ページ。
それっきりだと分かっているし規模も小さいので、ここまで色々考えて組む必要は正直ないと思う。
ところが、今度は100ページを超えるような中規模以上のサイトを作るとなったとき、しっかり設計しておかないと必ずと言っていいほど地獄を見ることになるだろう。
そのため、CSS設計はしっかり、それこそやりすぎではないかレベルまでやっておくと後々楽になる。
ちなみにだが、いきなりそんな中規模以上のサイトでCSS設計をしようとすると、今度は何を考えて設計すればいいかが分からなくなる。
だから、まずは小規模な、それこそ1ページのみのような規模からしっかりやってみるのがいいだろう。
私自身も、このシリーズを通してまずは軽めにやってみて、感覚を掴んでからWordPress側の設計をするつもりでいる。
その際は、過去のシリーズで出したサンプル、具体的にはこれを直してみようと思っているので、もし参考になれば幸いだ。
コメント