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 #을 모르는 팀 중 하나로부터 C # 에서이 새로운 프로젝트를 시작 해야하는 이유와 이전과 같은 접근 방식. 그들의 우려 중 일부는 다음과 같습니다.

• C # 솔루션은 기존 VBA 기반 솔루션만큼 안정적이거나 작동하지 않을 것이므로 상당히 중요한 프로젝트이므로 작동해야합니다.
• VBA 솔루션에서 수행 한 작업을 버리고 C #에서 처음부터 다시 만들어야합니다.
• 누군가 VBA와 C #의 두 가지 개별 솔루션을 지원해야합니다. [실제로, 그들은 현재 지원할 사람이 없다. 나는 보통 들어간다].

이제, 나는 그들의 우려의 일부를 어느 정도 이해할 수 있지만, 다음 단계와 그로 돌아 가야 할 단계에 대한 결정을 내려야합니다. 개인적으로 C #으로 구현하고 싶습니다. "Enterprise"솔루션을 구축하는 것이 더 나을 것이라고 생각하기 때문입니다. 또한, 저는 현재 VBA만큼 C #에 능숙하지 않으며이 같은 프로젝트를 통해 "다음 단계"로 나아 가기 위해이 기회를 C # 기술에 적용하고 싶습니다.

C # 솔루션 이이 프로젝트에 더 좋을 것이라고 생각하고 설득하는 데 사용할 수있는 포인트 목록을 준비했습니다.

• 단위 테스트.
• 소스 컨트롤.
• 코드 문서-다른 지원 담당자에게 지식을 전달합니다.
• 더 나은 코딩 규칙-ReSharper와 같은 것을 사용하여 더 나은 이름과 구조를 적용 할 수 있습니다.
• 더 나은 IDE-오류 강조 표시로 인한 실수가 줄어 듭니다.
• 어셈블리를 통한 더 많은 모듈화-향후 도구에서 재사용을 촉진 할 수 있습니다.
• 관리 배포-이 도구가 사용되는 사람을 제어 할 수 있습니다.

질문 : 설득하기 위해 다른 점을 추가 할 수 있습니까? 아니면이 프로젝트로 씹을 수있는 것보다 더 많이 물려고합니까? 어쨌든 VBA에서 조용히해야합니까?

나는 "새로운 언어"나 "더 시원한"언어가 결정의 기초가되어서는 안되며, 따라서 언어를 결정 지점으로 포함시키지 않기 때문에 새로운 언어로 옮기는 것만 알고 있습니다. 이것은 사실에 관한 것입니다.

또한 SO에 대한 많은 비교가 있기 때문에 언어로 C #과 VBA를 리터럴 비교를 요구하지 않습니다.

당신이 열거 한 세 가지 점은 공정 해 보입니다 :

C # 솔루션은 기존 VBA 기반 솔루션만큼 안정적이거나 작동하지 않을 것이므로 상당히 중요한 프로젝트이므로 작동해야합니다.

실제로, 나중에, 당신은 말합니다 : "저는 현재 VBA만큼 C #에 능숙하지 않기 때문에이 기회를 C # 기술에 적용하고 싶습니다 "(강조 광산).

다시 말해, 집중적 인 사용자 테스트를 거친 솔루션이 있습니다. 이 모든 것을 버리고 잘 모르는 언어로 모든 것을 다시 쓰고 싶습니다. 문제가 보입니까?

VBA 솔루션에서 수행 한 작업을 버리고 C #에서 처음부터 다시 만들어야합니다.

하지 말아야 할 것들이 떠 오릅니다. 사용자 테스트뿐만 아니라 코드를 던지고 있습니다. 좋은 것은 아닙니다.

누군가 VBA와 C #의 두 가지 개별 솔루션을 지원해야합니다. [실제로, 그들은 현재 지원할 사람이 없다. 나는 보통 들어간다].

VBA 버전이 여전히 사용된다면, 재 작성은 더욱 문제가됩니다. 이미 작동하고 기능을 리팩토링하고 기능을 추가 할 수있는 시스템이 하나만있을 때주의가 필요한 두 개의 개별 시스템이있는 이유는 무엇입니까?

반면에, 당신의 요점 중 일부는 비난받을 수 있습니다.

• 단위 테스트.

  현재 프로젝트를 단위 테스트 할 수도 있습니다. 편리한 프레임 워크가 없으면 하나를 만드십시오.

