Przesłuchanie członka zespołu z VBA na C #

tło

W zeszłym roku poproszono mnie o stworzenie narzędzia, które będzie wykorzystywane do planowania biznesowego dla około 10 użytkowników. Odbyło się to w imieniu innego zespołu IT, który „zlecił mi” podwykonawstwo pracy, a ponieważ terminy projektu były trochę nieplanowane po ich stronie, musiałem wdrożyć je w pośpiechu.

W tym czasie zdecydowaliśmy, że najszybszym sposobem będzie utworzenie skoroszytu programu Excel za pomocą VBA, a następnie zachęcenie użytkowników do pobrania skoroszytu z rozszerzeniem VBA z intranetu do użycia na swoich komputerach. Excel był w tym przypadku ograniczeniem, ponieważ używany przez nas system planowania (tj. Baza danych) może wchodzić w interakcje tylko za pomocą dodatku Excel, który musi zostać załadowany w tym samym czasie, gdy skoroszyt planowania jest otwarty. Jednak VBA nie był wówczas ograniczeniem.

Skoroszyt utworzyłem około 4000 wierszy kodu VBA i chociaż próbowałem oddzielić warstwy danych i warstw prezentacji, nie mogłem we wszystkich przypadkach z powodu terminów projektu. Szczerze mówiąc, chociaż jestem dumny z tworzenia tego skoroszytu, jestem jednocześnie trochę rozczarowany, że można było to zrobić lepiej, zarówno pod względem kodowania, jak i wdrażania dla użytkowników.

Dzisiaj

Wracając do dzisiejszego dnia, zespół IT ponownie przyszedł do mnie z prośbą o podobny skoroszyt (abym mógł ponownie użyć części innego skoroszytu powyżej), ale tym razem jest on o wiele bardziej skomplikowany i będzie używany przez większą liczbę użytkowników ( około 200).

Jednak tym razem jest to trochę lepiej zaplanowane i widzę, że mamy trochę więcej czasu na planowanie. Na tej podstawie pomyślałem o rozwiązaniu i infrastrukturze, ponieważ programowanie dla 100 użytkowników ma większy wpływ niż dla 10 użytkowników. Dlatego zasugerowałem zespołowi, że być może powinniśmy rozważyć migrację istniejącego kodu do rozwiązania C #, abyśmy mogli zarządzać kodem w bardziej wyrafinowany sposób. Nadal rozważam to jako dodatek napisany przy użyciu VSTO / Excel-DNA, który można następnie wdrożyć dla użytkowników.

