BEMに関するこのあたりの考え方や期待感は、2014年でもう少し突っ込んで取り組みたい所存。Twitterへのツイートをブログ記事にする省エネ投稿。
似たような話として、以前書いたBEMに関する記事ではこういう表現をした。
例えばサーバーサイドやJavaScriptのエンジニアが仮にCSSの設計を把握していなくても、とりあえずBEMの命名規則を覚えてもらえればブロック単位で維持すべきだと理解してもらえるので、それだけでデザインを壊してしまうリスクを結構回避できる。また命名した本人であっても、半年経ってから見たらBEMの名前はわかりやすく見えそう。
他のコードに比べると、HTMLはより多くの人が編集する場所なので、HTML上に割り振られるID名やクラス名はそれ単体で「何のための名前か」「どういう構造か」「変更がどこまで影響するか」が可能な限り明快な方が良いと思っている。少し誇張して言うとCSSのためではなくHTMLのために命名する。そうすることでプロジェクトやチーム全体でのHTMLのメンテナンス性向上に繋がりそう。BEMのルールはそれに適しているかなと。
具体的にRailsプロジェクトで喩えて言うと、Railsエンジニアがfeature specを書く時に、把握しやすく使いやすいクラス名になっているかどうか。また逆に、CSSを設計した本人であっても、CSSのクラス名を変更したいと思った時に、HTML/CSS内だけでなく、自分が書いたコードではない前述のfeature specやRailsヘルパー、JavaScriptコードなどからも該当する部分を容易に見つけ出すことができるかどうか。そのあたりのフットワークが軽くなるように設計・命名することは、継続的に変更を加えていくWebサービスなどでは重視したほうが良いと思っている。少なくとも、スタートアップのような小規模なチームでは。
そのように誰からでもHTMLに変更を加えやすくした上で、ツイート最後に書いたように、破壊（意図しない変更）を加えてしまった場合にそれを自動的・機械的に検知できる環境がフロントエンドでも整えば、今よりももっと気軽に、誰にでも変更を加えられる状態にできるんじゃないかなぁと。RSpecやCapybaraなどを使っていると、そうなって欲しいという願望が強い。既にPhantomCSSのようなツールが出てきているので、これらが熟れてきて、既存のテスト環境と連携できるようになると、そういう状況を実現できそうな予感。