• 소스 컨트롤.

  소스 컨트롤은 텍스트를 처리합니다. 현재 코드는 텍스트이므로 소스 컨트롤을 사용할 수 있습니다.

  언어, 운영 체제, 프레임 워크 또는 생태계는 전혀 관련이 없습니다. Visual Studio의 코드 또는 LINQPad에서 몇 분 안에 작성하는 코드 조각, 또는 작업을 자동화하는 PowerShell 스크립트, 데이터베이스 스키마 또는 Excel 매크로 등 작성한 코드에 대해 소스 제어를 사용할 수 있습니다 .

• 코드 문서-다른 지원 담당자에게 지식을 전달합니다.

  동의했다.

• 더 나은 코딩 규칙-ReSharper와 같은 것을 사용하여 더 나은 이름과 구조를 적용 할 수 있습니다.

  "더 나은"을 정의하십시오. Excel 매크로에 대한 코딩 규칙이 있습니까? 그렇다면, 그것들을 사용하십시오 : 그것들은 다른 것보다 낫거나 나쁘지 않습니다. 그렇지 않은 경우 다른 사람도 사용할 수 있도록 하나를 만들어 게시하십시오. 2010 년에 게시 된 질문에 대한 답변 은 다소 실망스러워 보이지만 그 이후로 사용할 수있는 새로운 도구가있을 수 있습니다.

  코딩 규칙의 중요한 부분은 커밋시 적용되어야한다는 것입니다.

• 더 나은 IDE-오류 강조 표시로 인한 실수가 줄어 듭니다.

  동의했다. Visual Studio에서 매크로를 작성할 수 없다는 사실 은 매우 불행합니다.

• 어셈블리를 통한 더 많은 모듈화-향후 도구에서 재사용을 촉진 할 수 있습니다.

  현재 제품에서 어느 정도의 모듈성을 사용할 수 있다고 확신합니다.

• 관리 배포-이 도구가 사용되는 사람을 제어 할 수 있습니다.

  동의했다.

완전한 재 작성 대신 매크로에서 VB.NET으로 작성된 일반 어셈블리로 코드 를 점진적으로 이동 시키는 방법을 검색 할 수 있습니다 . 왜 VB.NET에 있습니까? 세 가지 이유 :

• VBA와 C # 간에는 VBA와 VB.NET간에 차이가 적습니다.

• 당신 더 나은 VBA를 알고, 혼자 대신 C 번호의 VB.NET을 사용하는 것이 이유입니다. "C # 기술을 향상 시키려면"업무상 중요한 것이 아니라 개인 프로젝트로 수행하십시오.

• 언어에서 다른 언어로 다시 쓰면 잠재적 인 버그가 발생합니다. 이 프로젝트에는 필요하지 않습니다.

.NET 어셈블리로 이동하면 현재 다른 프로젝트에서 사용하는 편리한 단위 테스트, TFS 및 오류 강조 표시를 통해 Visual Studio의 편리한 환경을 제공 할 수 있습니다.

동시에, 코드를 단계별로 이동하더라도 완전한 재 작성의 위험이 없습니다 (즉, 새로운 버그가 많기 때문에 아무도 사용하고 싶지 않은 것을 만들기 위해 4 개월을 소비 함). 예를 들어 특정 기능에 대해 작업해야합니까? 먼저이 특정 기능을 .NET으로 옮길 수있는 방법을 생각해보십시오.

이것은 리팩토링과 매우 유사합니다. 몇 가지 새로운 디자인 패턴과 언어 기능을 배웠기 때문에 전체 내용을 다시 작성하는 대신 현재 작업중인 코드를 약간만 변경하면됩니다.

C #으로 이동하는 것을 지원합니다. 다른 사람들은 당신의 요점을 잘 다루었으므로 나는 그들이 말한 것을 다시는 말하지 않을 것입니다. VBA를 고수해야 할 많은 이유가 있습니다.

그러나 내 고용주 중 한 명이 의미있는 문서를 작성하는 데 완벽한 일을했습니다. 모든 소프트웨어 프로젝트에만 해당되는 경우 설계 결정이 정당화되어 실제로 작성되었습니다. 내 입장? 디자인 결정 중 하나는 "우리는이 프로그램을 Java로 작성하기로 결정했습니다. 왜냐하면 So-and-so는 그의 이력서에 x 년의 Java 경험을주기 원하기 때문입니다." 이것이 C #으로 전환해야하는 강력한 이유라면 사소한 것으로 무시할 수 없습니다. IT 팀에게 정당성을 부여하는 데 사용하는 이유 중 하나 일 수는 없습니다. 이력서에서 원하는 것을 실제로 신경 쓰지 않고 작동하는 제품을 걱정하기 때문입니다.

VBA에 대한 인식도 있습니다. 나는 그것이 사실이 아니라는 것을 알고 있지만, 이력서에서 'VBA'를 보는 상당히 많은 사람들을 알고 있으며 "이 사람은 인턴 작업을 계속하고 있습니까? 왜 실제 언어에 대한 경험이 없습니까?" 그들은 '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의 세 가지 요점으로 돌아가십시오.

