ときどき、「古いシステムを使い続けている」という顧客が居る。それでも構わない場合もあるが、看過できない場合もよくある。例えば、新機能を追加すると言う場合に元のシステムに連携させている場合。開発効率も悪く、制約や障害を孕ませ、と、良いことはない。
一番多いのがVB6.0で作ったものを使い続けない、というもの。そんなもの、とっととVB.netにでも移行してしまいなさい。その方がトータルコストも安上がりになりますよ、と言ってあげたい。VB6.0からVB.netへの移行は、それほど高度な技術はいらない。
ただ、折角移行するのであればオブジェクト指向の利点を活かすようにしないと移行する意味は薄い。単にコンバートすればいい、というものでもないのである。
ではどうすればいいか。
手順としてはおおまかに
・現状の整理(MVC化、リファクタリング、共通処理の洗い出し、可読性の向上 等)
・名前空間への整理
・移植
である。
VB6から抜け出せなくて困っていて、まだVB6のコンパイラがあるのなら、保守性を高めることも可能だ。上記の「現状の整理」を推進すればよい。
それにはクラスモジュールが有効である。現在VBA用にクラスモジュールの資料を作っているが、VB6でも同様に使える。是非活用いただければ、と思う。
一番多いのがVB6.0で作ったものを使い続けない、というもの。そんなもの、とっととVB.netにでも移行してしまいなさい。その方がトータルコストも安上がりになりますよ、と言ってあげたい。VB6.0からVB.netへの移行は、それほど高度な技術はいらない。
ただ、折角移行するのであればオブジェクト指向の利点を活かすようにしないと移行する意味は薄い。単にコンバートすればいい、というものでもないのである。
ではどうすればいいか。
手順としてはおおまかに
・現状の整理(MVC化、リファクタリング、共通処理の洗い出し、可読性の向上 等)
・名前空間への整理
・移植
である。
VB6から抜け出せなくて困っていて、まだVB6のコンパイラがあるのなら、保守性を高めることも可能だ。上記の「現状の整理」を推進すればよい。
それにはクラスモジュールが有効である。現在VBA用にクラスモジュールの資料を作っているが、VB6でも同様に使える。是非活用いただければ、と思う。