Расскажите про опыт создания расширений редактора

Что проверяют

Понимаете ли вы, что расширение живёт внутри чужого процесса. Его нельзя блокировать, оно обязано играть по правилам хоста насчёт потока интерфейса и запускаться так, чтобы не тормозить старт. Плюс смотрят, знакомы ли вы с Roslyn: разбор кода по синтаксическому дереву и семантической модели это отдельный навык, а не обычная бизнес-логика.

Как отвечать

Начните с того, какую боль закрывало расширение и сколько человек им пользовались. Дальше по существу:

• формат: пакет расширения для среды разработки, анализатор на Roslyn, который поставляется обычным пакетом и работает в том числе в сборке, или генератор кода;
• что именно писали: диагностики и быстрые исправления через DiagnosticAnalyzer и CodeFixProvider, окно инструментов на WPF, команды в меню, подсветку или подсказки;
• глубина анализа: где хватило синтаксического дерева, а где понадобилась семантическая модель, чтобы узнать реальный тип или найти все использования символа;
• потоки: асинхронная инициализация, явное переключение на поток интерфейса, отказ от блокирующего ожидания внутри обработчиков;
• поставка и совместимость: как раскатывали на команду, что ломалось при выходе новой версии среды.

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

Где спотыкаются

Путают анализатор и расширение среды. Анализатор едет вместе с проектом, работает у всех и падает на сборке в CI. Расширение ставится каждому разработчику отдельно и в CI не участвует.

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

Приносят проценты вроде «сократил время написания кода на треть». Это выдуманная метрика: замера до и после не было, а вопрос о методике подрывает доверие ко всему рассказу.