Допит учасника команди переходить від VBA до C #

Фон

Минулого року мене попросили створити інструмент, який використовуватиметься для планування бізнесу приблизно для 10 користувачів. Це було зроблено від імені іншої ІТ-команди, яка "підписала" мені роботу, і через те, що строки проекту були трохи незапланованими на їхньому боці, мені довелося реалізувати це трохи поспіхом.

Тоді ми вирішили, що найшвидшим способом буде створити робочу книжку Excel з VBA, а потім дозволити користувачам завантажити цю розширену робочу книжку з Інтранету для використання на своїх ПК. У цьому випадку Excel був обмеженням, оскільки система планування (тобто база даних), яку ми використовуємо, може взаємодіяти лише за допомогою надбудови Excel, яка повинна бути завантажена одночасно з відкритою робочою книжкою планування. Однак VBA не була обмеженням на той час.

У робочій книжці я створив близько 4000 рядків коду VBA, і, намагаючись розділити шари даних та презентації, я не міг у всіх випадках через терміни проекту. Якщо чесно, то, хоча я пишаюся тим, що створив цю робочу книжку, я в той же час трохи розчарований тим, що це могло бути зроблено краще, як з точки зору кодування, так і розгортання для користувачів.

Сьогодні

Повернувшись до сьогодні, ІТ-команда знову прийшла до мене, щоб подати запит на подібну робочу книжку (тому я можу повторно використати частини іншої робочої книги вище), але цього разу це набагато складніше і буде використовуватися більшою кількістю користувачів ( близько 200).

Однак цього разу заплановано трохи краще, і я можу побачити, що у нас є трохи більше часу для планування речей. Виходячи з цього, я подумав про рішення та інфраструктуру, оскільки програмування для 100 користувачів має більший вплив, ніж для 10 користувачів. Тому я запропонував команді, що, можливо, ми повинні розглянути можливість переміщення існуючого коду до рішення C #, щоб ми могли керувати кодом більш досконалим способом. Я все ще розглядаю це як надбудову, написану за допомогою VSTO / Excel-DNA, яка потім може бути розгорнена для користувачів.

