2013-07-01 21:06:15 +0900
CSSの記述・管理スタイルをどうするか考え中。まだこれといった結論は出ていないので、この記事は単なる覚え書きです。
ここ1ヶ月ほど、qnypの開発をデザイン面で支えてくれている@ruedapさんと、
- CSSのスタイルガイドを何でどう作るか(今のところKSSが有力候補)
- BEMやSMACSSが提唱している命名規則は実作業においてどんなメリット・デメリットがあるか
- レスポンシブなグリッドフレームワークは何を採用するのがいいか(候補はSusy、Bourbon Neatあたり)
- DOM要素にスタイルを適用する際にid/classをメインに使う(OOCSSアプローチ)か、要素名をメインに使うか
みたいなことを延々とやり取りしています。
その過程で、そもそもの問題の根幹についてちょっと思いついたことがあったので、いくつかツイートしてみました。
CSSの構造やメンテナンス性にまつわる問題は、技術的な解決策よりもチーム規模やメンバーの協調の仕方で解決する要素が大きいように感じてきています
— Junya Ogu®a (@junya) June 30, 2013
マークアップやスタイルを追加・変更する際、1)少数のデザイナーがそこを統括して一貫性を保証する、2)プログラマーも含めた開発チームメンバー各自が見よう見まねで手を出して徐々に破綻していく、を両極としたアプローチがある気がする。
— Junya Ogu®a (@junya) June 30, 2013
後者を防ぐためにルールを明文化するのが今のトレンドだけど、多分、前者のやり方でまわる規模のチームを維持してビジネスを成立させるのが一番かしこい気がする。
— Junya Ogu®a (@junya) June 30, 2013
プログラマーの割合が多いチームだと、いちいちデザイナーに確認・チェックを依頼するのも大変だろうし、チームビルディングがうまくいっていなかったり雇用形態が異なるメンバーを含んでいたりすると、そもそもそういう交流も起きづらかったりして、人知れずHTML/CSSが腐ってく。
— Junya Ogu®a (@junya) June 30, 2013
データベースにおけるDBAみたいな感じで、HTMLとCSSにもAdministratorを置くといいのかなあ。
— Junya Ogu®a (@junya) June 30, 2013
プログラマー中心のチームでもHTMLやCSSのコードレビューを積極的にやるべきかもしれない
— Junya Ogu®a (@junya) June 30, 2013