t-hom’s diary

主にVBAネタを扱っているブログです。

コード共通化のデメリット

プログラミングが上達すると、コードの共通部分をプロシージャに切り出すことを覚える。
コードを共通化すれば、共通部分に変更が発生した場合に、修正は一か所で済むので効率的だとされる。

はたして本当にそうだろうか?
私もつい最近まで、コードの共通化は善だと信じていた。

しかし、最近いくつかの機能を備えたプログラムを書く機会があり、この考えに疑念を抱くようになった。

例えば下図のように機能Aと機能Bがそれぞれ別のモジュールに存在し、それぞれ3つのプロシージャで構成されているとしよう。
f:id:t-hom:20180614184636p:plain

そして、ProcA-2とProcB-2が多くの点で共通しており、うまくすればひとつのプロシージャに纏めることができる状況を想像してみて欲しい。

実際にまとめるとこのようになる。
f:id:t-hom:20180614190856p:plain

以前の私なら、このコードは変更に強くなったと考えていた。
しかし実際にこのような状況を経験してみて、その考えは浅はかだったと反省することになった。

例えば機能Aを変更したいとき、それに合わせて共通プロシージャProcAB-2も変更する必要が生じたとする。
しかしProcAB-2を変更するには、機能Bに悪影響が無いよう慎重に整合性を保つ必要が出てくる。

複数の機能から依存された共通プロシージャは、おいそれと変更できなくなる。
また、これまで単一モジュールで完結していた機能が複数モジュールにまたがることで、モジュールの独立性が弱まり、別プロジェクトへの移植も困難になる。

DLL地獄というのを聞いたことがあるだろうか。様々なアプリケーションが共通DLLに依存しており、ソフトウェアによって依存しているDLLバージョンが異なることで発生するトラブルである。コードの共通化はまさにこれと同じトラブルを招く危険性がある。

私は最近、過度のコード共通化でプロジェクトのあちこちに依存が発生し、そのVBプロジェクトを破綻させてしまった。

今、最初からやり直しているが、心がけていることは極力モジュールの単体完結性を維持することである。ひとつの機能をうまく成し遂げるためにモジュールを作る。モジュール間でコードの重複があっても気にしないこと。それは必要な冗長性だ。

ここまでコード共通化のデメリットを書いてきたが、もちろん正しい共通化にはメリットがある。
私が問題だと思うのは、共通化は善であり、共通化可能だという単純な理由で依存性やプロシージャの独立性を考慮せずに共通化するケースである。
真に汎用的なプロシージャが、たまたま機能Aと機能Bから参照される場合は問題ないと思う。

当ブログは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。