はじめに

前回・前々回とフレームワークっておいしいの？をお題としてコンポーネント開発に触れてきました。
https://qiita.com/jun2/items/ae09f35c307711ac4dd5
https://qiita.com/jun2/items/5408fbbd1ed393bedd4e
開発を行っていく中でコンポーネント指向での開発を行うことでプロジェクトを跨いだ効率化が図ることができることがわかってきました。
上記2記事のまとめ編に近いものになりますが、コンポーネント指向での開発を検討している方の後押しになればと思います。

コンポーネント指向でのメリット

私なりに感じたメリットとしては以下のとおりです。

UI動作に統一感が出る。
軽微なロジックを何度もコピペする必要がない
テストの範囲を少なくすることができる
上記より開発スピードがとても早い

それぞれ解説していきます。

UI動作に統一感が出る

開発者によって好みがあると思うのですが、例えば日付入力ボックスの右側にクリック時にカレンダーが開くアイコンをつけたい人、アイコンはつけずに入力ボックス押下時にカレンダーをつけたい人などあると思います。
社として作る人が限られている場合はこれらはルールなりレビューなりで統一することができますが、作る人はバラバラ、部署もバラバラ、レビューする人もバラバラ、ルールがなかなか定着しにくい風潮、など色々と事情がある場合統一していくことは難しいです。
部品開発を行い、タグを書くだけで実装できるのであれば作る人の好みは現れにくいものと思います。

軽微なロジックを何度もコピペする必要がない

冒頭の記事でも記載しましたが、例えば

フォーカスアウト時にカンマ編集する(フォーカスイン時にカンマをとる)
日付入力時に和暦変換表示する
大文字小文字を小文字に統一する
電話番号・郵便番号・メールなどのバリデーション形式チェック
など部品化しておくことで本体のロジックには記載せずに純粋なビジネスロジックだけを表現することができます。

テストの範囲を少なくすることができる

これが一番大きいです。
「軽微なロジックを何度もコピペする必要がない」に記載したロジックはテストする必要があります。
カンマが2個以上になったら（私がよくハングするパターン笑）・・・、スラッシュ付きの日付の場合は・・・など軽微なロジックといえど細かい条件を与えてテストする必要があります。
コンポーネントとしてすでに担保できているのであれば、狙った機能が動いているか？（パラメータなどの設定にて正しく設定できているか）を見れば良いだけとなります。
当然ながらコンポーネントとしては細かい条件のテストは必要です。

上記より開発スピードがとても早い

これらメリットを感じた上で開発を行ってみると確かに開発は早いですし、コーディング量そのものがぐっと減ることが実感できます。
ただ一方でコンポーネント開発の初期コストは必要です。
私自身もコンポーネントの仕様を拡張していくことに時間を大きく取られました。
また、リードエンジニアが率先してやる、コンポーネント開発の専門部隊なりワーキンググループにて開発が行われるなどの体制も必須です。
みんなで良くしていきましょう！というスタンスでうまくいく企業様であればそれはそれで素晴らしいことだと思います・・・が、積極的な人材が多数いるような状況というのは恵まれた環境であると思います。

一度作ったもの再利用はコピペすることで確かに実行することができます。
が、もともと汎用性を求めて作ったコンポーネントの再利用性は非常に高いものであると思います。
頭ではわかっていてもなかなか今のやり方を変えていくには勇気が必要なものではあります。
なかなか踏み出せない方の助力に少しでもなればと思います。