VBAからC＃への移行について質問するチームメンバー
背景
昨年、10人程度のユーザーの事業計画に使えるツールを作ってもらいました。これは、私に作業を「下請け」した別のITチームに代わって行われたものであり、プロジェクトの期限が少し計画外だったため、少し急いで実装する必要がありました。
当時、私たちはVBAを使用してExcelワークブックを作成し、ユーザーにこのVBA拡張ワークブックをイントラネットからダウンロードしてPCで使用するのが最も速い方法だと判断しました。この場合、Excelは制約でした。これは、使用する計画システム（つまりデータベース）は、計画ワークブックを開くと同時にロードする必要があるExcelアドインを介してのみ対話できるためです。ただし、VBAは当時の制約ではありませんでした。
約4,000行のVBAコードを作成したワークブックで、データレイヤーとプレゼンテーションレイヤーを分離しようとしましたが、プロジェクトの期限が原因ですべてのケースで実行できませんでした。正直なところ、このワークブックを作成できたことを誇りに思いますが、同時に、コーディングとユーザーへの展開の両方の点で優れていたので少しがっかりしました。
今日
今日に戻って、ITチームは再び同様のワークブックを要求するようになりました（そのため、上記の他のワークブックの一部を再利用することができます）が、今回ははるかに複雑であり、より多くのユーザーが使用します（ 200前後）。
ただし、今回は少し計画が良く、計画を立てる時間がもう少しあることがわかります。これに基づいて、100ユーザー向けのプログラミングは10ユーザー向けのプログラミングよりも影響が大きいので、ソリューションとインフラストラクチャについて考えました。したがって、既存のコードをC＃ソリューションに移行して、より洗練された方法でコードを管理できるようにすることを検討するようにチームに提案しました。 VSTO/Excel-DNAを使用して記述され、ユーザーに展開できるアドインとして引き続き検討しています。
2週間前にITチームとこれについて話し合いましたが、昨日、チーム（VBAまたはC＃を知らない）の1人から、なぜこの新しいプロジェクトをC＃で開始するのか、以前と同じアプローチ。彼らの懸念のいくつかは次のとおりです。
- これはかなり重要なプロジェクトであるため、機能する必要があります。C＃ソリューションは、既存のVBAベースのソリューションほど安定していないか、機能しません。
- VBAソリューションで行ったことを破棄し、C＃で最初から再作成する必要があります。
- 誰かがVBAとC＃の2つの別々のソリューションをサポートする必要があります。 [実際には、彼らには現在サポートする人がいないので、私は通常は介入します]。
今、私は彼らの懸念のいくつかをある程度理解することができますが、私は次のステップと何に彼らに戻るかについての決定に至る必要があります。個人的には、このような「エンタープライズ」ソリューションを構築するのに向いていると思うので、C＃で実装したいと思います。さらに、私はこの機会にC＃のスキルを磨き上げたいと思っています。現在、C＃にはVBAほどの能力がないので、このようなプロジェクトを「次のレベル」に引き上げたいと考えています。
私は、C＃ソリューションがこのプロジェクトに適していることを彼らに説得するために使用できるポイントのリストを用意しました。
- ユニットテスト。
- ソース管理。
- コードドキュメンテーション-他のサポート担当者への知識の伝達用。
- より良いコーディング規約-ReSharperのようなものを使用して、より良い命名と構造を強制できます。
- より良いIDE-エラーの強調表示による間違いが少ない。
- アセンブリによるモジュール性の向上-将来のツールでの再利用を促進できます。
- 管理された展開-このツールの使用者を制御できます。
質問：それらを納得させるために他にどんな点を追加できますか？または、私はこのプロジェクトでかむことができる以上に噛み砕こうとしていますか？とにかく私は静かにしてVBAでそれを行うべきですか？
「新しい」または「涼しい」と思われるため、新しい言語に移行するだけでは決定の根拠とはならないことを認識しています。そのため、それを決定ポイントとして含めることに抵抗しました。これは事実についてです。
また、SOには多くの比較があるため、言語としてのC＃とVBAの文字通りの比較は求めていません。
あなたが挙げた3つの点は公平だと思われます：
これはかなり重要なプロジェクトであるため、機能する必要があります。C＃ソリューションは、既存のVBAベースのソリューションほど安定していないか、機能しません。
実際、後で、「この機会にC＃のスキルを磨き上げたいのですが、私はVBAほどC＃の能力がありません "（鉱山を強調）。
言い換えれば、あなたは機能し、集中的なユーザーテストを経たソリューションを持っています。あなたはこれらすべてを投げて、あなたがよく知らない言語ですべてを書き直したいのです。問題がわかりましたか？
VBAソリューションで行ったことを破棄し、C＃で最初から再作成する必要があります。
絶対にしてはいけないこと が頭に浮かぶ。あなたはコードとユーザーテストを投げています。良いことではありません。
誰かがVBAとC＃の2つの別々のソリューションをサポートする必要があります。 [実際には、彼らには現在サポートする人がいないので、私は通常は介入します]。
VBAバージョンを引き続き使用する場合、書き換えはさらに問題になります。既に機能していて、リファクタリングして機能を追加できるシステムが1つしかないのに、注意が必要な2つの異なるシステムがあるのはなぜですか。
一方、あなたの指摘のいくつかは批判される可能性があります：
単体テスト
現在のプロジェクトを単体テストすることもできます。 そのための便利なフレームワークがない場合は、作成します。
ソース管理
ソース管理はテキストを扱います。現在のコードはテキストであるため、ソース管理を使用できます。
言語、オペレーティングシステム、フレームワーク、エコシステムはまったく関係ありません。記述するコードにはソース管理を使用できます（使用する必要があります）。VisualStudioのコード、またはLINQPadで数分でドラフトしたコードの一部、またはタスクを自動化するPowerShellスクリプト またはデータベーススキーマ 、またはExcelマクロ。
コードドキュメント-他のサポート担当者への知識の伝達用
同意した。
より良いコーディング規約-ReSharperのようなものを使用して、より良い命名と構造を強制できます。
「より良い」を定義します。 Excelのマクロのコーディング規約はありますか？はいの場合、それらを使用します。それらは他のものよりも良くも悪くもありません。そうでない場合は、作成して公開し、他の人も使用できるようにします。 2010年に投稿された質問への回答 はかなりがっかりしているように見えますが、それ以降、新しいツールを利用できる場合があります。
コーディング規約の重要な部分は、コミット時に強制されることです。
Better IDE-エラーの強調表示によるミスの減少。
同意した。 Visual Studioでマクロを作成できない という事実は非常に残念です。
アセンブリによるモジュール性の向上-将来のツールでの再利用を促進できます。
現在の製品でもある程度のモジュール性を使用できると思います。
管理された展開-このツールの使用者を制御できます
同意した。
完全な書き直しの代わりに、コードをマクロからVB.NETで記述された通常のアセンブリにプログレッシブに移動する方法を検索できます。なぜVB.NETなのか？ 3つの理由：
VBAとC＃の間にあるので、VBAとVB.NETの違いはほとんどありません。
あなたはVBAをよく知っています、そしてこれだけがC＃の代わりにVB.NETを使用する良い理由です。 「C＃スキルを磨く」には、ビジネスに不可欠なものではなく、個人的なプロジェクトを使用してください。
言語を別の言語に書き換えると、潜在的なバグが発生します。このプロジェクトでは必要ありません。
.NETアセンブリに移動すると、便利な単体テスト、TFS、および他のプロジェクトで現在使用しているエラーの強調表示など、Visual Studioの便利な環境を提供できます。
同時に、コードを段階的に移動する場合、完全な書き換えのリスクを負うことはありません（つまり、4か月を費やして、多数の新しいバグがあるため、誰も使用したくないものを作成します）。たとえば、特定の機能に取り組む必要がありますか？まず、この特定の機能を.NETに移行する方法を考えてください。
これはリファクタリングとよく似ています。いくつかの新しいデザインパターンと言語機能を学んだために全体を書き直す代わりに、現在作業しているコードに小さな変更を加えるだけです。
C＃への移行をサポートします。他の人はあなたのポイントを非常によくカバーしてくれたので、私は彼らが言ったことをリハッシュしません。 VBAを使用する理由はたくさんあります。
ただし、私の雇用主の1人が、意味のあるドキュメントを作成する上で申し分のない仕事をしました。すべてのソフトウェアプロジェクトにそれがあったとしても、設計の決定は実際には正当化されて書き留められていました。私のポイント？設計上の決定の1つは、「このプログラムをJavaで作成することを選択しています。なぜなら、氏はx年のJava彼の履歴書での経験）を入れたいからです。それがC＃に移行する強い理由は、それを些細なこととして無視することはできません。ITチームに正当化する理由の1つになることはありません。あなたの履歴書が欲しい、彼らは実用的な製品を気にします。
VBAの考え方についても考えます。私はそれが真実ではないことを知っていますが、履歴書で「VBA」を見て、「何、この人はインターンの仕事で行き詰っていましたか？本物のの経験がないのはなぜですか？ =言語？」彼らは「VBA」を見て「Excelマクロ開発者」と考えています。あるセルを別のセルにコピーして貼り付ける、単純な計算を行うなど。通常、VBAでの実際の開発を評価できるのは、それを実行したことがある人であり、少なくとも私の経験では、ますます小さなプールのように見えます。あなたはあなたの地域のVBAの見方をよりよく理解しているかもしれませんが、私はそれに対する多くの不当な否定性を見てきました。
もう1つ注目したいのは、MainMaがVBAとC＃の類似点について言及したことです。これは間違いなく真実であり、JMKの答えは、読み進めるためのいくつかのテクノロジーを提供します。 VBAコードをC＃プロジェクトにコピーして貼り付けてみて、構文エラーがどれほど簡単に修正できるかを確認してください。
4,000行のコードがあるとおっしゃっていましたが、これはコードのかなりの部分であり、おそらく多くの機能を備えています...しかし、それはonly 4,000行のコードです。コピーして貼り付けてみてください。これらの構文エラーを修正してプロジェクトが機能するようになっていても、驚くことはありません。コードの詳細や利用可能な空き時間を知らなければ、週末にこれを打ち消すことができると思います。
C＃のベストプラクティスに従っていない可能性があり、非効率的かもしれませんが、C＃で機能的に同等のプロジェクトになってしまいます。また、新しいC＃コードは、古いVBAコードよりも欠陥が発生しにくいことは比較的確実です。
自分の時間にVBAコードをC＃に変換すると、いくつかのことが実行されます。
- 構文エラーを研究するにつれて、C＃の実践に慣れることができます-C＃で実際に作業するための入門書
- これは、プラグインをExcelにロードする際の明らかな問題を明らかにします（おそらくExcelがまだ要件であるためです）。おそらく、まだ検討していない問題があり、それが障害となる可能性があります。
- 顧客（ITチーム）に概念実証が表示されます。現在の機能を備えたC＃プラグインが機能していることが彼らにわかる場合は、C＃を使用することで認識されるリスクのレベルを低減できます。
ITの3つのポイントに戻ります。
•これはかなり重要なプロジェクトであるため、機能する必要があります。C＃ソリューションは、既存のVBAベースのソリューションほど安定していないか、機能しません。
前述のように、C＃コードは同じ機能をカバーし、VBAと同じくらい安定しています。厳密に言えばisバグ/欠陥または非効率性を導入する可能性がありますが、それはありそうにありません。私たちはiOS/Objective CからAndroid/Javaへの移植について話しているのではなく、構文の多くの類似点を共有し、まったく同じテクノロジーを利用できる2つの言語間の移植について話している-Excelワークブック。
•VBAソリューションで行ったことを破棄し、C＃で最初から再作成する必要があります。
これにより、労力やコードを捨てることはありません。
•誰かがVBAとC＃の2つの別々のソリューションをサポートする必要があります。 [実際には、彼らには現在サポートする人がいないので、私は通常は介入します]。
ソリューションは1つだけで、すべてC＃です。
全体として、顧客は多くのリスクを抱えています。そのリスクを軽減するための対策を講じることができれば、C＃への変更を受け入れる可能性があります。
私はそれを言うのが嫌いですが、あなたの議論は水を保持していません。
ユニットテスト。
これは非常に長い間解決された問題でした。単体テストフレームワークは多数あります。一つを選ぶ。あなたはすでにこれをやっていたはずです。 IDEに統合され、他の優れた機能を提供するため、 ours をお勧めします。
ソース管理
これは少し難しいですが、ビルド済みのソリューションはほとんどありませんが、実際には、コードをリポジトリに出し入れするだけの問題です。 これを行う簡単な方法はここにあります ですが、 他のより良いオプション もあります。
コードのドキュメント
また、解決された問題。 MZ-ToolshasはXMLドキュメント機能です .NetのXMLコメントドキュメントと非常によく似ています。
より良いコーディング規約
Visual StudioにReSharperプラグインがあるのと同じように、 MZ-Tools と Rubberduck の両方にこのような機能があります。
より良いIDE
この場合も、VBA IDEで使用できるプラグインがあります。
アセンブリによるモジュール性の向上-将来のツールでの再利用を促進できます。
また、解決された問題。いいえ、アセンブリを作成することはできませんが、他のVBAプロジェクトを参照することはできます。
管理された展開-このツールの使用者を制御できます。
ビットステッカーです。プログラムにアクセスできるユーザーとアクセスできないユーザーを制御するコードを記述する必要がありますが、（再度）おそらく既にセキュリティコードを記述しているはずです。
展開に関してはまた解決した問題です。はい、コードが必要ですが、 使用/変更できる例 があります。
これに加えて、ゼロから始めることになります。私もお勧めします Joel Spolskyの記事 。
彼らは、ソフトウェア会社が犯す可能性のある1つの最悪の戦略的間違いを犯してそれを行いました。
彼らはコードを一から書き直すことにしました。
IT担当者は正しい。これを一から書き直すことはできません。現在のソリューションで問題を解決する必要があります。
これで、すべてのことを説明したので、C＃またはVB.Netでこれを実行する理由を完全に理解できます。 新しいプロジェクトを開始する場合、本当に良い解決策ですが、そのサウンドから、それは新しいプロジェクトではありません。最初からやり直して、改善する方がはるかに良いです。
C＃への移行方法（つまり、使用するテクノロジ）によって異なります。
OpenXMLを使用する場合は、完全に書き直すということですが、機能する解決策がある場合はお勧めしません。
Interopの使用について話していると、プロセスが驚くほどスムーズであることがわかります。過去に多くのコードをVBAからC＃（Interopを使用）に移動しました。ワークブックにプラグインすると、次のようになります。
var excelApplication = new Application();
var workbook = excelApplication.Workbooks.Open(@"C:\location.xlsx");
多くの場合、VBAコードをコピーして貼り付けることができます。関数呼び出しの前にworkbook.を付け、必要に応じてDimをvarに置き換えて、セミコロンを追加します。終わり。
基本的には下のフレームワーク（Excel）と同じで、構文をVBAからC＃に変更するだけです。
完了したら、必ずアプリケーションを保存して閉じます。
workbook.Save();
excelApplication.Quit();
次に、マーシャルでアプリケーションを解放します。
Marshal.ReleaseComObject(excelApplication);
私はおそらく、Excelアプリケーションオブジェクトの周りにIDisposableを実装するラッパークラスを記述し、このオブジェクトを使用する場合は必ずusingを使用してください。
ケースを作成するための良い方法は、1時間ほど費やすことです。これは、短時間でコードを移植する速さを示し、これが良いアイデアであることを同僚に納得させるでしょう。
コードはほとんど変更されないままですが、Visual Studio内にC＃プロジェクトがあることで言及したすべての利点があります。
Microsoftでさえ this の記事で次のように述べていることを指摘できます。
コードを更新して機能を改善したり、バグを修正したりするには、Officeのアーティファクトをすべてのユーザー、およびカスタマイズを使用していたすべてのファイルで再送信、再構成、再作成する必要があります。
この記事は、Officeをベースにしたものを開発するためのさまざまなアプローチに関するものです。おそらく、他の賛否両論を議論に取り入れることもできます。
私は現在、VBAほどC＃に精通していないため、この機会を利用してC＃のスキルを磨き上げたいと思います。このようなプロジェクトで「次のレベル」に進むことができます。
正直に言ってください。この決定に関与する他の人々とこの情報を共有する予定はありますか？そうでない場合、プロジェクトが失敗した場合、私はあなたにすべての責任を負います。同様のプロジェクトがすでに作成され、フィールドに出されているので、誰もが自分の心の中で起こると予想されることを形成しています。彼らは最後の1つを構築するのにかかった時間を知っており、これをより短い時間で作成できると信じます（これは、追加の要件に基づいて正しい場合とそうでない場合があります）。新しい言語を習得するとともに、この責任を引き受ける準備ができていますか？
古いアプリをC＃ASAPに移植することをお勧めします。多分あなたは決定がなされる前のプロセスで十分に学ぶことができます。少なくとも、新しい言語でスキルを向上させるという目標を達成し、プロジェクトを時間どおりに完了することができます。
繰り返しになりますが、それについて強いと感じ、プロジェクトの構築がすべて肩にかかっている場合は、好きなようにしてください。許可よりも許しを得る方が常に簡単です。
私は同じ立場にあり、非常に大きな（20k行以上のVBAコード）アプリケーションをExcelブックに組み込んでいます。 Office 2013でのテストでは、新しいオフィスモデルでの起動イベントのシーケンスの変更と、おそらくより厳密なEMETの実施が原因で、それは単に機能しません。したがって、私は今年のOffice 2013の展開前にC＃およびVB.NETへのクラッシュ変換を行う立場にあります。組織の周りで使用されている他の、より単純な（VBA拡張）ワークブックは免疫がなく、機能しているものとそうでないものがあります。
エラーは、Workbook_Openイベントで発生します。このイベントでは、ブックのシートは使用できなくなり、VBAコードが参照される前の内部Excelコードで発生します。
VBA、C＃、VB.NETのすべてで快適であるため、後の2つの両方で変換を記述しています。フレームワークコードはC＃で記述されています。これは、言語イディオムを使用すると、VB.NETの場合よりも3〜4倍速く特定の関数構成をその言語で記述できるためです。コードの大部分はVB.NETにあります。これは、私の書き換えがそれほど広範囲ではなく、C＃にはない特定のイディオムがあるためです。
決定を行う前に、既存のアプリケーションをOFFICE 2013でテストし、組織が今後2〜3年間で展開することを予測しているEMET施行の最大限の範囲をテストすることを強くお勧めします。私と同じように、既存のアプリケーションはリライトなしではその環境で単に実行されないことに気付くでしょう。その場合、リライトはDOT NETとVSTOでも行われる可能性があります。
補遺：
ワークブックVBAのコンテンツ全体をループし、すべてのモジュール、クラス、フォームをファイルにエクスポートする、少し自動化された抽出ユーティリティを作成するのは、どれだけ豪華かによって異なりますが、1〜2日で完了します。同様に、ディレクトリから空のワークブックにファイルをインポートする逆も同様です。これら2つを使用すると、すべてのVBAコードを適切なソース管理に入れ、ワークブックのソースコードからBuildプロセスを作成することができます。
または- Excel VBA Code Cleaner などの無料のユーティリティを使用します