По части минусов, в качестве информации к размышлению, довожу до сведения свой печальный опыт использования VBA...
Главная причина, по которой я когда-то ушёл с VBA заключалась в том, что в какой-то момент времени я не смог полноценно продолжать развивать свой проект, написанный на VBA под MS Access 2003-2007. Расскажу поподробней...
Созданный когда-то мною проект представлял собой набор файлов MS Access, разделённых на клиентскую и серверную части. Клиентские представляли собой набор визуальных интерфейсов для работы с контентом, хранящимся в базе данных. Эти клиентские файлы находились на машинках пользователей. На сервере лежал основной файл, хранящий в себе базу данных. Программка задумывалась как приложение, позволяющее вести весь процесс строительства (компания занималась ремонтом как зданий, так и отдельных квартир) с нуля до сдачи под ключ. За пару лет в этом приложении (монолитом) было реализовано следующее:
1. Создана сметная программа, со своей базой данных по различным механизмам, оборудованию, материалам, перечням работ, расченками с привязкой по месяцам и коэффициентам перерасчёта.
2. Смету всегда можно было экспортировать в MS Excel. При этом все ячейки документа содержали в себе формулы, группировки строк и столбцов, а так же дополнительные листы с выборкой всех материалов и механизмов.
3. На основании сметы в программе можно был создавать формы КС-2 и КС-3 (выполнение), а так же акты приёмки работ. Результат так же экспортировался в Excel с полным набором формул, с дополнительными листами, содержащими материалы и механизмы, задействованные в ходе этого выполнения (по аналогии со сметами).
4. В программе присутствовал контроль того, чтобы не было превышения объемов работ и перерасходов материала. Если такое превышение или перерасход требовались, то в проге создавалась заявка руководству о необходимости такого превышения и оно обосновывалось. Заявка попадала руководству (которое так же пользовалось клиентом приложения) и в случае одобрения (руководство жало на кнопку "одобрить") формировался акт о перерасходе и можно было на указанный объём превышать затраты материалов (или объём работ).
5. В той же программе, после того, как смета была создана, она сначала попадала в отдел снабжения, который проверял адекватность единичных расценок по каждой позиции сметы (т.к. именно снабженец потом закупает материалы). Если все расценки, указанные в смете, соответствуют реальным, то снабженец жал кнопку "одобрено" и смета далее летела по сети к руководству. Руководство смотрело смету и одобряло либо забраковывало её (отправляло на доработку). Формы кс-2 и кс-3 программа разрешала создавать только после одобрения руководством исходной сметы. Ежели снабженец находил в смете расценки, с которыми не был согласен, то он выдавал свои замечания, помечая свой вариант расценки и отправлял это обратно, на доработку в сметный отдел.
По ходу развития проекта, мне время от времени нужно было вносить изменения в исходный код VBA, что-то изменяя или, как правило, добавляя новый функционал, о котором просили пользователи. Так же приходилось вносить правки в графический интерфейс, т.е. в формочки (диалоговые окна), на которых находились визуальные контролы, такие как кнопки, списки, текстовые поля, чекбоксы и т.п.
Вот когда программка была мною написана на VBA до указанной выше стадии, вдруг начались проблемы... К этому моменту программа уже вовсю использовалась около трёх лет. Компания была небольшой, пользовались программой около 10 человек.
С некоторых пор я заметил следующее:
В редакторе VBA, если я пытался поставить курсор мышки в конкретном диапазоне строк исходного кода в конкретном модуле, то я получал аварийное завершение MS Access. Т.е. у меня в коде были такие места, которые я в дальнейшем не мог править, т.к. банальная попытка установить курсор на строку кода, подлежащую редактированию, приводило к краху MS Access. Похожая ситуация вдруг появилась в некоторых редакторах форм: попытка подвинуть какой-то контрол (драг-дропом) или изменить его размер, так же приводило к аварийному завершению MS Access. Т.е. это происходило не везде, но только в определённых местах и всегда (с некоторых пор).
Сначала у меня появилось таких "артефактов" два (где-то через пару лет после создания проекта). Я просто запомнил эти проблемные места и в дальнейшем старался избегать их. Но со временем я заметил, что подобные "артефакты" стали появляться и в др. местах (причём очень важных), где не столь давно их не было... Я не понимал в чём дело, пытался выполнять экспорт клиентов и сервера и сохранять в др. версии MS Access, но обозначенные проблемы не исчезали. Я полагаю, что это был какой-то баг не самого VBA, но баг редактора VBA, который был встроен в MS Access. А поскольку в др приложениях используются тот же самый редактор VBA, то существует опасность того, что подобное поведение я могу словить и при программировании на VBA в др. продуктах, таких как MS Office. Я долго искал решение обозначенной мною выше проблемы на различных форумах, но так и не нашёл его.
Это была серьёзная проблема, т.к. программа уже по полной использовалась в компании. Нельзя было просто взять и выбросить её в ведро, т.к. слишком много на ней уже было завязано. Оставалось только продолжать использовать её в том виде, в котором она была на тот момент, прекратив её развитие. Для меня это был весьма ощутимый удар, т.к. в эту программу я вложил очень много сил. Собственно всё это было разработано мною в одиночку... И тут такой "сюрприз" оттуда, откуда не ждал...
Стало совершенно очевидно, что в виду обозначенных выше проблем продолжать развивать приложение в MS Acces не имеет смысла. Редактор VBA работает как чёрный ящик. Я не мог заглянуть в него, дабы понять в чём дело. Нужно было переходить на что-то более открытое и безопасное, где подобные грабли не могли бы возникнуть. Т.е. нужно переходить на что-то такое, где я бы имел возможность открывать свои исходники в банальном текстовом редакторе (при необходимости) и вносить в него правки. Для себя я решил, что больше никогда не буду писать на VBA что-то сложное, да и вообще, по возможности буду стараться избегать писать на нём, дабы избежать появления обозначенных выше проблем.
Я пошёл к руководству, рассказал о проблеме и предложил оставить текущую версию как есть и начать писать др. автономную программу, не являющуюся надстройкой над MS Access. Руководство дало добро.
В то время, помимо VBA, я имел лишь небольшой опыт работы с AutoLISP (даже не Visual LISP). Поэтому такие слова как C, C++, .NET, C# и т.п. мне мало о чём говорили. Я знал только то, что C и C++ "очень сложные языки, на изучение которых потребуется порядочно времени и сил".
В то время я думал, что ".net" - это что-то связанное с сетью. Но погуглив узнал, что это не так. Так же почитал в интернете, что изучать какой-нибудь .net-язык гораздо проще, чем изучать C\C++. Я так же прочитал, что многие программисты из существовавших на тот момент .net-языков предпочтение отдавали C#. Поэтому я стал выбирать между VB.NET и C#. Я так же видел, что книг и статей с примерами кода гораздо больше по C#, чем по VB.NET. Кроме того, посмотрев примеры кода VB.NET я сделал для себя вывод, что это совершенно др. язык (ибо кода я не понял), отличный от VBA и имеющий с ним лишь некоторое синтаксическое сходство. После того, как я один вечер почитал основы по C#, я понял, что его синтаксис мне нравится гораздо больше, чем синтаксис VBA и VB.NET (это помимо того, что обучающих мануалов по C# было так же значительно больше чем по VB.NET). Так я принял решение, что уходить с VBA буду на C#.
Затем в нашей стране наступил кризис. У компании возникли существенные проблемы с заказами и она стала разваливаться (там уже руководству было не до моих программ)...
Потом я наблюдал метания автодеска - то "срочно уходите с vba", то "можете ещё некоторое время посидеть на vba", что так же не было плюсом в копилку VBA...
Вот таким был мой печальный опыт использования VBA.
