Thành viên nhóm đặt câu hỏi chuyển từ VBA sang C #

Lý lịch

Năm ngoái, tôi đã được yêu cầu tạo ra một công cụ được sử dụng để lập kế hoạch kinh doanh cho khoảng 10 người dùng. Điều này đã được thực hiện thay mặt cho một nhóm CNTT khác đã "ký hợp đồng" công việc với tôi và do thời hạn dự án có một chút không dự tính về phía họ, tôi đã phải thực hiện nó một cách vội vàng.

Vào thời điểm đó, chúng tôi đã quyết định rằng cách nhanh nhất sẽ là tạo một sổ làm việc Excel bằng VBA và sau đó người dùng tải xuống sổ làm việc được tăng cường VBA này từ Intranet để sử dụng trên PC của họ. Excel là một hạn chế trong trường hợp này vì hệ thống lập kế hoạch (tức là cơ sở dữ liệu) mà chúng tôi sử dụng chỉ có thể tương tác thông qua bổ trợ Excel phải được tải cùng lúc khi sổ làm việc lập kế hoạch được mở. Tuy nhiên, VBA không phải là một hạn chế tại thời điểm đó.

Sổ làm việc tôi đã tạo khoảng 4.000 dòng mã VBA và trong khi tôi cố tách các lớp dữ liệu và trình bày, tôi không thể trong mọi trường hợp do thời hạn dự án. Thành thật mà nói, trong khi tôi tự hào khi tạo ra sổ làm việc này, tôi đồng thời hơi thất vọng vì nó có thể được thực hiện tốt hơn, cả về mã hóa và cả triển khai cho người dùng.

Hôm nay

Quay lại ngày hôm nay và nhóm CNTT một lần nữa đến với tôi để yêu cầu một sổ làm việc tương tự (vì vậy tôi có thể sử dụng lại các phần của sổ làm việc khác ở trên), nhưng lần này nó phức tạp hơn nhiều và sẽ được sử dụng bởi số lượng người dùng lớn hơn ( khoảng 200).

Tuy nhiên, lần này, nó được lên kế hoạch tốt hơn một chút và tôi có thể thấy rằng chúng ta có thêm một chút thời gian để lên kế hoạch cho mọi thứ. Dựa trên điều này, tôi đã nghĩ về giải pháp và cơ sở hạ tầng vì lập trình cho 100 người dùng có nhiều tác động hơn so với 10 người dùng. Do đó, tôi đã đề xuất với nhóm rằng có lẽ chúng ta nên xem xét việc di chuyển mã hiện có sang giải pháp C # để chúng ta có thể quản lý mã theo cách tinh tế hơn. Tôi vẫn đang xem nó như một phần bổ trợ được viết bằng VSTO / Excel-DNA, sau đó có thể được triển khai cho người dùng.

