二度と繰り返したくないので言語化します。
背景
ソースコードを流用して別プロジェクトを作ろうとする中で、複数のプロジェクトから同じコードを使いたいので、機能のクラスライブラリへの分割を行っています。
内容はVB.NetのWindowsフォームアプリケーションで、諸々のコンポーネントや機能をクラスライブラリに分割して種々の機能を作り直せば簡単にできるだろうと考えていました。
元のコード
元のコードは自分がフルスクラッチでリライトしたものです。つまりこの件で悪いのは全部自分です。以下の記事でリライトしていた*1コードです。
wrongwrong163377.hatenablog.com
起きた問題
起きた問題は大きく以下の2点です
- 巨大な定数クラスへの依存による分割の困難さの発生
- マズい変数の渡し方と各機能の利用
巨大な定数クラスへの依存
巨大な定数クラスはとても便利でした。実装当時は.NetのPropertieやらDictionaryやらを使ってスマートに仕上げた気でいました。が、実際に機能のクラスライブラリへの分割を行ってみると、この定数部が恐ろしい勢いで足を引っ張りました。
機能ごとの制御に定数クラスの変数を利用してしまったせいで分割は恐ろしく煩雑で大規模な変更を伴いました。二度とやりません。
定数クラスを作るとしても全てを1つに纏めるようなことはせず、機能ごとに管理する定数をしっかり割り振った上で作るようにしようと思います。
定数クラス自体は「よく使う定数を引数でリレーするような形にならない」という利点があるので、決して害悪とは言えないと思っています。できるだけスマートに利用していこうと思います。
マズい変数の渡し方と各機能の利用
「末端の機能にはリテラルで渡せ」というのが今回最大の教訓です。というのも「定数クラスの値で渡して、諸々の処理にそれを流用する」ということをやってしまったせいで余計な依存が生まれ、クラスライブラリへの分割で物凄く苦労しているからです。
「後から見返してそうだった」というのが大きいとは思いますが、ファイルパスを渡せば済む所で無駄に定数クラスへの依存を作ってしまったせいで分割が上手く行かなくなったり、「定数クラスへ依存しないように」と作ったはずの関数で依存を発生させていた時は本当に辛かったです。
残りの分割に掛ける労力を考えると頭が痛いというか、生産的じゃない作業過ぎて死にたくなります。辛い。
反省
巨大な定数クラスを作らないことと、設計をしっかり考え、できるだけリテラルで引数をやり取りすることを心がけようと思っています。
極端な言い方になりますが、最初からクラスライブラリへの分割をやっていれば依存を発生させないコーディングができたんじゃないかとすら思っています。
割と『秘伝のタレ、製造中』みたいな感じになりつつあるので、できるだけスマートなコードにまとめられるように頑張ろうと思います（というか、あんだけDisっておいてちゃんとしたコードを残せないってのは……）。特に割とお金を貰っているという点は大きいですね。がんばります。
*1:あれから半年ってマジか！？
