入社時からHTMLとCSSをコーディングする際は「汎用性高く作るべき」と教わり、認識と命名ルールの統一・再利用しやすい構造・細分化など汎用性を意識してコーディングしてきた。こうすることで別のエンジニアが作ったパーツも自分のもののように扱え、コーディングが楽になると考えていた。しかし、意識しようが他人が作ったパーツはあくまで他人のもので、テコ入れなしでは怖くて使い回そうとは思えない。
「怖い」というのは、ブレイクポイントごとにどういう挙動をするのかわからないから怖くて使えない、という意味だ。これは他人が作ったからであり、理解するためにはCSSを読まなくてはならず、それでは1から作るのと変わらない。結局は誰もが読みやすい汎用性の高いコードを書いても、他人が作ったものをそのまま使い回してページを構築する気にはなれない。強いて言うのであれば、恩恵を受けるのは作者以外がプロジェクトを引き継いだときに理解しやすい、という点くらいだ。
例えばJavaScriptであれば、頻繁に使う関数を毎度作るのも時間の無駄なので、特製のライブラリを構築する取り組みを行っている。プロジェクトで作った関数を各々ライブラリに登録していくという無理のないスタイルで取り組んでいるが、実際に取り込んで使える実用的なものとなっている。ここに登録されるようなJavaScriptの関数は数値型やストリング型など決まった値を返す約束がされている。だから、誰が作ったものだろうと使い回すことができる。一方でHTMLとCSSのパーツは何か値を返すわけでもないし、コードを見ないと全容を把握しきれないから使い回しづらいのではないだろうか。
ここまで来るとまるで「汎用性を意識したコーディングは無意味だ」と考えているように捉えられるかもしれないが、そうではない。私が思うのは将来のことばかり考えて「汎用性の高さ」に工数をかけ過ぎるのは違うのではないか、ということだ。例えばHTMLの組み方を突き詰めても見た目には表れないしクライアントのメリットになるとは思い難い。それよりは程々なところで手を止めてクオリティチェックに時間を割いた方がクライアントのためと言える。ただ、適度な汎用性はプロジェクトを跨いだときにパーツを使い回すためにも必要だし、これはコーディングスピードの向上にもつながる。どこまで考えるか、さじ加減は難しいが今後も誰かのメリットになるコーディングを心がけたい。