iOS開発で過度な共通化がもたらす影響

MVCやMVVM、Clean ArchitectureやVIPERなどなど、iOSプラットフォーム上でも設計手法もといデザインパターンは議論の大きな対象です。

一方で開発をしていると、どこまで共通化するかなども考えることが多々あります。例えばUIパーツをどこまで共通化するかなどです。

DRYの原則もあります。コードを共通化をすることで、自分も含む他のエンジニアももうそのコードを書く必要がないという大事な考え方です。

しかし嬉々として進める共通化には意外な落とし穴もあると考えてます。

プロジェクトに与える影響

私は、この「各コンポーネントをどこまで共通化するか」はプロジェクトに大きな影響を与える要素であると考えてます。

それはなぜか？以下に私の考察を述べてみます。

QAコストの増大やバグの見落とし

ある部品（ボタンとしましょう）に変更を加えた場合、そのボタンを使用している全ての画面に影響が及びます。コードによっては確認しなくて良かったり、自動テストでカバーできたりするかもしれません。しかしそうでない場合、私達は影響のある全画面を確認する必要があります。確認する必要のあった画面を見落としている可能性もあります。つまり、コストをリリースの遅れや予期しないバグという形で支払うことになります。

一方で、共通化することで初期の開発スピードを短縮できたりするので、そこはよい側面だなと思います。なぜならリリースするまでは、おそらく全ての画面の挙動をテストすることになるのですから。

しかし、上記の落とし穴を考えれば、リリースしてからの開発スピードが落ちるリスクもあります。

対処方法

過度な共通化に陥った場合の対処方法は、地道ですがひとつひとつ引き剥がすことと思います。そして、手を加えるタイミングで新規にパーツを作り直すなどしていきましょう。QAコスト増大や予期せぬバグは減ると思うので、最終的にリリースにかかる時間はそれほど変わらないはずです。

よりよい共通化のために気を付けたいこと

全ての共通化が悪いとは考えていません。なぜなら共通化によって私たちは余分なコードを書かなくて済むのですから。

なので私は、将来に渡って変更される可能性が極めて低いコードのみ共通化すべきと考えてます。それは言い換えると、変更が頻繁に行われると予想されるコードは共通化すべきでないと考えています。

そして、これはプロジェクトの関係者に確認する必要はありますが、今は同じような画面でも、細かくかつ頻繁に変更になる画面などは注意が必要です。うっかり共通パーツにしてしまうとそのパーツ自体に変更を入れたくなります。その時は影響のある画面全てをチェックしなければなりません。

迅速かつ負荷の低いリリースを望む場合は、それらを考慮するとよいのではと考えてます。