VBAからC＃に移行するチームメンバーの質問

バックグラウンド

昨年、約10人のユーザーのビジネス計画に使用するツールの作成を依頼されました。これは、作業を「下請け」する別のITチームに代わって行われ、プロジェクトの締め切りが彼らの側で少し計画外であるため、私はそれを少し急いで実装しなければなりませんでした。

当時、私たちは、VBAを使用してExcelブックを作成し、ユーザーがこのVBAが強化されたブックをイントラネットからダウンロードしてPCで使用するのが最も簡単な方法であると判断しました。この場合、Excelは制約でした。使用する計画システム（データベース）は、計画ワークブックを開くと同時にロードする必要があるExcelアドインを介してのみ対話できるためです。ただし、当時のVBAは制約ではありませんでした。

約4,000行のVBAコードを作成したワークブックで、データレイヤーとプレゼンテーションレイヤーを分離しようとしましたが、プロジェクトの締め切りのためにすべてのケースでできませんでした。正直に言って、このワークブックを作成することを誇りに思っていますが、同時に、コーディングとユーザーへの展開の両方の面で、より良くできたという点で少しがっかりしています。

今日

今日に戻ると、ITチームが再び同じようなワークブックをリクエストするようになりました（したがって、上記の他のワークブックの一部を再利用できます）が、今回ははるかに複雑で、より多くのユーザーに使用されます（約200）。

ただし、今回は少し計画が良く、計画を立てる時間がもう少しあることがわかります。これに基づいて、100人のユーザー向けのプログラミングは10人のユーザー向けよりも影響が大きいため、ソリューションとインフラストラクチャについて考えました。したがって、既存のコードをC＃ソリューションに移行して、コードをより洗練された方法で管理できるようにすることを検討することをチームに提案しました。VSTO / Excel-DNAを使用して作成され、ユーザーに展開できるアドインとしてまだ検討中です。

私はこれを2週間前にITチームと話し合い、すべてが順調であるように見えましたが、昨日まで、チームの1人（VBAまたはC＃を知らない）から、この新しいプロジェクトをC＃で開始するのではなく、前と同じアプローチ。彼らの懸念のいくつかは次のとおりです。

• これはかなり重要なプロジェクトであるため、動作する必要があります。C＃ソリューションは、既存のVBAベースのソリューションほど安定しておらず、動作しません。
• VBAソリューションで行った[I]処理を破棄し、C＃でゼロから再作成する必要があります。
• 誰かがVBAとC＃の2つの別々のソリューションをサポートする必要があります。[実際、彼らは現在サポートのための誰かを持っていません、私は通常介入します]。

今、私は彼らの懸念のいくつかをある程度理解することができますが、次のステップと彼らに何を戻すべきかについて決定する必要があります。個人的には、C＃で実装したいと思います。なぜなら、このような「エンタープライズ」ソリューションを構築する方が良いと思うからです。さらに、私はこの機会にC＃のスキルを磨きたいと思います。私は現在C＃の能力がVBAほどではないので、このようなプロジェクトを「次のレベル」に引き上げたいと思っています。

私は、C＃ソリューションがこのプロジェクトに適していると確信させるために使用できるポイントのリストを用意しました。

• 単体テスト。
• ソース管理。
• コードのドキュメント-他のサポート担当者への知識の伝達。
• コーディング規則の改善-ReSharperなどを使用して、命名と構造を強化できます。
• IDEの改善-エラーの強調表示によるミスの減少。
• アセンブリによるモジュール性の向上-将来のツールでの再利用を促進できます。
• 管理された展開-このツールの使用者を制御できます。

質問：説得するために他にどのような点を追加できますか？それとも、このプロジェクトで噛むことができる以上に噛み砕こうとしていますか？とにかく静かにしてVBAでやるべきですか？

「新しい」または「クールな」と思われるため、新しい言語に移行するだけでは判断の根拠にならないため、それを判断ポイントとして含めることを拒否しています。

また、私は言語としてのC＃とVBAのリテラル比較を求めていません。SOには多くの比較があるからです。

リストした3つの点は公平に思えます。

これはかなり重要なプロジェクトであるため、動作する必要があります。C＃ソリューションは、既存のVBAベースのソリューションほど安定しておらず、動作しません。