Rozmawiałem o tym z zespołem IT dwa tygodnie temu i wszystko wydawało się w porządku, aż do wczoraj otrzymałem wiadomość od jednego z zespołów (który nie zna VBA ani C #) z pytaniem, dlaczego powinniśmy rozpocząć ten nowy projekt w C # w porównaniu z użyciem takie samo podejście jak poprzednio. Niektóre z nich dotyczyły:

• Jest to dość ważny projekt, więc musi działać - rozwiązanie C # nie byłoby tak stabilne ani działało tak dobrze, jak istniejące rozwiązanie oparte na VBA.
• Musielibyśmy wyrzucić to, co [ja] zrobiliśmy w rozwiązaniu VBA i odtworzyć to od zera w języku C #.
• Ktoś będzie musiał obsługiwać dwa oddzielne rozwiązania, jedno w VBA i jedno w C #. [w rzeczywistości obecnie nie mają nikogo do pomocy, zwykle wkraczam].

Teraz do pewnego stopnia rozumiem niektóre z ich obaw, ale muszę podjąć decyzję dotyczącą kolejnych kroków i tego, do czego należy się zwrócić. Osobiście chciałbym wdrożyć w języku C #, ponieważ uważam, że lepiej byłoby zbudować takie rozwiązanie „Enterprise”. Co więcej, chciałbym skorzystać z okazji, aby poprawić moje umiejętności w C #, ponieważ obecnie nie jestem tak kompetentny w C # jak jestem VBA i chciałbym, aby taki projekt zabrał mnie na „następny poziom”.

Przygotowałem listę punktów, których mogę użyć, aby przekonać ich, że rozwiązanie C # byłoby lepsze dla tego projektu, oto co mam do tej pory:

• Testów jednostkowych.
• Kontrola źródła.
• Dokumentacja kodu - w celu przekazania wiedzy innym osobom wspierającym.
• Lepsze konwencje kodowania - można użyć rzeczy takich jak ReSharper, aby wymusić lepszą nazewnictwo i strukturę.
• Lepsze IDE - mniej błędów z powodu podświetlania błędów.
• Większa modułowość dzięki zestawom - może promować ponowne użycie w przyszłych narzędziach.
• Zarządzane wdrożenie - może kontrolować, kto korzysta z tego narzędzia.

Pytanie: Jakie jeszcze kwestie mogę dodać, aby je przekonać? A może próbuję odgryźć więcej, niż mogę żuć w tym projekcie? Czy powinienem po prostu milczeć i zrobić to w VBA?

Wiem, że przejście do nowego języka, ponieważ jego „nowszy” lub postrzegany jako „chłodniejszy” nie powinien stanowić podstawy do podjęcia decyzji i dlatego postanowiłem uwzględnić go jako punkt decyzyjny - chodzi o fakty.

Ponadto nie proszę o dosłowne porównanie C # i VBA jako języków, ponieważ istnieje wiele porównań na temat SO.

Trzy wymienione punkty wydają się sprawiedliwe:

Jest to dość ważny projekt, więc musi działać - rozwiązanie C # nie byłoby tak stabilne ani działało tak dobrze, jak istniejące rozwiązanie oparte na VBA.

Rzeczywiście, później mówisz: „Chciałbym skorzystać z okazji, aby poprawić swoje umiejętności w C #, ponieważ nie jestem obecnie tak kompetentny w C #, jak jestem VBA ” (moje podkreślenie).

Innymi słowy, masz rozwiązanie, które działa i przeszło intensywne testy użytkownika. Chcesz to wszystko wyrzucić i przepisać wszystko w języku, którego nie znasz dobrze. Widzisz problem?

Musielibyśmy wyrzucić to, co [ja] zrobiliśmy w rozwiązaniu VBA i odtworzyć to od zera w języku C #.

Przychodzą na myśl rzeczy, których nigdy nie powinieneś robić . Rzucasz kod, a także testy użytkownika. To nie jest dobra rzecz.

Ktoś będzie musiał obsługiwać dwa oddzielne rozwiązania, jedno w VBA i jedno w C #. [w rzeczywistości obecnie nie mają nikogo do pomocy, zwykle wkraczam].

Jeśli nadal byłaby używana wersja VBA, przepisywanie jest jeszcze bardziej problematyczne. Dlaczego miałbyś mieć dwa różne systemy, które wymagają Twojej uwagi, skoro możesz mieć tylko jeden, który już działa i który możesz przebudować i dodać funkcje?

Z drugiej strony niektóre z twoich punktów można skrytykować:

• Testów jednostkowych.

  Możesz również przetestować swój bieżący projekt. Jeśli nie ma do tego dogodnych ram, utwórz je.

• Kontrola źródła.

  Kontrola źródła zajmuje się tekstem. Twój obecny kod to tekst, dlatego możesz dla niego użyć kontroli źródła.

  Język, system operacyjny, struktura lub ekosystem są całkowicie nieistotne. Możesz (i powinieneś) używać kontroli źródła dla dowolnego kodu, który piszesz: kod w Visual Studio lub fragment kodu, który szkicujesz w ciągu kilku minut w LINQPad, lub skrypty PowerShell, które automatyzują zadanie, schemat bazy danych lub makra Excel.

• Dokumentacja kodu - w celu przekazania wiedzy innym osobom wspierającym.

  Zgoda.

• Lepsze konwencje kodowania - można użyć rzeczy takich jak ReSharper, aby wymusić lepszą nazewnictwo i strukturę.

  Zdefiniuj „lepiej”. Czy istnieją konwencje kodowania dla makr Excela? Jeśli tak, skorzystaj z nich: nie są lepsze ani gorsze od innych. Jeśli nie, utwórz je i opublikuj, aby inni też mogli z nich korzystać. Odpowiedzi na pytanie opublikowane w 2010 r. Wydają się dość rozczarowujące, ale od tego czasu mogą być dostępne nowe narzędzia.

  Zauważ, że ważną częścią konwencji kodowania jest to, że powinny być egzekwowane przy zatwierdzaniu.

• Lepsze IDE - mniej błędów z powodu podświetlania błędów.

  Zgoda. Fakt, że nie możemy pisać makr w programie Visual Studio, jest bardzo niefortunny.

• Większa modułowość dzięki zestawom - może promować ponowne użycie w przyszłych narzędziach.

  Jestem prawie pewien, że twój obecny produkt może również korzystać z pewnego stopnia modułowości.

• Zarządzane wdrożenie - może kontrolować, kto korzysta z tego narzędzia.

  Zgoda.

Zamiast kompletnego przepisywania możesz znaleźć sposób na stopniowe przenoszenie kodu z makra do zwykłego zestawu napisanego w VB.NET. Dlaczego w VB.NET? Trzy powody:

• Różnica między VBA i VB.NET jest mniejsza niż między VBA i C #.

• Ty wiesz lepiej VBA, a samo to dobry powód, aby używać VB.NET zamiast C #. Jeśli chcesz „odświeżyć swoje umiejętności w języku C #”, rób to z własnymi projektami, a nie z kluczowymi sprawami biznesowymi.

• Wszelkie przepisywanie z jednego języka na inny prowadzi do potencjalnych błędów. Nie potrzebujesz tego do tego projektu.

Przejście do zestawu .NET może dać ci wygodne środowisko Visual Studio, z wygodnym testowaniem jednostek, TFS i podświetlaniem błędów, którego obecnie używasz w innych projektach.

Jednocześnie, jeśli przenosisz kod krok po kroku, nie ryzykujesz kompletnego przepisania (tj. Spędzenia czterech miesięcy na tworzeniu czegoś, czego nikt nie chce używać z powodu dużej liczby nowych błędów). Na przykład musisz popracować nad konkretną funkcją? Zastanów się, jak możesz najpierw przenieść tę konkretną funkcję na platformę .NET.

Jest to dość podobne do refaktoryzacji. Zamiast przepisywać całość, ponieważ nauczyłeś się nowych wzorców projektowych i funkcji językowych, po prostu dokonujesz niewielkich zmian w kodzie, nad którym obecnie pracujesz.

Poparłbym przejście do C #. Inni bardzo dobrze opisali twoje punkty, więc nie powtórzę tego, co powiedzieli. Jest zdecydowanie wiele dobrych powodów, aby trzymać się VBA.

jednak jeden z moich pracodawców wykonał nienaganną pracę przy tworzeniu sensownej dokumentacji. Do tego stopnia, że ​​decyzje projektowe zostały spisane z uzasadnieniem - jeśli tylko wszystkie projekty oprogramowania miały to! Mój punkt? Jedną z decyzji projektowych było: „Wybieramy pisanie tego programu w Javie, ponieważ pan taki i taki chce odłożyć x-letnie doświadczenie w Javie”. Jeśli jest to silny powód, aby przejść do C #, nie można tego zignorować jako trywialności. To po prostu nie może być jeden z powodów, dla których wykorzystujesz to do usprawiedliwienia zespołowi IT, ponieważ tak naprawdę nie obchodzi ich, co chcesz w CV, zależy im na działającym produkcie.

Można również pomyśleć o postrzeganiu VBA. Wiem, że to nieprawda, ale znam sporo osób, które widzą „VBA” w życiorysie i myślą: „Co, ten facet utknął podczas stażu? Dlaczego nie ma doświadczenia w prawdziwym języku?”. Widzą „VBA” i myślą „excel macro developer”. Jak kopiowanie / wklejanie jednej komórki do drugiej, wykonywanie prostych obliczeń itp. Zwykle ludzie, którzy potrafią docenić prawdziwy rozwój VBA, to ci, którzy to zrobili, i wydaje mi się to coraz mniejszą pulą, przynajmniej z mojego doświadczenia. Być może lepiej rozumiesz postrzeganie VBA w swojej okolicy, ale widziałem wiele nieuzasadnionych negatywnych nastawień w stosunku do niego.

Inną rzeczą, którą chcę wyzerować: MainMa wspomniał o podobieństwach między VBA i C #. Jest to absolutnie prawda, a odpowiedź JMK oferuje kilka technologii do przeczytania. Spróbuj skopiować / wkleić kod VBA do projektu w języku C # i przekonaj się, jak łatwo błędy w składni wyglądają na poprawienie.

Powiedziałeś, że masz 4000 linii kodu, co jest sporą częścią kodu i prawdopodobnie obejmuje wiele funkcji ... ale to tylko 4000 linii kodu. Spróbuj skopiować i wkleić. Naprawdę nie byłbym zaskoczony, gdybyś mógł usunąć te błędy składniowe i mieć działający projekt. Nie znając szczegółów kodu ani dostępnego czasu wolnego, pomyślałbym, że możesz to znokautować w weekend.

Może nie być zgodny z najlepszymi praktykami w C #, może być nieefektywny, ale skończyłby się funkcjonalnie równoważnym projektem w C #. Możesz być również względnie pewien, że nowy kod C # nie jest bardziej podatny na defekty niż stary kod VBA.

Konwersja kodu VBA na C # we własnym czasie zrobiłaby dla ciebie kilka rzeczy:

• Badając błędy składniowe, zapoznasz się z praktykami w języku C # - rodzajem podkładu do faktycznej pracy w języku C #
• Zapali światło na wszelkie oczywiste problemy z ładowaniem wtyczki do programu Excel (ponieważ program Excel jest prawdopodobnie nadal wymagany). Być może istnieje problem, którego jeszcze nie rozważałeś, a może to być blokada drogi.
• Pokaże proof-of-concept swojemu klientowi (zespołowi IT). Jeśli zobaczą, że masz działającą wtyczkę C # z bieżącą funkcjonalnością, wówczas zmniejszysz poziom postrzeganego ryzyka dzięki C #.

Wracając do trzech punktów IT:

• Jest to dość ważny projekt, więc musi działać - rozwiązanie C # nie byłoby tak stabilne ani działało tak dobrze, jak istniejące rozwiązanie oparte na VBA.

Jak wspomniano, Twój kod C # będzie obejmował tę samą funkcjonalność i będzie tak samo stabilny jak twój VBA. Ściśle mówiąc, nie jest szansa, wprowadzają błędy / usterki lub nieefektywność, ale to wydaje się mało prawdopodobne. Nie mówimy o porcie z iOS / Objective C na Android / Java, mówimy o porcie między dwoma językami, które mają wiele podobieństw w składni i mogą korzystać z dokładnie tej samej technologii - skoroszytów programu Excel.

• Musielibyśmy wyrzucić to, co [ja] zrobiliśmy w rozwiązaniu VBA i odtworzyć to od zera w języku C #.

Dzięki temu nie wyrzucasz żadnego wysiłku ani kodu.

• Ktoś będzie musiał obsługiwać dwa oddzielne rozwiązania, jedno w VBA i jedno w C #. [w rzeczywistości obecnie nie mają nikogo do pomocy, zwykle wkraczam].

Będziesz miał tylko 1 rozwiązanie, wszystkie w języku C #.

Podsumowując, twój klient widzi duże ryzyko. Jeśli możesz podjąć kroki w celu ograniczenia tego ryzyka, mogą zaakceptować zmianę na C #.

Nienawidzę tego mówić, ale twoje argumenty po prostu nie utrzymują wody.

Testów jednostkowych.

To był rozwiązany problem od bardzo dawna. Istnieje wiele ram testów jednostkowych. Wybierz jedno. Powinieneś już to robić. Polecam nasz , ponieważ integruje się z IDE i zapewnia inne świetne funkcje.

Kontrola źródła

To jest trochę trudniejsze, istnieje kilka gotowych rozwiązań, ale tak naprawdę to tylko kwestia wprowadzenia i wyjścia kodu z repozytorium. Oto niski sposób na zrobienie tego , ale są też inne lepsze opcje .

Dokumentacja kodu

Również rozwiązany problem. MZ-Toolshas to funkcja dokumentacji XML, która działa bardzo podobnie do dokumentów komentarzy XML w .Net.

Lepsze konwencje kodowania

Podobnie jak Visual Studio ma wtyczkę ReSharper , zarówno MZ-Tools, jak i Rubberduck mają takie funkcje.

Lepsze IDE

Ponownie dostępne są wtyczki dla VBA IDE.

Większa modułowość dzięki zestawom - może promować ponowne użycie w przyszłych narzędziach.

Również rozwiązany problem. Nie, nie możesz tworzyć zespołów, ale możesz odwoływać się do innych projektów VBA.

Zarządzane wdrożenie - może kontrolować, kto korzysta z tego narzędzia.

Trochę naklejki, musisz napisać kod, aby kontrolować, kto ma dostęp do programu, a kto nie, ale prawdopodobnie (jeszcze) prawdopodobnie już powinieneś napisać kod bezpieczeństwa.

Jeśli chodzi o wdrożenie, jest to również rozwiązany problem. Tak, wymaga kodu, ale istnieją przykłady, których można użyć / zmodyfikować .

Na dodatek jest to, że zaczynasz od zera. Ja również polecę artykuł Joela Spolsky'ego .

Zrobili to, popełniając jeden najgorszy błąd strategiczny, jaki może popełnić każda firma produkująca oprogramowanie:

Postanowili przepisać kod od zera.

Twoi informatycy mają rację. Nie powinieneś pisać tego od nowa. Powinieneś rozwiązywać problemy z obecnym rozwiązaniem.

Teraz, po tym wszystkim, absolutnie rozumiem, dlaczego chcesz to zrobić w C # lub VB.Net. Naprawdę są lepszym rozwiązaniem, jeśli zaczynasz nowy projekt , ale z jego brzmienia nie jest to nowy projekt. O wiele lepiej jest ulepszyć to, co musisz, aby je przerwać, zaczynając od nowa.

Możesz zauważyć, że nawet Microsoft stwierdza w tym artykule:

Aktualizacja kodu w celu ulepszenia funkcji lub naprawienia błędów wymagałaby ponownego wysłania e-maila, przebudowania i przepracowania artefaktu pakietu Office przez każdego użytkownika oraz w każdym pliku korzystającym z dostosowania.

Ten artykuł dotyczy różnych podejść do opracowywania programów opartych na pakiecie Office, być może w dyskusji możesz wziąć także inne zalety i wady.

To naprawdę zależy od tego, jak zamierzasz przejść do C # (tj. Jakiej technologii będziesz używać).

Jeśli zamierzasz używać OpenXML, to mówisz o całkowitym przepisaniu, co nie jest zalecane, jeśli masz rozwiązanie, które działa.

Jeśli mówisz o korzystaniu z Interopa, może się okazać, że proces jest zaskakująco gładki. W przeszłości przeniosłem dużo kodu z VBA na C # (z Interopem), a po podłączeniu do skoroszytu:

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

W wielu przypadkach można skopiować / makaron kodu VBA, poprzedzając z wywołań funkcji workbook., zastępując Wym z var etc gdzie właściwe i dodając średników na końcu.

Jest to w zasadzie ten sam Framework pod spodem (Excel), po prostu zmieniasz składnię z VBA na C #.

Po zakończeniu pamiętaj o zapisaniu i zamknięciu aplikacji:

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

Następnie zwolnij aplikację z marszałkiem:

Marshal.ReleaseComObject(excelApplication);

Prawdopodobnie napisałbym klasę opakowującą implementującą IDisposable wokół obiektu aplikacji Excel, a następnie koniecznie używałbym usingtego obiektu.

Dobrym sposobem na uzasadnienie tej sprawy byłoby spędzenie około godziny na zrobieniu tego, co w krótkim czasie pokazałoby, jak szybko można przekierować kod i przekonać kolegów, że to dobry pomysł.

Kod pozostałby w dużej mierze niezmieniony, ale masz wszystkie wspomniane korzyści z posiadania projektu C # w Visual Studio.

Jestem w tej samej sytuacji, mając bardzo dużą (20k + linii kodu VBA) aplikację wbudowaną w skoroszyt EXCEL. Po przetestowaniu z pakietem Office 2013 po prostu nie działa, co jest uważane ze względu na zmiany w sekwencji zdarzenia rozruchowego w nowym modelu biura i być może bardziej rygorystyczne egzekwowanie EMET. Dlatego jestem w stanie wykonać awarię do C # i VB.NET przed wprowadzeniem pakietu Office 2013 w tym roku. Inne, prostsze (ulepszone VBA) skoroszyty używane w organizacji nie były odporne, niektóre działały, a inne nie.

Błędy występują w zdarzeniu Workbook_Open , w którym arkusze skoroszytu nie są już dostępne, oraz w wewnętrznym kodzie EXCEL przed odwołaniem do dowolnego kodu VBA.

Będąc wygodnym we wszystkich VBA, C # i VB.NET piszę konwersję w obu ostatnich dwóch. Kod frameworku jest napisany w języku C #, ponieważ idiomy języka pozwalają mi pisać pewne konstrukcje funkcjonalne w tym języku 3-4 razy szybciej niż w VB.NET. Większość kodu znajduje się w VB.NET, ponieważ wtedy moje przepisywanie jest mniej obszerne i istnieją pewne idiomy, które nie są obecne w języku C #.

Przed podjęciem jakiejkolwiek decyzji zdecydowanie zalecam przetestowanie istniejącej aplikacji za pomocą OFFICE 2013 i jak najszerszego zakresu egzekwowania przepisów EMET, jaki organizacja przewiduje na kolejne 2-3 lata. Możesz, podobnie jak ja, odkryć, że istniejąca aplikacja po prostu nie uruchomi się w tym środowisku bez przepisania - w takim przypadku przepisanie może równie dobrze być w DOT NET i VSTO.

Uzupełnienie:

Napisanie małego automatycznego narzędzia do rozpakowywania, które zapętla całą zawartość skoroszytu VBA i eksportuje wszystkie moduły, klasy i formularze do plików, zajmuje 1-2 dni, w zależności od tego, jak chcesz. Podobnie z odwrotnością, aby zaimportować pliki z katalogu do pustego skoroszytu. Dzięki tym dwóm jest całkiem możliwe, aby cały kod VBA miał odpowiednią kontrolę źródła i mieć proces budowania z kodu źródłowego skoroszytu.

LUB - skorzystaj z bezpłatnego narzędzia, takiego jak Excel VBA Code Cleaner

Chciałbym skorzystać z okazji, aby poprawić moje umiejętności w C #, ponieważ obecnie nie jestem tak kompetentny w C # jak jestem VBA i chciałbym, aby taki projekt zabrał mnie na „następny poziom”.

Bądź szczery. Czy planujesz udostępnić te informacje innym osobom zaangażowanym w podjęcie tej decyzji? Jeśli nie, złożyłbym na ciebie całą winę, jeśli projekt się nie powiedzie. Ponieważ podobny projekt został już stworzony i wprowadzony w życie, wszyscy ukształtowali to, czego się spodziewają. Wiedzą, ile czasu zajęło zbudowanie ostatniego, i będą wierzyć, że możesz go stworzyć w krótszym czasie (co może, ale nie musi być prawdą, w oparciu o dodatkowe wymagania). Czy jesteś gotowy wziąć na siebie tę odpowiedzialność wraz z nauką nowego języka?

Zalecam przeniesienie starej aplikacji do C # ASAP. Być może możesz nauczyć się wystarczająco dużo w procesie przed podjęciem decyzji. Przynajmniej osiągniesz cel polegający na zwiększeniu umiejętności dzięki nowemu językowi i nadal wykonasz projekt na czas.

Z drugiej strony, jeśli czujesz się tak silny, a budowanie projektu spoczywa na twoich barkach, rób to tak, jak chcesz. Zawsze łatwiej jest uzyskać przebaczenie niż pozwolenie.