• 매우 중요한 프로젝트이므로 작동해야합니다. C # 솔루션은 기존 VBA 기반 솔루션만큼 안정적이거나 작동하지 않습니다.

앞에서 언급했듯이 C # 코드는 동일한 기능을 수행하며 VBA와 마찬가지로 안정적입니다. 엄밀히 말하면, 거기 이다 당신이 버그 / 결함이나 비 효율성을 소개하는 기회,하지만 그건 아닌 것 같습니다. 우리는 iOS / Objective C에서 Android / Java 로의 포트에 대해 이야기하는 것이 아니라 구문에서 많은 유사점을 공유하고 정확히 동일한 기술 인 Excel 통합 문서를 사용할 수있는 두 언어 사이의 포트에 대해 이야기하고 있습니다.

• VBA 솔루션에서 수행 한 작업을 버리고 C #에서 처음부터 다시 만들어야합니다.

이를 통해 노력이나 코드를 버리지 않습니다.

• 누군가 VBA와 C #의 두 가지 개별 솔루션을 지원해야합니다. [사실, 그들은 현재 지원할 사람이 없다. 나는 보통 들어간다].

C #에는 하나의 솔루션 만 있습니다.

대체로 고객에게는 많은 위험이 있습니다. 이러한 위험을 완화하기위한 단계를 수행 할 수 있으면 C #으로의 변경을 수용 할 수 있습니다.

나는 그것을 말하기를 싫어하지만, 당신의 주장은 단지 물을 보유하지 않습니다.

단위 테스트.

이것은 오랫동안 해결 된 문제였습니다. 많은 단위 테스팅 프레임 워크가 있습니다. 하나를 선택. 이미이 작업을 수행 했어야합니다. 나는 추천 우리를 가 IDE에 통합 및 다른 훌륭한 기능을 제공하기 때문에.

소스 컨트롤

이것은 조금 더 어려우며 준비된 솔루션이 거의 없지만 코드를 리포지토리로 가져오고 나가는 것만으로도 문제가되지 않습니다. 여기에 눈썹이 적은 방법이 있지만 다른 더 좋은 옵션 도 있습니다.

코드 문서

또한 해결 된 문제. MZ-Toolshas는 .Net의 XML 주석 문서와 매우 유사한 XML 문서 기능 을 제공합니다.

더 나은 코딩 규칙

Visual Studio에 ReSharper 플러그인이있는 것처럼 MZ-Tools 와 Rubberduck 에는 이러한 기능이 있습니다.

더 나은 IDE

다시, VBA IDE에 사용 가능한 플러그인이 있습니다.

어셈블리를 통한 더 많은 모듈화-향후 도구에서 재사용을 촉진 할 수 있습니다.

또한 해결 된 문제. 아니요, 어셈블리를 만들 수는 없지만 다른 VBA 프로젝트를 참조 할 수 있습니다.

관리 배포-이 도구가 사용되는 사람을 제어 할 수 있습니다.

비트 스티커는 프로그램에 액세스 할 수있는 사람과 액세스 할 수없는 사람을 제어하는 ​​코드를 작성해야하지만 이미 보안 코드를 작성 했어야합니다.

배포와 관련 하여 해결 된 문제 이기도 합니다. 예, 코드가 필요하지만 사용 / 수정할 수 있는 예제가 있습니다 .

무엇보다도 처음부터 시작한다는 사실입니다. 나 역시 Joel Spolsky의 기사를 추천 할 것이다 .

그들은 모든 소프트웨어 회사가 할 수있는 최악의 전략적 실수를함으로써 그렇게했습니다.

그들은 코드를 처음부터 다시 작성하기로 결정했습니다.

IT 직원이 옳습니다. 처음부터 다시 작성해서는 안됩니다. 현재 솔루션의 문제를 해결해야합니다.

이제는 모두 C # 또는 VB.Net 에서이 작업을 수행하려는 이유를 이해할 수 있습니다. 새 프로젝트를 시작하는 경우 실제로 더 나은 솔루션 이지만 그 소리에서 새 프로젝트가 아닙니다. 처음부터 다시 시작하여 문제를 개선하는 것이 훨씬 좋습니다.

이 기사 에서 Microsoft조차도 다음과 같이 지적 할 수 있습니다 .

기능을 개선하거나 버그를 수정하기 위해 코드를 업데이트하려면 모든 사용자와 Office 사용자 지정을 사용하는 모든 단일 파일에서 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 응용 프로그램 개체 주위에 IDisposable을 구현하는 래퍼 클래스를 작성 한 다음 using이 개체 를 사용할 때 사용해야합니다.