Tôi đã thảo luận vấn đề này với nhóm CNTT hai tuần trước và mọi thứ dường như đều ổn, cho đến ngày hôm qua tôi nhận được thư từ một trong số nhóm (không biết VBA hoặc C #) đặt câu hỏi tại sao chúng ta nên bắt đầu dự án mới này trong C # so với sử dụng cách tiếp cận như trước đây. Một số mối quan tâm của họ là:

• Đây là một dự án khá quan trọng vì vậy nó phải hoạt động - giải pháp C # sẽ không ổn định hoặc hoạt động tốt như giải pháp dựa trên VBA hiện có.
• Chúng tôi sẽ phải vứt bỏ những gì chúng tôi [tôi] đã làm trong giải pháp VBA và tạo lại nó từ đầu trong C #.
• Ai đó sẽ phải hỗ trợ hai giải pháp riêng biệt, một trong VBA và một trong C #. [thực ra, hiện tại họ không có ai hỗ trợ, tôi thường bước vào].

Bây giờ, tôi có thể hiểu một số mối quan tâm của họ ở một mức độ nào đó, nhưng tôi cần đi đến quyết định về các bước tiếp theo và những gì cần quay lại với họ. Cá nhân, tôi muốn triển khai trong C # vì tôi cảm thấy việc cho vay tốt hơn để xây dựng giải pháp "Doanh nghiệp" như thế này. Hơn nữa, tôi muốn tận dụng cơ hội này để cải thiện các kỹ năng C # của mình vì hiện tại tôi không đủ năng lực trong C # vì tôi là VBA và tôi muốn một dự án như thế này đưa tôi đến "cấp độ tiếp theo".

Tôi đã chuẩn bị một danh sách các điểm mà tôi có thể sử dụng để thử và thuyết phục họ rằng giải pháp C # sẽ tốt hơn cho dự án này, đây là những gì tôi có cho đến nay:

• Kiểm tra đơn vị.
• Kiểm soát nguồn.
• Mã tài liệu - để chuyển giao kiến ​​thức cho những người hỗ trợ khác.
• Các quy ước mã hóa tốt hơn - có thể sử dụng những thứ như ReSharper để thực thi việc đặt tên và cấu trúc tốt hơn.
• IDE tốt hơn - ít lỗi hơn do đánh dấu lỗi.
• Nhiều mô-đun hơn thông qua các hội đồng - có thể thúc đẩy tái sử dụng trong các công cụ trong tương lai.
• Quản lý triển khai - có thể kiểm soát công cụ này được sử dụng bởi ai.

Câu hỏi: Tôi có thể thêm những điểm nào khác để thuyết phục họ? Hay tôi đang cố gắng cắn nhiều hơn tôi có thể nhai với dự án này? Tôi có nên giữ im lặng và làm điều đó trong VBA không?

Tôi biết rằng việc chuyển sang một ngôn ngữ mới bởi vì "mới hơn" hoặc được coi là "mát mẻ" hơn không nên là cơ sở cho một quyết định và vì vậy tôi đã chống lại việc đưa nó vào như một điểm quyết định - đây là về sự thật.

Ngoài ra, tôi không yêu cầu so sánh theo nghĩa đen giữa C # và VBA là ngôn ngữ, vì có rất nhiều so sánh về SO.

Ba điểm bạn liệt kê có vẻ công bằng:

Đây là một dự án khá quan trọng vì vậy nó phải hoạt động - giải pháp C # sẽ không ổn định hoặc hoạt động tốt như giải pháp dựa trên VBA hiện có.

Thật vậy, sau này, bạn nói: "Tôi muốn nhân cơ hội này cải thiện các kỹ năng C # của tôi vì hiện tại tôi không đủ năng lực trong C # như tôi là VBA " (nhấn mạnh của tôi).

Nói cách khác, bạn có một giải pháp hoạt động và trải qua quá trình kiểm tra người dùng chuyên sâu. Bạn muốn ném tất cả những thứ này và viết lại mọi thứ bằng ngôn ngữ mà bạn không biết rõ. Thấy vấn đề?

Chúng tôi sẽ phải vứt bỏ những gì chúng tôi [tôi] đã làm trong giải pháp VBA và tạo lại nó từ đầu trong C #.

Những điều bạn không bao giờ nên làm trong tâm trí. Bạn đang ném mã, cũng như kiểm tra người dùng. Không phải là một điều tốt.

Ai đó sẽ phải hỗ trợ hai giải pháp riêng biệt, một trong VBA và một trong C #. [thực ra, hiện tại họ không có ai hỗ trợ, tôi thường bước vào].

Nếu phiên bản VBA vẫn sẽ được sử dụng, việc viết lại thực sự thậm chí còn có vấn đề hơn. Tại sao bạn có hai hệ thống khác nhau đòi hỏi sự chú ý của bạn, khi bạn có thể chỉ có một hệ thống đã hoạt động và bạn có thể cấu trúc lại và thêm các tính năng vào?

Mặt khác, một số điểm của bạn có thể bị chỉ trích:

• Kiểm tra đơn vị.

  Bạn có thể đơn vị kiểm tra dự án hiện tại của bạn là tốt. Nếu không có khung thuận tiện cho việc đó, hãy tạo một cái.

• Kiểm soát nguồn.

  Kiểm soát nguồn thỏa thuận với văn bản. Mã hiện tại của bạn là văn bản, do đó bạn có thể sử dụng kiểm soát nguồn cho nó.

  Ngôn ngữ, hệ điều hành, khung hoặc hệ sinh thái hoàn toàn không liên quan. Bạn có thể (và nên) sử dụng kiểm soát nguồn cho bất kỳ mã nào bạn viết: mã trong Visual Studio hoặc một đoạn mã bạn soạn thảo trong vài phút trong LINQPad hoặc tập lệnh PowerShell để tự động hóa tác vụ hoặc lược đồ cơ sở dữ liệu hoặc macro Excel.

• Mã tài liệu - để chuyển giao kiến ​​thức cho những người hỗ trợ khác.

  Đã đồng ý.

• Các quy ước mã hóa tốt hơn - có thể sử dụng những thứ như ReSharper để thực thi việc đặt tên và cấu trúc tốt hơn.

  Xác định "tốt hơn". Có quy ước mã hóa cho các macro của Excel không? Nếu có, sử dụng chúng: chúng không tốt hơn hoặc kém hơn bất kỳ loại nào khác. Nếu không, hãy tạo chúng và xuất bản chúng để người khác cũng có thể sử dụng chúng. Các câu trả lời cho một câu hỏi được đăng vào năm 2010 có vẻ khá đáng thất vọng, nhưng có thể có các công cụ mới có sẵn kể từ đó.

  Lưu ý rằng phần quan trọng của các quy ước mã hóa là chúng phải được thực thi theo cam kết.

• IDE tốt hơn - ít lỗi hơn do đánh dấu lỗi.

  Đã đồng ý. Việc chúng ta không thể viết macro trong Visual Studio là rất đáng tiếc.

• Nhiều mô-đun hơn thông qua các hội đồng - có thể thúc đẩy tái sử dụng trong các công cụ trong tương lai.

  Tôi khá chắc chắn rằng sản phẩm hiện tại của bạn cũng có thể sử dụng một số mức độ mô đun.

• Quản lý triển khai - có thể kiểm soát công cụ này được sử dụng bởi ai.

  Đã đồng ý.

Thay vì viết lại hoàn toàn, bạn có thể tìm kiếm một cách để dần dần chuyển mã từ macro sang một cụm thông thường được viết bằng VB.NET. Tại sao trong VB.NET? Ba lý do:

• Có ít sự khác biệt giữa VBA và VB.NET vì có giữa VBA và C #.

• Bạn biết VBA tốt hơn và đây là lý do chính đáng để sử dụng VB.NET thay vì C #. Nếu bạn muốn "cải thiện kỹ năng C # của mình", hãy thực hiện nó với các dự án cá nhân của bạn, chứ không phải kinh doanh quan trọng.

• Bất kỳ viết lại từ một ngôn ngữ sang ngôn ngữ khác dẫn đến lỗi tiềm năng. Bạn không cần điều đó cho dự án này.

Chuyển sang lắp ráp .NET có thể cung cấp cho bạn môi trường thuận tiện của Visual Studio, với thử nghiệm đơn vị thuận tiện, TFS và lỗi làm nổi bật bạn hiện đang sử dụng trong các dự án khác.

Đồng thời, nếu bạn di chuyển mã của mình từng bước một, bạn sẽ không gặp rủi ro khi viết lại hoàn toàn (nghĩa là mất bốn tháng để tạo ra thứ gì đó không ai muốn sử dụng vì số lượng lỗi mới cao). Ví dụ, bạn cần phải làm việc trên một tính năng cụ thể? Hãy nghĩ làm thế nào bạn có thể di chuyển tính năng đặc biệt này sang .NET trước.

Điều này khá giống với tái cấu trúc. Thay vì viết lại toàn bộ bởi vì bạn đã học được một số mẫu thiết kế mới và các tính năng ngôn ngữ, bạn chỉ cần thực hiện các thay đổi nhỏ trên mã mà bạn làm việc ngay bây giờ.

Tôi sẽ hỗ trợ đi đến C #. Những người khác đã bảo vệ quan điểm của bạn rất tốt, vì vậy tôi sẽ không kiểm tra lại những gì họ đã nói. Chắc chắn có rất nhiều lý do tốt để gắn bó với VBA.

Tuy nhiên , một trong những người chủ của tôi đã làm một công việc hoàn hảo để tạo ra tài liệu có ý nghĩa. Nhiều đến nỗi các quyết định thiết kế đã thực sự được viết ra với sự biện minh - nếu chỉ có tất cả các dự án phần mềm có điều đó! Quan điểm của tôi? Một trong những quyết định thiết kế là "Chúng tôi đang chọn viết chương trình này bằng Java, bởi vì ông muốn và sẽ đưa x năm kinh nghiệm Java vào hồ sơ xin việc của mình". Nếu đó là một lý do mạnh mẽ để bạn chuyển sang C #, thì đó không thể là một sự tầm thường. Đó không thể là một trong những lý do bạn sử dụng để biện minh cho nhóm CNTT, bởi vì họ không thực sự quan tâm đến những gì bạn muốn trong hồ sơ của bạn, họ quan tâm đến sản phẩm làm việc.

Cũng có nhận thức về VBA để suy nghĩ. Tôi biết điều đó không đúng, nhưng tôi biết khá nhiều người nhìn thấy 'VBA' trong hồ sơ xin việc và nghĩ "Cái gì, anh chàng này bị kẹt khi làm việc thực tập? Tại sao anh ta không có kinh nghiệm với ngôn ngữ thực sự ?" Họ thấy 'VBA' và nghĩ 'nhà phát triển vĩ mô excel'. Giống như sao chép / dán một ô này sang ô khác, thực hiện các phép tính đơn giản, v.v. Thông thường, loại người có thể đánh giá cao sự phát triển thực sự trong VBA là những người đã thực hiện nó, và đó dường như là một nhóm ngày càng nhỏ, ít nhất là theo kinh nghiệm của tôi. Bạn có thể hiểu rõ hơn về nhận thức về VBA trong khu vực của bạn, nhưng tôi đã thấy rất nhiều tiêu cực không chính đáng đối với nó.

Một điều khác mà tôi muốn hướng đến: MainMa đã đề cập đến sự tương đồng giữa VBA và C #. Điều này là hoàn toàn đúng và câu trả lời của JMK cung cấp một vài công nghệ để đọc tiếp. Hãy thử sao chép / dán mã VBA của bạn vào dự án C # và xem các lỗi cú pháp trông dễ sửa như thế nào.

Bạn nói rằng bạn có 4.000 dòng mã, đây là một đoạn mã tốt và có thể bao gồm rất nhiều chức năng ... nhưng đó chỉ là 4.000 dòng mã. Hãy thử sao chép và dán điều. Tôi thực sự sẽ không ngạc nhiên nếu bạn có thể dọn sạch những lỗi cú pháp đó và có một dự án đang hoạt động. Nếu không biết chi tiết về mã của bạn hoặc lượng thời gian rảnh dành cho bạn, tôi sẽ nghĩ bạn có thể loại bỏ điều này trong một ngày cuối tuần.

Nó có thể không tuân theo các thực tiễn tốt nhất của C #, nó có thể không hiệu quả, nhưng bạn sẽ kết thúc với một dự án tương đương về chức năng trong C #. Bạn cũng có thể tương đối chắc chắn rằng mã C # mới của bạn không dễ bị lỗi hơn mã VBA cũ của bạn.

Chuyển đổi mã VBA của bạn thành C # theo thời gian của riêng bạn sẽ giúp bạn thực hiện một số điều:

• Khi bạn nghiên cứu lỗi cú pháp, bạn sẽ trở nên quen thuộc hơn với thực tiễn C # - một loại mồi để thực sự hoạt động trong C #
• Nó sẽ làm sáng tỏ mọi vấn đề rõ ràng khi tải plugin vào excel (vì excel có lẽ vẫn là một yêu cầu). Có lẽ có một vấn đề bạn chưa xem xét có thể là một rào cản.
• Nó sẽ hiển thị một bằng chứng về khái niệm cho khách hàng của bạn (nhóm CNTT). Nếu họ có thể thấy bạn có trình cắm C # hoạt động với chức năng hiện tại, thì bạn sẽ giảm mức độ rủi ro nhận thức của họ với C #.

Và quay trở lại ba điểm của CNTT:

• Đây là một dự án khá quan trọng vì vậy nó phải hoạt động - giải pháp C # sẽ không ổn định hoặc hoạt động tốt như giải pháp dựa trên VBA hiện có.

Như đã đề cập, mã C # của bạn sẽ có cùng chức năng và ổn định như VBA của bạn. Nói đúng ra, có là một cơ hội bạn giới thiệu lỗi / khuyết tật hoặc không hiệu quả, nhưng điều đó dường như khó xảy ra. Chúng ta không nói về một cổng từ iOS / Objective C sang Android / Java, chúng ta đang nói về một cổng giữa hai ngôn ngữ có nhiều điểm tương đồng về cú pháp và có thể sử dụng cùng một công nghệ - sổ làm việc excel.

• Chúng ta sẽ phải vứt bỏ những gì chúng ta [tôi] đã làm trong giải pháp VBA và tạo lại nó từ đầu trong C #.

Với điều này, bạn sẽ không vứt bỏ bất kỳ nỗ lực hoặc mã.

• Ai đó sẽ phải hỗ trợ hai giải pháp riêng biệt, một trong VBA và một trong C #. [thực ra, hiện tại họ không có ai hỗ trợ, tôi thường bước vào].

Bạn sẽ chỉ có 1 giải pháp, tất cả trong C #.

Tất cả trong tất cả, khách hàng của bạn nhìn thấy rất nhiều rủi ro. Nếu bạn có thể thực hiện các bước để giảm thiểu rủi ro đó, họ có thể chấp nhận thay đổi thành C #.

Tôi ghét phải nói điều đó, nhưng lập luận của bạn không giữ được nước.

Kiểm tra đơn vị.

Đây là một vấn đề được giải quyết trong một thời gian rất dài. Có rất nhiều khung kiểm tra đơn vị ngoài kia. Chọn một. Bạn nên làm điều này đã. Tôi khuyên chúng ta , vì nó tích hợp vào IDE và cung cấp các tính năng tuyệt vời khác.

Kiểm soát nguồn

Đây là một khó khăn hơn một chút, có một vài giải pháp được xây dựng sẵn, nhưng thực sự chỉ là vấn đề đưa mã của bạn vào và ra khỏi kho lưu trữ. Đây là một cách thấp để làm điều đó , nhưng cũng có những lựa chọn khác tốt hơn .

Mã tài liệu

Cũng là một vấn đề được giải quyết. MZ-Toolshas một tính năng tài liệu XML hoạt động rất giống với tài liệu nhận xét XML của .Net.

Công ước mã hóa tốt hơn

Giống như Visual Studio có plugin ReSharper, cả MZ-Tools và Rubberduck đều có các tính năng như vậy.

IDE tốt hơn

Một lần nữa, có các plugin có sẵn cho VBA IDE.

Nhiều mô-đun hơn thông qua các hội đồng - có thể thúc đẩy tái sử dụng trong các công cụ trong tương lai.

Cũng là một vấn đề được giải quyết. Không, bạn không thể tạo các hội đồng, nhưng bạn có thể tham khảo các Dự án VBA khác.

Quản lý triển khai - có thể kiểm soát công cụ này được sử dụng bởi ai.

Một nhãn dán nhỏ, bạn sẽ cần viết mã để kiểm soát ai có thể truy cập chương trình và ai không thể, nhưng bạn (một lần nữa) có lẽ đã có mã bảo mật bằng văn bản.

Đối với việc triển khai, nó cũng là một vấn đề được giải quyết. Vâng, nó yêu cầu mã, nhưng có những ví dụ ngoài kia mà bạn có thể sử dụng / sửa đổi .

Trên hết, đây là thực tế mà bạn sẽ bắt đầu lại từ đầu. Tôi cũng sẽ giới thiệu bài viết của Joel Spolsky .

Họ đã làm điều đó bằng cách phạm sai lầm chiến lược tồi tệ nhất mà bất kỳ công ty phần mềm nào cũng có thể mắc phải:

Họ quyết định viết lại mã từ đầu.

Những người IT của bạn nói đúng. Bạn không nên viết lại từ đầu. Bạn nên giải quyết các vấn đề với giải pháp hiện tại của bạn.

Bây giờ, với tất cả những gì đã nói, tôi hoàn toàn có thể hiểu lý do tại sao bạn muốn làm điều này trong C # hoặc VB.Net. Chúng thực sự là một giải pháp tốt hơn, nếu bạn đang bắt đầu một dự án mới , nhưng từ âm thanh của nó, đó không phải là một dự án mới. Tốt hơn hết là cải thiện những gì bạn có sau đó để phá vỡ nó bằng cách bắt đầu lại.

Bạn có thể chỉ ra rằng ngay cả Microsoft khẳng định trong này bài viết:

Cập nhật mã để cải thiện các tính năng hoặc sửa lỗi sẽ yêu cầu tạo phẩm Office phải được gửi lại qua email, cấu trúc lại và làm việc lại bởi mỗi người dùng và trong mỗi tệp đang sử dụng tùy chỉnh.

Bài viết nói về các cách tiếp cận khác nhau của việc phát triển công cụ dựa trên Office, có thể bạn cũng có thể lấy một số ưu và nhược điểm khác từ nó trong cuộc thảo luận của mình.

Nó thực sự phụ thuộc vào cách bạn dự định chuyển sang C # (tức là bạn sẽ sử dụng công nghệ nào).

Nếu bạn định sử dụng OpenXML, thì bạn đang nói tổng thể viết lại, nếu bạn có một giải pháp hiệu quả, thì không nên.

Nếu bạn đang nói về việc sử dụng Interop, bạn có thể thấy rằng quá trình này trơn tru một cách đáng ngạc nhiên. Tôi đã chuyển rất nhiều mã từ VBA sang C # (với Interop) trong quá khứ và một khi bạn đã cắm vào sổ làm việc, như vậy:

var excelApplication = new Application();
var workbook = excelApplication.Workbooks.Open(@"C:\location.xlsx");

Trong rất nhiều trường hợp, bạn có thể sao chép / pasta mã VBA của mình, gọi tiền tố hàm workbook., thay thế Dim bằng var vv khi thích hợp và thêm dấu chấm phẩy vào cuối.

Về cơ bản, đó là cùng một Khung bên dưới (Excel), bạn chỉ đang thay đổi Cú pháp từ VBA sang C #.

Khi bạn hoàn tất, hãy nhớ lưu và đóng ứng dụng:

workbook.Save();
excelApplication.Quit();

Sau đó phát hành ứng dụng với Thống chế:

Marshal.ReleaseComObject(excelApplication);

Tôi có thể sẽ viết một lớp trình bao bọc triển khai IDis Dùng xung quanh đối tượng Ứng dụng Excel, sau đó hãy chắc chắn sử dụng usingkhi đối tượng này được sử dụng.

Một cách tốt để làm cho trường hợp của bạn là dành một giờ hoặc lâu hơn để làm điều này, trong một khoảng thời gian ngắn sẽ chứng minh bạn có thể chuyển mã nhanh như thế nào và thuyết phục các đồng nghiệp của bạn rằng đây là một ý tưởng tốt.

Mã sẽ vẫn không thay đổi theo một cách nào đó, nhưng bạn có tất cả những lợi ích bạn đã đề cập khi có dự án C # trong Visual Studio.

Tôi đang ở vị trí tương tự, có một ứng dụng rất lớn (20k + dòng mã VBA) được tích hợp trong sổ làm việc EXCEL. Khi thử nghiệm với Office 2013, đơn giản là nó không hoạt động, được cho là do những thay đổi trong chuỗi sự kiện khởi động trong mô hình văn phòng mới và có thể thực thi EMET nghiêm ngặt hơn. Do đó, tôi đang ở vị trí thực hiện chuyển đổi sự cố sang C # và VB.NET trước khi triển khai Office 2013 trong năm nay. Các sách bài tập khác, đơn giản hơn (tăng cường VBA) được sử dụng xung quanh tổ chức đã không được miễn dịch, một số làm việc và một số khác thì không.

Các lỗi xảy ra trong sự kiện Workbook_Open , trong đó các trang tính của sổ làm việc không còn nữa và trong mã EXCEL nội bộ trước khi bất kỳ mã VBA nào được tham chiếu.

Thoải mái trong tất cả các VBA, C # và VB.NET Tôi đang viết chuyển đổi trong cả hai phần sau. Mã khung đang được viết bằng C # vì các thành ngữ ngôn ngữ cho phép tôi viết các cấu trúc chức năng nhất định trong ngôn ngữ đó nhanh hơn 3-4 lần so với VB.NET. Phần lớn mã nằm trong VB.NET vì khi đó phần viết lại của tôi ít mở rộng hơn và có một số thành ngữ nhất định không có trong C #.

Trước khi đưa ra bất kỳ quyết định nào, tôi thực sự khuyên bạn nên kiểm tra ứng dụng hiện có với VĂN PHÒNG 2013 và mức độ thực thi EMET đầy đủ nhất mà tổ chức dự kiến ​​sẽ triển khai trong 2-3 năm tới. Bạn có thể, giống như tôi, phát hiện ra rằng ứng dụng hiện tại sẽ không chạy trong môi trường đó mà không cần viết lại - trong trường hợp đó, việc viết lại cũng có thể có trong DOT NET và VSTO.

Phụ lục:

Viết một tiện ích trích xuất tự động nhỏ, lặp lại toàn bộ nội dung của VBA trong sổ làm việc và xuất tất cả các mô-đun, lớp và biểu mẫu sang tệp, là 1-2 ngày làm việc, tùy thuộc vào mức độ ưa thích của bạn. Tương tự như vậy với ngược lại để nhập các tệp từ một thư mục vào một sổ làm việc trống. Với hai điều này, hoàn toàn có thể có tất cả mã VBA của bạn trong kiểm soát nguồn thích hợp và có quy trình Xây dựng từ mã nguồn cho sổ làm việc của bạn.

HOẶC - sử dụng tiện ích miễn phí, chẳng hạn như Excel VBA Code Cleaner

Tôi muốn tận dụng cơ hội này để cải thiện các kỹ năng C # của mình vì hiện tại tôi không đủ năng lực trong C # vì tôi là VBA và tôi muốn một dự án như thế này đưa tôi đến "cấp độ tiếp theo".

Hãy trung thực. Bạn có kế hoạch chia sẻ thông tin này với những người khác có liên quan trong việc đưa ra quyết định này không? Nếu không, tôi sẽ đổ lỗi cho bạn nếu dự án thất bại. Vì một dự án tương tự đã được tạo ra và đưa vào lĩnh vực này, mọi người đã hình thành những gì họ mong đợi sẽ xảy ra trong tâm trí của chính họ. Họ biết phải mất bao lâu để xây dựng cái cuối cùng và sẽ tin rằng bạn có thể tạo cái này trong thời gian ngắn hơn (điều này có thể đúng hoặc không dựa trên các yêu cầu bổ sung). Bạn đã sẵn sàng để đảm nhận trách nhiệm này cùng với việc học một ngôn ngữ mới?

Tôi khuyên bạn nên chuyển ứng dụng cũ sang C # ASAP. Có lẽ bạn có thể học đủ trong quá trình trước khi đưa ra quyết định. Ít nhất bạn sẽ đạt được mục tiêu tăng kỹ năng của mình với ngôn ngữ mới và vẫn hoàn thành dự án đúng hạn.

Sau đó, một lần nữa, nếu bạn cảm thấy mạnh mẽ về nó và xây dựng dự án là tất cả nằm trên vai của bạn, hãy làm theo cách bạn muốn. Luôn luôn dễ dàng để có được sự tha thứ hơn là sự cho phép.