実際、後で、あなたは次のように語っています。「私は現在、VBAほどC＃の能力がないので、この機会にC＃のスキルを磨きたいです」（強調鉱山）。

言い換えれば、あなたは動作し、集中的なユーザーテストを経たソリューションを持っています。これをすべて投げ捨てて、よく知らない言語ですべてを書き直したいのです。問題が発生しましたか？

VBAソリューションで行った[I]処理を破棄し、C＃でゼロから再作成する必要があります。

絶対にすべきでないことを思い浮かべます。ユーザーテストと同様に、コードをスローしています。良くない。

誰かがVBAとC＃の2つの別々のソリューションをサポートする必要があります。[実際、彼らは現在サポートのための誰かを持っていません、私は通常介入します]。

VBAバージョンが引き続き使用される場合、書き換えはさらに問題になります。すでに機能し、機能をリファクタリングして機能を追加できるシステムが1つしかない場合に、注意が必要な2つの異なるシステムがあるのはなぜですか？

一方、あなたのポイントのいくつかは批判される可能性があります。

• 単体テスト。

  現在のプロジェクトもユニットテストできます。そのための便利なフレームワークがない場合は、作成してください。

• ソース管理。

  ソース管理はテキストを扱います。現在のコードはテキストなので、ソース管理を使用できます。

  言語、オペレーティングシステム、フレームワーク、またはエコシステムは完全に無関係です。Visual Studioのコード、LINQPadで数分でドラフトするコード、タスクを自動化するPowerShellスクリプト、データベーススキーマ、Excelマクロなど、記述するコードにソース管理を使用できます（また、使用する必要があります）。

• コードのドキュメント-他のサポート担当者への知識の伝達。

  同意した。

• コーディング規則の改善-ReSharperなどを使用して、命名と構造を強化できます。

  「より良い」を定義します。Excelのマクロのコーディング規則はありますか？「はい」の場合、それらを使用します。それらは他のどの製品よりも良くも悪くもありません。そうでない場合は、他の人が使用できるように、作成して公開します。2010年に投稿された質問への回答はかなり期待はずれに思えますが、それ以降に新しいツールが利用可能になる可能性があります。

  コーディング規約の重要な部分は、コミット時に実施する必要があることに注意してください。

• IDEの改善-エラーの強調表示によるミスの減少。

  同意した。Visual Studioでマクロを記述できないという事実は非常に残念です。

• アセンブリによるモジュール性の向上-将来のツールでの再利用を促進できます。

  現在の製品でもある程度のモジュール性を使用できると確信しています。

• 管理された展開-このツールの使用者を制御できます。

  同意した。

完全に書き直すのではなく、コードをマクロからVB.NETで記述された通常のアセンブリに段階的に移動する方法を検索する場合があります。VB.NETでなぜですか？3つの理由：

• VBAとC＃には違いがあるため、VBAとVB.NETの違いは少ないです。

• あなたはよりよいVBAを知っており、これだけではVB.NETの代わりに、C＃を使用するための十分な理由です。「C＃スキルを磨きたい」場合は、ビジネスに不可欠なものではなく、個人プロジェクトで実行してください。

• 言語から別の言語に書き換えると、潜在的なバグが発生します。このプロジェクトには必要ありません。

.NETアセンブリに移行すると、Visual Studioの便利な環境が得られ、便利な単体テスト、TFS、および他のプロジェクトで現在使用しているエラーの強調表示が可能になります。

同時に、コードを段階的に移動する場合、完全な書き換えのリスクを負うことはありません（つまり、多数の新しいバグのために、誰も使用したくないものを作成するのに4か月を費やします）。たとえば、特定の機能に取り組む必要がありますか？まず、この特定の機能を.NETに移行する方法を考えてください。

これはリファクタリングに非常に似ています。いくつかの新しい設計パターンと言語機能を学習したために全体を書き直す代わりに、現在作業しているコードを少し変更するだけです。

C＃への移行をサポートします。他の人があなたのポイントを非常によくカバーしているので、私は彼らが言ったことを再ハッシュしません。VBAに固執する正当な理由はたくさんあります。