짧은 시간 안에 코드를 얼마나 빨리 포팅 할 수 있는지 보여주고 동료들에게 이것이 좋은 생각임을 확신시켜 줄 수있는 좋은 방법은 한 시간 정도를 소비하는 것입니다.

코드는 거의 변경되지 않았지만 Visual Studio에서 C # 프로젝트를 사용하면 언급 한 모든 이점이 있습니다.

나는 EXCEL 통합 문서에 내장 된 매우 큰 (20k + 라인의 VBA 코드) 응용 프로그램을 가지고 있다는 동일한 입장에 있습니다. Office 2013으로 테스트하면 새로운 사무실 모델의 시작 이벤트 순서 변경 및 EMET의 더 엄격한 시행으로 인해 작동하지 않습니다. 따라서 저는 올해 Office 2013이 출시되기 전에 C # 및 VB.NET으로의 충돌 변환을 수행하고 있습니다. 조직 주변에서 사용되는 다른 더 간단한 (VBA 향상) 통합 문서는 면역 적이 지 않으며 일부는 작동하지 않습니다.

통합 문서 시트를 더 이상 사용할 수없고 VBA 코드를 참조하기 전에 내부 EXCEL 코드에서 Workbook_Open 이벤트 에서 오류가 발생합니다 .

모든 VBA, C # 및 VB.NET에서 편안하므로 후자 둘 다에서 변환을 작성하고 있습니다. 언어 관용구를 사용하면 VB.NET보다 3-4 배 빠른 특정 언어로 특정 기능 구성을 작성할 수 있기 때문에 프레임 워크 코드는 C #으로 작성됩니다. 코드의 대부분은 VB.NET에 있습니다. 왜냐하면 저의 재 작성은 덜 광범위하고 C #에는없는 특정 관용구가 있기 때문입니다.

결정을 내리기 전에 OFFICE 2013 및 조직이 향후 2-3 년 동안 출시 될 것으로 예상되는 EMET 시행을 최대한 활용하여 기존 응용 프로그램을 테스트하는 것이 좋습니다. 저와 마찬가지로 기존 응용 프로그램은 다시 작성하지 않고 해당 환경에서 단순히 실행되지 않습니다.이 경우 다시 작성은 DOT NET 및 VSTO에서도 가능합니다.

추가:

통합 문서 VBA의 전체 내용을 반복하고 모든 모듈, 클래스 및 양식을 파일로 내보내는 작은 자동 추출 유틸리티를 작성하는 것은 얼마나 멋진 지에 따라 1-2 일 작동합니다. 디렉토리에서 빈 통합 문서로 파일을 가져 오는 것과 반대의 경우도 마찬가지입니다. 이 두 가지를 사용하면 모든 VBA 코드를 적절한 소스 제어 상태로 유지하고 통합 문서의 소스 코드에서 빌드 프로세스를 수행 할 수 있습니다.

또는 Excel VBA Code Cleaner 와 같은 무료 유틸리티를 사용하십시오.

저는 현재 VBA만큼 C #에 능숙하지 않기 때문에이 기회를 C # 기술에 대해 다루고 싶습니다. 그리고 "다음 레벨"로 데려 가기위한 이와 같은 프로젝트를 원합니다.

솔직 해지십시오. 이 결정을 내리는 데 관여하는 다른 사람들과이 정보를 공유 할 계획입니까? 그렇지 않다면, 프로젝트가 실패하면 전체 책임을 져야합니다. 비슷한 프로젝트가 이미 만들어져 현장에 나왔기 때문에 모든 사람들은 자신의 마음에서 일어날 것으로 예상되는 것을 형성했습니다. 그들은 마지막 것을 만드는 데 걸리는 시간을 알고 있으며 더 짧은 시간에 추가 할 수 있다고 생각합니다 (추가 요구 사항에 따라 사실 일 수도 있고 그렇지 않을 수도 있음). 새로운 언어를 배우면서이 책임을 맡을 준비가 되셨습니까?

이전 앱을 C # ASAP로 이식하는 것이 좋습니다. 결정을 내리기 전에 프로세스에서 충분히 배울 수 있습니다. 최소한 새로운 언어로 기술을 향상시키려는 목표를 달성하고 프로젝트를 제 시간에 완수해야합니다.

다시 말하지만, 당신이 그것에 대해 강하다고 생각하고 프로젝트를 구축하는 것이 모두 당신의 어깨에 놓여 있다면, 원하는 방식으로하십시오. 허락보다 항상 용서를 얻는 것이 더 쉽습니다.