1. はじめに
チームでの開発においては特に、どのようにコードを書くかについて共通の理解を持つことが重要です。
本記事では、CSSの4つの原則に焦点を当て、私と一緒に開発を行っている人たちとまずは「何を重視するか」についてディスカッションを実施したので、備忘録としてここに残します。
＊4原則なので、4つ守れるといいですが、競合するものもあるので、迷ったときの指針を定めました。
2. チーム状況
- 対象読者：初学エンジニア〜中堅エンジニア
- 開発環境：大規模開発プロジェクトあり、保守作業も含む
3. メンバーが日々意識していること
-
予測しやすさ
コードは読みやすく、理解しやすいものでなければならない。 -
重複を避ける
同じスタイルルールを何度も書かず、汎用的なコードにリファクタリングする。 -
CSS変数の使用
変更が必要になったときの修正箇所を最小限に抑えるために、CSS変数を活用する。 -
固定値の使用を避ける
レスポンシブデザインを考慮し、可能な限り固定値を避ける。
4. ディスカッション内容
「予測しやすいコード」
チームメンバーがコードを理解しやすくするための土台。
これがないと、他を意識したとて、わかりづらいコードになる。
「再利用しやすい」
大規模開発や保守を考慮すると、「再利用しやすい」コードの重要性が高い。
初めから再利用可能なコンポーネントを設計することで、将来的な修正や機能追加が容易になる。
「保守しやすい」
保守の容易さは保守の効率性に直結する。
保守しやすいコードは、長期的なプロジェクトの成功に不可欠ではあるが、上記の「予測しやすい」「再利用しやすい」ができていれば、自ずと「保守しやすい」のではないか。
「拡張しやすい」
やりすぎると逆効果になる可能性がある。
必要以上に抽象化や汎用化を進めると、コスト（時間）がかかるので要注意。
しかし、適切なレベルでの拡張性は、将来的な機能追加や変更に対応しやすくはなる。
参考
【YAGNI原則】必要になると思っているなら、それはいらない
結論
私たちのチームでは、「予測しやすいコード」を基盤とし、「再利用しやすい」CSSの書き方に重点を置くことになりました。
しかし、この原則を守るためにも、チーム全体でのルールを定め、コーディングスタイルを統一する必要があります。
そうすることで、大規模な開発プロジェクトでも効率的にアプリケーションの開発を進めることができるため、今後は、ルールやガイドラインを検討して行きます。