Комментарии 6
У разработки кастомных расширений под проект есть пара недостатков. Во-первых, вся команда привязывается к одной IDE и даже к одной версии IDE. А значит, если кто-то предпочитает Rider, скажем, то ему придется подстраиваться под остальных. Равно как любителям попробовать новейшие превью версии придется ждать обновления расширения под новую студию. Плюс, со временем к проекту могут подключаться внешние подрядчики, у которых может не оказаться лицензии на нужную версию той же студии.
Кроме того, есть тенденция, что с уходом основного драйвера, развивавшего расширение, его поддержка прекращается, заморозившись на какой-то версии. И все это работает до первого ломающего изменения, после чего перед организацией встает выбор: или оттягивать обновление до последнего (и продолжать работать на VS10 в 2021) или всей команде перестраивать процессы, привычно автоматизированные в расширении.
Не утверждаю, что так бывает всегда, но это то, с чем сам сталкивался.
Если 10 человек работают со студией, а пара человек нет, то все норм! Даже если пополам, тимлид же знает, кто быстрее создаст новый проект в решении или добавит новых контроллеров. Следовательно, задачи уйдут кому нужно.
Расширения со старых версий студии чаще всего отлично перекочуют в новую версию, если, конечно, не будет меняться версия платформы и языка самого проекта.
Если работает 5 человек в студии и 5 в райдере и проект долгий, можно создать расширения для обоих IDE. А можно вообще основать всю логику на шаблонах для дотнета, а в расширение встроить необходимую инфраструктуру для включения их в IDE. Можно завязаться на генераторы Т4. Да хоть на скрипты PS. Тогда получится своего рода кроссплатформенность. Как Xamarin. У тебя есть корневой функционал, но UI ты делаешь для iOS и для андрюши отдельно. Да, будет сложнее поддерживать, но о целесообразности нужно думать в каждом конкретном случае. Я же предложил подход, чтобы было вообще о чем думать. А примеры затачивал под студию, потому что большинство известных мне дотнетчиков работают именно в этой IDE.
Да-да, я согласен. Писал не с целью критики подхода, а чтобы дополнить статью соображениями о возможных подводных камнях на периоде от 5 лет и больше.
Плюс, при команде условно в 10 человек проблем будет меньше. Они начнут проявляться на уровне 30-50 человек, т.к. для большинства инструменты по автоматизации будут являться черным ящиком, который либо работает, либо нет.
Пользовательские шаблоны и расширения для Visual Studio под проект (Часть 4: пользовательские расширения)