しかし、私の雇用主の1人は、意味のあるドキュメントを作成するのに完璧な仕事をしました。設計上の決定が正当化されて実際に書き留められたので、すべてのソフトウェアプロジェクトだけがそれを持っているなら！私のポイント？設計上の決定事項の1つは、「私たちはこのプログラムをJavaで書くことを選択しています。だからこそ、氏は履歴書にx年のJavaの経験を積みたいと思っています」。それがC＃に移行する強い理由である場合、それは些細なこととして無視することはできません。ITチームに正当化するために使用する理由の1つになりえないのは、履歴書に何が欲しいかを気にせず、実際の製品を気にするからです。

考えるVBAの認識もあります。私はそれが真実ではないことを知っていますが、履歴書で「VBA」を見て、「この男はインターンの仕事で立ち往生しましたか？なぜ彼は実際の言語の経験がないのですか？」彼らは「VBA」を見て、「マクロ開発者に優れている」と考えています。あるセルから別のセルへのコピー/貼り付け、簡単な計算など。通常、VBAの実際の開発を評価できるのは、それを行った人であり、少なくとも私の経験では、ますます小さなプールのように思えます。お住まいの地域でのVBAの認識についてはより良い感覚をお持ちかもしれませんが、私はそれに対して多くの不当な否定性を見てきました。

私がゼロにしたい他のこと：MainMaはVBAとC＃の類似点に言及しました。これは絶対に真実であり、JMKの答えは、読み進めるためのいくつかのテクノロジーを提供します。VBAコードをC＃プロジェクトにコピー/貼り付けして、構文エラーがどの程度簡単に修正できるかを確認してください。

4,000行のコードがあるとおっしゃっていましたが、これはかなりの量のコードであり、おそらく多くの機能を含んでいます...しかし、それはたった 4,000行のコードです。コピーして貼り付けてみてください。これらの構文エラーをクリーンアップして作業プロジェクトを作成できたとしても、私は本当に驚かないでしょう。コードの詳細や利用可能な空き時間を知らなくても、週末にこれをノックアウトできると思います。

C＃のベストプラクティスに準拠していない可能性があり、非効率的かもしれませんが、C＃で機能的に同等のプロジェクトになります。また、新しいC＃コードが古いVBAコードと同じように欠陥を起こしにくいことを比較的確信できます。

自分の時間にVBAコードをC＃に変換すると、いくつかのことができます。

• 構文エラーを調べると、C＃の慣習（C＃で実際に作業するための一種の入門書）に慣れることができます。
• プラグインをExcelにロードする際の明らかな問題に光を当てます（Excelはおそらく要件であるため）。おそらく、あなたがまだ考慮していない問題があり、それが障害になる可能性があります。
• 顧客（ITチーム）に概念実証を表示します。現在の機能を備えた動作中のC＃プラグインがあることがわかると、C＃で認識されるリスクのレベルが低下します。

そして、ITの3つのポイントに戻ります。

•非常に重要なプロジェクトであるため、動作する必要があります-C＃ソリューションは、既存のVBAベースのソリューションほど安定しておらず、動作しません。

前述のように、C＃コードは同じ機能をカバーし、VBAと同じくらい安定しています。厳密に言えば、そこにあるあなたがバグ/欠陥や非効率性を導入チャンスが、それは考えにくいです。iOS / Objective CからAndroid / Javaへの移植についてではなく、構文の多くの類似点を共有し、まったく同じテクノロジーを利用できる2つの言語間の移植について話しています。

•VBAソリューションで行った[I]を破棄し、C＃でゼロから再作成する必要があります。

これにより、労力やコードを捨てることはありません。

•誰かがVBAとC＃の2つの別々のソリューションをサポートする必要があります。[実際、彼らは現在サポートのための誰かを持っていません、私は通常介入します]。

ソリューションは1つだけで、すべてC＃で作成できます。

全体として、顧客には多くのリスクがあります。そのリスクを軽減するための措置を講じることができれば、C＃への変更を受け入れる可能性があります。

私はそれを言うのは嫌いですが、あなたの議論は水を保持していません。

単体テスト。

これは非常に長い間解決された問題でした。多くの単体テストフレームワークがあります。一つを選ぶ。すでにこれを行っているはずです。IDEに統合され、他の優れた機能を提供するため、私たちのをお勧めします。

ソース管理

