Опрос члена команды с VBA на C #

Фон

В прошлом году меня попросили создать инструмент для бизнес-планирования примерно для 10 пользователей. Это было сделано от имени другой ИТ-команды, которая «заключила со мной контракт», и из-за того, что сроки выполнения проекта были немного незапланированными с их стороны, мне пришлось немного поторопиться с этим.

В то время мы решили, что самым быстрым способом было бы создать книгу Excel с VBA, а затем попросить пользователей загрузить эту книгу с расширенными возможностями VBA из интрасети для использования на своих ПК. В этом случае Excel был ограничением, поскольку используемая нами система планирования (т. Е. База данных) может взаимодействовать только через надстройку Excel, которая должна быть загружена одновременно с открытой книгой планирования. Тем не менее, VBA не был ограничением в то время.

В рабочей книге я создал около 4000 строк кода VBA, и хотя я пытался разделить уровни данных и представления, я не смог во всех случаях из-за сроков проекта. Если честно, хотя я горжусь созданием этой книги, я в то же время немного разочарован тем, что она могла бы быть лучше, как с точки зрения кодирования, так и с точки зрения развертывания для пользователей.

сегодня

Назад к сегодняшнему дню, и ИТ-команда снова пришла ко мне, чтобы запросить аналогичную рабочую книгу (чтобы я мог повторно использовать части другой рабочей книги выше), но на этот раз она намного сложнее и будет использоваться большим числом пользователей ( около 200).

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

Я обсуждал это с ИТ-командой две недели назад, и все было в порядке, до вчерашнего дня я получил письмо от одного из членов команды (который не знает VBA или C #) с вопросом, почему мы должны начать этот новый проект в C # вместо использования тот же подход, что и раньше. Некоторые из их проблем были:

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

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

Я подготовил список моментов, которые я мог бы использовать, чтобы попытаться убедить их в том, что решение C # будет лучше для этого проекта, вот что я имею до сих пор:

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

Вопрос: Какие еще моменты я мог бы добавить, чтобы убедить их? Или я пытаюсь откусить больше, чем могу прожевать в этом проекте? Должен ли я просто молчать и делать это в VBA в любом случае?

Я знаю, что просто переход на новый язык, потому что он «новее» или считается «круче», не должен быть основой для решения, и поэтому я не стал включать его в качестве точки принятия решения - речь идет о фактах.

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

Три перечисленных вами пункта кажутся справедливыми:

Это довольно важный проект, поэтому он должен работать - решение C # не будет таким же стабильным или работать, как существующее решение на основе VBA.

Действительно, позже вы скажете: «Я хотел бы воспользоваться этой возможностью, чтобы освежить свои навыки в C #, поскольку в настоящее время я не настолько компетентен в C #, как VBA » (выделено мое).

Другими словами, у вас есть решение, которое работает и прошло интенсивное пользовательское тестирование. Вы хотите бросить все это и переписать все на языке, который вы плохо знаете. Видишь проблему?

Нам бы пришлось отказаться от того, что мы [I] сделали в решении 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, потому что мистер такой-то хочет, чтобы в его резюме были вложены х лет опыта Java». Если это веская причина для вас перейти на C #, то это нельзя игнорировать как тривиальность. Это просто не может быть одной из причин, по которой вы используете его, чтобы оправдать это перед ИТ-командой, потому что им действительно все равно, что вам нужно в вашем резюме, они заботятся о работающем продукте.

Есть также восприятие VBA, о котором стоит подумать. Я знаю, что это неправда, но я знаю немало людей, которые видят «VBA» в резюме и думают: «Что, этот парень застрял во время стажировки? Почему у него нет опыта работы с реальным языком?» Они видят «VBA» и думают «разработчик макроса Excel». Например, копирование / вставка одной ячейки в другую, выполнение простых вычислений и т. Д. Обычно люди, которые могут оценить реальное развитие в 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.

• Нам пришлось бы выбросить то, что мы [I] сделали в решении 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 и т. Д., Где это уместно, и добавляя точку с запятой в конце.

По сути, это тот же самый каркас (Excel), вы просто меняете синтаксис с VBA на C #.

Когда вы закончите, не забудьте сохранить и закрыть приложение:

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

Затем выпустите приложение с маршалом:

Marshal.ReleaseComObject(excelApplication);

Возможно, я бы написал класс-оболочку, реализующую IDisposable вокруг объекта приложения Excel, а затем обязательно использовал бы usingэтот объект.

Хороший способ обосновать свое мнение - потратить на это примерно час, что за короткий промежуток времени продемонстрирует, как быстро вы сможете переносить код, и убедит ваших коллег, что это хорошая идея.

В некотором смысле код останется в значительной степени неизменным, но у вас есть все преимущества, о которых вы упомянули, имея проект C # в Visual Studio.

Я нахожусь в том же положении, имея очень большое (более 20 000 строк кода VBA) приложение, встроенное в рабочую книгу EXCEL. После тестирования с 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 в надлежащем управлении исходным кодом, и иметь процесс Build из исходного кода для вашей рабочей книги.

ИЛИ - используйте бесплатную утилиту, такую ​​как Excel VBA Code Cleaner

Я хотел бы воспользоваться этой возможностью, чтобы освежить свои навыки в C #, так как в настоящее время я не настолько компетентен в C #, как VBA, и я бы хотел, чтобы такой проект поднял меня на «следующий уровень».

Будь честным. Планируете ли вы поделиться этой информацией с другими людьми, участвующими в принятии этого решения? Если нет, я бы возложил всю вину на вас, если проект потерпит неудачу. Поскольку подобный проект уже создан и запущен в производство, каждый сформировал то, что он ожидает, в своем собственном уме. Они знают, сколько времени понадобилось для создания последнего, и будут верить, что вы можете создать его за меньшее время (что может быть или не быть правдой в зависимости от дополнительных требований). Готовы ли вы взять на себя эту ответственность вместе с изучением нового языка?

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

Опять же, если вы чувствуете в себе сильные стороны, и создание проекта лежит на ваших плечах, делайте это так, как вы хотите. Всегда легче получить прощение, чем разрешение.