Я обговорював це з IT-командою два тижні тому, і все здавалося, що це нормально, до вчора я не отримав повідомлення від однієї з команди (яка не знає VBA або C #) з питанням, чому ми повинні починати цей новий проект у C # проти використання той же підхід, як і раніше. Деякі з їх проблем були:

• Це досить важливий проект, тому він повинен працювати - рішення C # не буде настільки стабільним чи ефективним, як існуюче рішення на базі VBA.
• Нам доведеться викинути те, що ми [я] зробили в рішенні VBA, і відтворити це з нуля в C #.
• Комусь доведеться підтримувати два окремих рішення, одне в VBA і одне в C #. [насправді у них наразі немає когось для підтримки, я зазвичай наступаю].

Тепер я можу певною мірою зрозуміти їхні проблеми, але мені потрібно прийняти рішення щодо наступних кроків і з чим повернутися до них. Особисто мені хотілося б реалізувати в C #, тому що я вважаю, що вона краще піддається побудові такого «Enterprise» рішення, як це. Крім того, я хотів би скористатися цією можливістю вивчити свої C # навички, оскільки я зараз не такий компетентний в C #, як я VBA, і я хотів би, щоб такий проект, як цей, переніс мене на "наступний рівень".

Я підготував список пунктів, які міг би використати, щоб спробувати їх переконати, що рішення C # буде кращим для цього проекту, ось що я маю досі:

• Блок тестування.
• Контроль джерела.
• Документація з кодом - для передачі знань іншим супровідним особам.
• Кращі умови кодування - можуть використовувати такі речі, як ReSharper, для забезпечення кращого іменування та структури.
• Краще IDE - менше помилок через виділення помилок.
• Більша модульність через збірки - може сприяти повторному використанню в майбутніх інструментах.
• Кероване розгортання - може контролювати, ким використовується цей інструмент.

Питання: Які ще моменти я можу додати, щоб переконати їх? Або я намагаюся відкусити більше, ніж можу жувати цим проектом? Чи варто просто мовчати і робити це в VBA все одно?

Я усвідомлюю, що просто перехід на нову мову через те, що її "новіша" чи сприйнята "крутішою" не повинна бути основою для прийняття рішення, і як такий я протистояв включенню її як пункт рішення - мова йде про факти.

Крім того, я не прошу буквального порівняння між C # і VBA як мовами, оскільки існує багато порівнянь щодо SO.

Три точки, які ви перерахували, здаються справедливими:

Це досить важливий проект, тому він повинен працювати - рішення C # не буде настільки стабільним чи ефективним, як існуюче рішення на базі VBA.

Дійсно, пізніше ви скажете: "Я хотів би скористатися цією можливістю, щоб засвоїти свої C # навички, оскільки я зараз не такий компетентний в C #, як я VBA " (акцент мій).

Іншими словами, у вас є рішення, яке працює і пройшло інтенсивне тестування користувачів. Ви хочете кинути все це і переписати все мовою, яку ви не добре знаєте. Бачите проблему?

Нам доведеться викинути те, що ми [я] зробили в рішенні VBA, і відтворити це з нуля в C #.

Те, чого ти ніколи не повинен робити, приходить на думку. Ви кидаєте код, а також тестування користувача. Недобра річ.

Комусь доведеться підтримувати два окремих рішення, одне в VBA і одне в C #. [насправді у них наразі немає когось для підтримки, я зазвичай наступаю].

Якщо версія VBA все-таки буде використовуватися, переписати це справді ще більш проблематично. Чому у вас є дві розрізнені системи, які потребують вашої уваги, якщо у вас може бути лише одна, яка вже працює і до якої ви можете переробляти та додавати функції?

Деякі ваші моменти, з іншого боку, можна критикувати:

• Блок тестування.

  Ви також можете перевірити свій поточний проект. Якщо для цього немає зручної рамки, створіть її.

• Контроль джерела.

  Контроль джерела стосується тексту. Ваш поточний код - це текст, тому ви можете використовувати для нього керування джерелом.

  Мова, операційна система, рамки або екосистема абсолютно не мають значення. Ви можете (і повинні) використовувати управління джерелом для будь-якого написаного вами коду: код у Visual Studio або фрагмент коду, який ви складете за кілька хвилин у LINQPad, або сценарії PowerShell, які автоматизують завдання, схему бази даних або макроси Excel.

• Документація з кодом - для передачі знань іншим супровідним особам.

  Домовились.

• Кращі умови кодування - можуть використовувати такі речі, як ReSharper, для забезпечення кращого іменування та структури.

  Визначте «краще». Чи існують умови кодування для макросів Excel? Якщо так, використовуйте їх: вони ні кращі, ні гірші за будь-які інші. Якщо ні, створіть їх та опублікуйте, щоб і інші користувачі могли їх використовувати. Відповіді на запитання, розміщені в 2010 році, здаються досить невтішними, але з тих пір можуть бути нові інструменти.

  Зауважте, що важливою частиною конвенцій кодування є те, що вони повинні застосовуватися під час фіксації.

• Краще IDE - менше помилок через виділення помилок.

  Домовились. Те, що ми не можемо писати макроси у Visual Studio , дуже прикро.

• Більша модульність через збірки - може сприяти повторному використанню в майбутніх інструментах.

  Я впевнений, що ваш поточний продукт також може використовувати певну модульність.

• Кероване розгортання - може контролювати, ким використовується цей інструмент.

  Домовились.

Замість повного перезапису ви можете шукати спосіб поступового переміщення коду з макросу до звичайної збірки, написаної у VB.NET. Чому у VB.NET? Три причини:

• Різниця між VBA та VB.NET менша, як і між VBA та C #.

• Ви краще знаєте VBA, і тільки це є вагомим приводом використовувати VB.NET замість C #. Якщо ви хочете "підкреслити свої C # навички", робіть це своїми особистими проектами, а не критичними справами.

• Будь-яке перезапис з мови на іншу призводить до потенційних помилок. Вам цього не потрібно для цього проекту.

Перехід на збірку .NET може забезпечити вам зручне середовище Visual Studio, зручне тестування модулів, TFS та виділення помилок, які ви зараз використовуєте в інших проектах.

У той же час, якщо ви переміщуєте код покроково, ви не ризикуєте повністю переписати (тобто витративши чотири місяці на створення чогось, що ніхто не хоче використовувати через велику кількість нових помилок). Наприклад, вам потрібно працювати над певною функцією? Подумайте, як ви можете спочатку перемістити цю особливість до .NET.

Це досить схоже на рефакторинг. Замість того, щоб переписувати все це через те, що ви дізналися деякі нові моделі дизайну та мовні особливості, ви просто зробите невеликі зміни в коді, над яким зараз працюєте.

Я б підтримав перехід на C #. Інші дуже добре висвітлили ваші бали, тому я не буду переробити те, що вони сказали. Напевно є багато вагомих причин дотримуватися VBA.

Однак один із моїх роботодавців зробив бездоганну роботу зі створення змістовної документації. Настільки, що дизайнерські рішення насправді були записані з обґрунтуванням - коли б це мали лише всі програмні проекти! Моя думка? Одним із дизайнерських рішень було «Ми вирішили написати цю програму на Java, тому що містер Соці і так хочемо поставити на своє резюме x років досвіду Java». Якщо це вагома причина для переходу на C #, то це не можна ігнорувати як дрібницю. Це просто не може бути однією з причин, яку ви використовуєте для того, щоб виправдати це для ІТ-команди, тому що їм не все одно, що ви хочете у вашому резюме, вони дбають про працюючий продукт.

Існує також сприйняття VBA для роздумів. Я знаю, що це неправда, але я знаю досить багато людей, які бачать "VBA" на резюме і думають: "Що, цей хлопець застряг, що робив стажування? Чому він не має досвіду з реальною мовою?" Вони бачать "VBA" і думають, що "перевершує розробник макросів". Як і копіювання / вставлення однієї комірки в іншу, виконання простих обчислень тощо. Зазвичай люди, які можуть оцінити реальний розвиток в VBA, - це ті, хто це зробив, і, як мінімум, з мого досвіду, це схоже на все менший пул. Можливо, ви краще відчуєте сприйняття VBA у вашому районі, але я бачив багато невиправданого негативу щодо нього.

Інша річ, яку я хочу зробити на нуль: MainMa згадала схожість між VBA та C #. Це абсолютно вірно, і відповідь JMK пропонує декілька технологій для читання. Спробуйте скопіювати / вставити код VBA в проект C # і подивіться, як легко виправити помилки синтаксису.

Ви сказали, що у вас є 4000 рядків коду, що є гарним фрагментом коду і, ймовірно, включає багато функціональності ... але це лише 4000 рядків коду. Спробуйте скопіювати та вставити річ. Я дійсно не був би здивований, якби ви могли очистити ці синтаксичні помилки і мати робочий проект. Не знаючи подробиць вашого коду чи кількості вільного часу, який вам доступний, я б подумав, що ви можете вибити це у вихідні.

Він може не дотримуватися найкращих практик C #, він може бути неефективним, але ви отримаєте функціонально еквівалентний проект на C #. Ви також можете бути відносно впевнені, що ваш новий C # код не є більш дефектним, ніж ваш старий код VBA.

Перетворення вашого коду VBA в C # у свій час зробить для вас пару речей:

• Досліджуючи помилки синтаксису, ви ознайомитесь із практикою C # - свого роду праймер для фактичної роботи в C #
• Він засвітить будь-які очевидні проблеми із завантаженням плагіна в excel (оскільки, мабуть, excel все ще є вимогою). Можливо, є питання, яке ви ще не вважали, і це може бути блокпостом.
• Він покаже підтвердження концепції вашому клієнту (ІТ-команді). Якщо вони можуть побачити, що у вас працює робочий плагін C # з поточною функціональністю, ви зменшите рівень сприйнятого ризику за допомогою C #.

І повернувшись до трьох моментів ІТ:

• Це досить важливий проект, тому він повинен працювати - рішення C # не буде настільки стабільним чи ефективним, як існуюче рішення на базі VBA.

Як уже згадувалося, ваш C # код буде охоплювати таку ж функціональність і бути таким же стабільним, як і ваш VBA. Строго кажучи, є ймовірність ввести помилки / дефекти чи неефективність, але це здається малоймовірним. Ми не говоримо про порт від iOS / Objective C до Android / Java, ми говоримо про порт між двома мовами, які мають багато подібностей у синтаксисі і можуть використовувати саме таку технологію - працездатні зошити Excel.

• Нам доведеться викинути те, що ми [я] зробили в рішенні VBA, і відтворити це з нуля в C #.

Цим ви не кидаєте жодних зусиль чи коду.

• Хтось повинен буде підтримувати два окремих рішення, одне в VBA і одне в C #. [насправді у них наразі немає когось для підтримки, я зазвичай наступаю].

У вас буде лише 1 рішення, все в C #.

Загалом ваш клієнт бачить багато ризику. Якщо ви можете вжити заходів для зменшення цього ризику, вони можуть охопити зміну на C #.

Я ненавиджу це говорити, але ваші аргументи просто не тримають води.

Блок тестування.

Це було вирішеною проблемою дуже давно. Є багато фреймворків для тестування блоків. Вибрати один. Ви повинні були це робити вже. Я рекомендую нашу , тому що вона інтегрується в IDE і надає інші чудові функції.

Контроль джерела

Це трохи жорсткіше, є кілька готових вбудованих рішень, але це справді лише питання введення вашого коду у сховище та вихід із нього. Ось низький спосіб зробити це , але є й інші кращі варіанти .

Кодова документація

Також вирішена проблема. MZ-Tools має функцію документації XML, яка працює дуже аналогічно документам XML для коментарів .Net.

Кращі умови кодування

Як і у Visual Studio є плагін ReSharper, і MZ-Tools, і Rubberduck мають такі функції.

Краще IDE

Знову ж таки, для VBA IDE доступні плагіни.

Більша модульність через збірки - може сприяти повторному використанню в майбутніх інструментах.

Також вирішена проблема. Ні, ви не можете створювати збірки, але ви можете посилатися на інші проекти VBA.

Кероване розгортання - може контролювати, ким використовується цей інструмент.

Трохи наклейка, вам потрібно буде написати код, щоб контролювати, хто може отримати доступ до програми, а хто не може, але ви (знову ж таки), мабуть, вже мали написати написаний код безпеки.

Щодо розгортання, це також вирішена проблема. Так, він вимагає коду, але є приклади, які ви можете використовувати / змінювати .

На додаток до всього, це той факт, що ви б починали з нуля. Я теж порекомендую статтю Джоела Спольського .

Вони зробили це, зробивши єдину найгіршу стратегічну помилку, яку може зробити будь-яка програмна компанія:

Вони вирішили переписати код з нуля.

Ваші ІТ-хлопці мають рацію. Ви не повинні переписувати це з нуля. Ви повинні вирішити проблеми з вашим поточним рішенням.

Тепер, маючи все сказане, я можу абсолютно зрозуміти, чому ви хочете робити це в 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 тощо, де це доречно, та додавши крапки з комою.

Це по суті той самий Framework під ним (Excel), ви просто змінюєте синтаксис з VBA на C #.

Закінчивши, не забудьте зберегти та закрити програму:

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

Потім випустіть програму з маршалом:

Marshal.ReleaseComObject(excelApplication);

Можливо, я б написав клас обгортки, що реалізує IDisposable навколо об'єкта програми Excel, тоді обов'язково використовуйте usingцей об’єкт.

Хорошим способом зробити ваш випадок було б витратити на це годину або близько того, що за короткий проміжок часу продемонструє, як швидко ви можете перенести код коду, і переконати своїх колег, що це хороша ідея.

Код певним чином залишатиметься незмінним, але у вас є всі переваги, про які ви згадали, що маєте проект C # у Visual Studio.

Я перебуваю в такому самому положенні, що в робочу книжку EXCEL вбудовано дуже велику програму (20k + рядки коду VBA). Після тестування з Office 2013 він просто не працює, імовірно, через зміни в послідовності запуску події в новій офісній моделі та, можливо, більш жорсткого виконання EMET. Таким чином, я переживаю перетворення аварійних перетворень на C # і VB.NET до початку запуску Office 2013 цього року. Інші, простіші (покращені VBA) робочі зошити, що використовуються в організації, не захищені, деякі працюють, а інші - ні.

Помилки трапляються в події Workbook_Open , де аркуші робочої книги більше недоступні, та у внутрішньому коді EXCEL до посилання будь-якого коду VBA.

Будучи комфортним у всіх VBA, C # та VB.NET, я пишу перетворення в обох останніх двох. Рамковий код пишеться на C #, оскільки мовні ідіоми дозволяють мені писати певні функціональні конструкції на цій мові в 3-4 рази швидше, ніж у VB.NET. Основна частина коду є у VB.NET, оскільки тоді моя перезапис є менш обширним, і там є певні ідіоми, яких немає у C #.

Перш ніж приймати будь-яке рішення, я настійно рекомендую протестувати існуючу програму за допомогою OFFICE 2013 та максимально можливого застосування програми EMET, яку організація передбачає впровадити впродовж наступних 2-3 років. Ви можете, як і я, виявити, що існуюча програма просто не запуститься в цьому середовищі без перезапису - в такому випадку перезапис може бути також у DOT NET та VSTO.

Додаток:

Написання невеликої автоматизованої утиліти витягу, яка перебирає весь вміст робочої книги VBA та експортує всі модулі, класи та форми у файли, працює 1-2 дні, залежно від того, наскільки ви хочете, щоб це було. Аналогічно із зворотним імпортом файлів із каталогу в порожню робочу книгу. З цими двома цілком можливо мати весь свій код VBA у належному контролі джерела, а також створити процес збирання з вихідного коду для вашої робочої книги.

АБО - використовуйте безкоштовну утиліту, таку як Excel VBA Code Cleaner

Я хотів би скористатися цією можливістю, щоб засвоїти свої C # навички, оскільки я зараз не такий компетентний в C #, як я VBA, і я хотів би такий проект, щоб перевести мене на "наступний рівень".

Бути чесним. Чи плануєте ви поділитися цією інформацією з іншими людьми, які беруть участь у прийнятті цього рішення? Якщо ні, то я б поклав на себе всю провину, якщо проект не вдасться. Оскільки подібний проект уже створений та викладений у поле, кожен сформував те, що сподівається на власну думку. Вони знають, скільки часу знадобилося для складання останнього, і вірять, що ви можете створити цей за менший час (що може бути, а може і не бути правдою на основі додаткових вимог). Чи готові ви взяти на себе цю відповідальність разом із вивченням нової мови?

Рекомендую перенести старий додаток до C # ASAP. Можливо, ви зможете навчитися достатньо в процесі, перш ніж буде прийнято рішення. Принаймні, ви досягнете своєї мети - підвищити свої навички новою мовою і все-таки виконати проект вчасно.

Знову ж таки, якщо ви відчуваєте, що сильно ставитесь до цього, і побудова проекту все лежить на ваших плечах, зробіть це так, як вам хочеться. Завжди легше отримати прощення, ніж дозвіл.