VB6.0掲示板か.NET掲示板か投稿を迷ったのですが・・・

自分ひとりでVB6.0で業務アプリを新規作成中です。
職場では、予算やら開発方針会議やらややこしい会社の都合で、
はじめから.NETでつくることは許されないのですが、順調に運用しているシステムも
来年以降順次VB.NET移行が決定しています。
というわけで今せっせと設計しているアプリ（４人月程度）も、早くて一年後くらいには
.NETに作り直すことになりそうです。

VB.NETの技術者はまわりには一人もいません（プログラムが分かる人がいないというか）。
移行しなくてはいけないのなら、移行しやすいように組みたいのですが、.NETは未経験で
どうすればよいのか？？
とりあえず.NET参考書などは購入して勉強しようとしてますが、
なにかコツはないでしょうか？または参考になるものをご存知ないでしょうか？

移行時のつまづきのQ&Aはこちらの.NET掲示板にもありますが、ピンポイントすぎて
「移行しやすいVB6.0プログラミング」にはあまり結びつかなくて。。。

> 移行時のつまづきのQ&Aはこちらの.NET掲示板にもありますが、ピンポイントすぎて
> 「移行しやすいVB6.0プログラミング」にはあまり結びつかなくて。。。

そんなあなたに是非
http://www.microsoft.com/japan/msdn/vbasic/migration/tips/default.aspx

> 移行時のつまづきのQ&Aはこちらの.NET掲示板にもありますが、ピンポイントすぎて
> 「移行しやすいVB6.0プログラミング」にはあまり結びつかなくて。。。

どれの事を指しておられるのか解りませんが、.NET 関係のTopページに紹介している
Visual Basic 6.0 ユーザーのための Visual Basic .NET 移行ガイド　以上のものは
ないかと思います。

http://hanatyan.sakura.ne.jp/dotnet/Tipsitiran.htm

http://www.microsoft.com/japan/msdn/net/vbtransitionguide/

しかしながら、私の経験から言えば、VB6.0 で作成したコードをウィザードを使って
.NET に移行しても業務用として使用するにはどうかと思います。
従って、どちらかと言えば、下記のようなものの方がより役立ったように思います。

　http://hanatyan.sakura.ne.jp/dotnet/vb6tonet.htm

その他、ここに掲載しているようなTips集は特に有効かと。
http://hanatyan.sakura.ne.jp/dotnet/menu.htm

下記サイト等も
http://dobon.net/vb/dotnet/index.html

オブジェクト指向にも通じると思うんだけど。。。

[VB6.0]→[VB.NET]へ引き継がれているものはたくさんあります。
引き継がれなかったものや、仕様変更もたくさんあります。
…ということは、修正を最小限に抑えるなら、しっかりと目的別に
部品化しておくことです。引き継がれなかった部分のみ交換すれば
いいように。
# 逆に何でもかんでもグローバルで宣言とか、プログラム内の依存
# 関係がスパゲッティーしてると、全部作り直したほうが早いと
# いう結論になると思います。
それは[VB6.0]でもメンテしやすいコードになるはずです。
そんなプログラムなら[VB6.0]か[VB.NET]かは関係ないと思います。
設計の問題ですから。

ボク自身の頭の中は、特に苦労を感じずに移行できたと思ってます。
If 文とか、For ループとか、基本構文が変わったわけではないので。
# Excel の解放とかは苦労してますが、どうしようもないことですし。

もともと、VBが外部のAPIとかライブラリを利用して部品交換して
動いてるようなものだと思っています。テキストボックスとかボタンに
したってコンポーネントの参照ですし、[VB6.0]時代でも Excel の
バージョンが上がったら修正とかあったはずです。[VB6.0]→[VB.NET]
で一気にあらゆるオブジェクトのバージョンが上がったようなものですが、
プログラマ側の基本的な対応方法は変わらないかと。

新しいオブジェクトの操作は、その都度調べて覚えるだけですし、
代替機能を持つ新しいオブジェクトが見つからなければ(使いこなせ
なければ)基本構文や理解できるオブジェクトを組み合わせて作る
だけです。
オブジェクトの並べ替え命令(Sortメソッド)の動きが気に入らなければ、
自分でソートのアルゴリズムを書くという発想が自然にできる、基礎の
しっかりしたプログラマなら何の問題もないでしょう。

逆に、自分の思い通りの関数が用意されていなければプログラムできない
というのであれば、プログラマとしての能力に問題があるのでは？
# 現実問題としてそんな自称プログラマ、実質コピペ職人が増えてますが。

ま、部品の中身は見なくても、画面に貼り付けてお手軽に実行できる
VBの特性とは矛盾してるかも知れませんが、プログラムは現実世界の
ものなので、ブラックボックスの中に夢を期待されても困るわけです。

いつまでも自称初心者を名乗り続ける人は論外ですが、ある程度経験を
積んだプログラマなら、地に足の付いた考え方で、ブラックボックスの
中身をおおまかに想像できると思います。だとしたらブラックボックスが
使えなくなっても、さほど困らないはず。

[VB6.0]→[VB.NET]にこだわらず、プログラムとしていいものを作るような
考えで、設計書とかに力を入れてみるのも１つの方法かと思います。

NANACさん、花ちゃんさん、るしぇさんありがとうございます。
これから新規でつくるVB6.0アプリなのに.NETに移行が決まってしまっているので、
なるべく.NET移行時に困らないよう6.0で組んでおきたいと模索中です。

しかし「VB6.0でコレとコレは使わずこんな構成にしておけば移行も楽」みたいな
楽ちん資料はないものですね。そりゃそうか・・・そしてやはり先ずVB.NETを知らねば。
.NET開発環境がないのでつらいのですが、がんばります。

NANACさん
>http://www.microsoft.com/japan/msdn/vbasic/migration/tips/default.aspx
こちらをただいまチェック中です。勉強します！

花ちゃんさん
>Visual Basic 6.0 ユーザーのための Visual Basic .NET 移行ガイド　以上のものは
ないかと思います。
一部ちらっと読んだことはありましたが、も一度みてみました。移行方法がのっている・・・とだけ認識していたのですが、VB6.0で準備しておくことについても記載があるのですね。
役立ちそうなのでじっくり読んでみます。
>http://hanatyan.sakura.ne.jp/dotnet/vb6tonet.htm
は既に拝見して、参考にしております。ありがとうございます。

るしぇさん
>しっかりと目的別に
>部品化しておくことです。引き継がれなかった部分のみ交換すれば
>いいように。
おっしゃるとおり、部品化して組んでおきたいと考えています。
オブジェクト指向プログラミング自体これから（理屈は勉強したけど実践はまだ）
ということもあり、.NETはソレなので要は修正点を囲い込めるような構造に(部品に）
すれば移行しやすいのだろうと。。思いつつも不安いっぱいの手探り中です。

例えばコントロールの移行を考えていて、
vb6.0で配列にして共通動作はクラスでまとめてといて大丈夫のかな？とか
（コントロール配列は.NET移行できないみたいですね。大丈夫じゃなかった）
basで共通関数つくるのとclassにしておく（いつもは使い勝手でふり分けていた）のと、
どっちが移行時の作業量が少ないのかな？とか気になってしまいます。
（どっちなんでしょう・・・）

>設計書とかに力を入れてみるのも１つの方法かと思います。
ここは出来る限り！がんばります。。。