これは少し難しく、構築済みのソリューションはほとんどありませんが、実際にはコードをリポジトリに出し入れするだけです。これを行うための低額な方法がありますが、他にも優れたオプションがあります。

コード文書

また、解決された問題。MZ-Toolshasは、 .NetのXMLコメントドキュメントと非常によく似た動作をするXMLドキュメント機能です。

より良いコーディング規約

Visual StudioにReSharperプラグインがあるように、MZ-ToolsとRubberduckにもそのような機能があります。

より良いIDE

繰り返しますが、VBA IDEで使用できるプラグインがあります。

アセンブリによるモジュール性の向上-将来のツールでの再利用を促進できます。

また、解決された問題。いいえ、アセンブリを作成することはできませんが、他のVBAプロジェクトを参照することはできます。

管理された展開-このツールの使用者を制御できます。

ちょっとしたステッカーですが、プログラムにアクセスできるユーザーとアクセスできないユーザーを制御するコードを書く必要がありますが、おそらく（再び）セキュリティコードを既に書いているはずです。

展開に関しては、解決された問題でもあります。はい、それにはコードが必要ですが、使用/変更できる例があります。

これに加えて、ゼロから始めるという事実があります。私もジョエル・スポルスキーの記事をお勧めします。

彼らは、ソフトウェア会社が犯す可能性のある最悪の戦略的ミスを1つ犯すことでそれを行いました。

彼らはコードをゼロから書き直すことにしました。

あなたのITスタッフは正しいです。これを最初から書き直すべきではありません。現在のソリューションで問題を解決する必要があります。

さて、以上のことはすべて述べましたが、なぜC＃またはVB.Netでこれを行うのかを完全に理解できます。あなたが新しいプロジェクトを始めているなら、彼らは本当により良い解決策ですが、その音からすると、それは新しいプロジェクトではありません。最初からやり直して、それを壊すためにあなたが持っているものを改善することははるかに良いです。

この記事でMicrosoftが述べていることを指摘することができます。

機能を改善したりバグを修正したりするためにコードを更新するには、すべてのユーザーが、カスタマイズを使用しているすべてのファイルで、Officeアーティファクトを再メール、再構築、および再作業する必要があります。

この記事は、Officeをベースにしたものを開発するさまざまなアプローチに関するものであり、ディスカッションで他の賛否両論を取り上げることもできます。

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 Applicationオブジェクトの周りにIDisposableを実装するラッパークラスを作成し、usingこのオブジェクトを使用するときに必ず使用するようにします。

あなたの主張をする良い方法は、これを1時間ほど費やすことであり、短い時間であなたがコードを移植できる速さを実証し、これが良いアイデアであることを同僚に納得させます。

コードはほとんど変更されませんが、Visual Studio内にC＃プロジェクトを作成することで言及したすべての利点があります。

私は同じ立場にあり、非常に大きな（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コードを適切なソース管理に入れ、ワークブックのソースコードからビルドプロセスを作成することができます。

または-Excel VBA Code Cleanerなどの無料のユーティリティを使用します

私は現在、VBAほどC＃の能力がないので、この機会を利用してC＃のスキルを磨きたいと思います。このようなプロジェクトで「次のレベル」に引き上げたいと思います。

正直に言って。この決定に関与した他の人々とこの情報を共有する予定はありますか？そうでない場合、プロジェクトが失敗した場合、私はあなたに責任を負わせます。同様のプロジェクトがすでに作成され、フィールドに投入されているため、誰もが自分の頭の中で何が起こるかを予測しています。彼らは最後のものを構築するのにどれくらい時間がかかったかを知っており、あなたがより短い時間でこれを作成できると信じます（追加の要件に基づいて真実であるかもしれません）。新しい言語を習得するとともに、この責任を引き受ける準備はできていますか？

古いアプリをC＃にできるだけ早く移植することをお勧めします。たぶん、あなたは決定が下される前にプロセスで十分に学ぶことができます。少なくとも、新しい言語でスキルを向上させるという目標を達成し、それでもプロジェクトを時間通りに完了させることができます。

繰り返しになりますが、プロジェクトに強いことを感じ、プロジェクトの構築がすべて肩にかかっている場合は、思い通りに実行してください。許しよりも許しを得る方が常に簡単です。