Крутые расширения Visual Studio имеют несколько ключевых признаков, которые отличают их от остальных. Они выглядят и на самом деле хорошо продуманы, функциональны и надежны. Кроме того, они делают то, что должны, до уровня совершенства и нативно вписываются во внутренние функции Visual Studio.
Чтобы упростить написание хороших расширений, мы работаем с сообществом над разработкой простого чек-листа. Существует даже GitHub issue template, который вы можете использовать. В этой статье рассмотрим 9 правил крутого расширения. Подробности под катом.
Следующий список не имеет порядка. Не забудьте выполнить все правила для достижения наилучших результатов.
Добавьте пакет NuGet Microsoft.VisualStudio.SDK.Analyzers в свой VSIX проект. Это поможет вам обнаружить и устранить распространенные ошибки в отношении потоков.
Все расширения должны иметь значок, связанный с ними. Убедитесь, что значок представляет собой высококачественный файл .png с разрешением 128×128 пикселей и DPI 96 или больше. После добавления значка в проект VSIX зарегистрируйте его в файле .vsixmanifest как значок и изображение для предварительного просмотра. В Visual Studio Marketplace используется более крупный значок, и ваш будет динамически изменяться при отображении в Visual Studio.
Исследования показывают, что пользователи чаще устанавливают расширения с короткими описательными именами и точными данными о них. Убедитесь, что имя отражает суть того, что делает расширение. Описание в файле .vsixmanifest должно создавать ожидания относительно того, что делает расширение. Итого, краткое описание того, какие проблемы решает расширение и какие его функции являются ключевыми.
Это одна из самых важных вещей, которую вы должны сделать, чтобы ваше расширение стало успешным. Хорошее описание состоит из:
Лицензия отображается в Marketplace, в установщике VSIX и в диалоговом окне Extensions Manager. Всегда указывайте лицензию, чтобы создавать ожидания для пользователей. Подумайте о том, чтобы использовать choosealicense.com для поиска подходящей лицензии. Причиной этого правила является устранение любой неоднозначности, что важно для многих пользователей Visual Studio.
Если расширение собирает данные, например телеметрию, добавьте примечание об этом в описании.
Visual Studio поставляется с тысячами значков, которые доступны в коллекции KnownMonikers. При добавлении значков к кнопкам проверьте: возможно вы можете использовать существующие значки KnownMonikers, ведь они являются частью языка проектирования, знакомого пользователям Visual Studio. Вот полный список KnownMonikers, а также можно использовать расширение KnownMonikers Explorer, чтобы найти подходящий для ваших сценариев.
Следуйте тем же шаблонам и принципам проектирования, которые использует сама Visual Studio. Это делает расширение естественным для пользователей. Это также уменьшает отвлекающие факторы, вызванные плохо проработанным пользовательским интерфейсом. Убедитесь, что все кнопки, меню, панели инструментов и окна инструментов по умолчанию видны только тогда, когда пользователь находится в правильном контексте для их использования. Есть несколько правил:
Может быть заманчиво поддерживать версии Visual Studio вплоть до Visual Studio 2010, чтобы каждый мог использовать ваше новое расширение. Проблема заключается в том, что при этом больше нельзя использовать API, представленные позже, чем та старая версия, которую поддерживает расширение. Часто эти новые API важны и помогают повысить производительность и надежность как вашего расширения, так и самой Visual Studio.
Вот наши рекомендации по принятию решения о том, какие версии Visual Studio поддерживать:
Что вы думаете об этом чек-листе? Согласны ли вы с правилами? Пожалуйста поделитесь мыслями ниже в комментариях или в репозитории GitHub. Я надеюсь чек-лист поможет вам создавать крутые расширения, которые станут действительно популярными.
Чтобы упростить написание хороших расширений, мы работаем с сообществом над разработкой простого чек-листа. Существует даже GitHub issue template, который вы можете использовать. В этой статье рассмотрим 9 правил крутого расширения. Подробности под катом.
Правила
Следующий список не имеет порядка. Не забудьте выполнить все правила для достижения наилучших результатов.
Правило 1: Придерживаетесь правил потоколирования
Добавьте пакет NuGet Microsoft.VisualStudio.SDK.Analyzers в свой VSIX проект. Это поможет вам обнаружить и устранить распространенные ошибки в отношении потоков.
Правило 2: Добавьте иконку в высоком качестве
Все расширения должны иметь значок, связанный с ними. Убедитесь, что значок представляет собой высококачественный файл .png с разрешением 128×128 пикселей и DPI 96 или больше. После добавления значка в проект VSIX зарегистрируйте его в файле .vsixmanifest как значок и изображение для предварительного просмотра. В Visual Studio Marketplace используется более крупный значок, и ваш будет динамически изменяться при отображении в Visual Studio.
Правило 3: Название и описание
Исследования показывают, что пользователи чаще устанавливают расширения с короткими описательными именами и точными данными о них. Убедитесь, что имя отражает суть того, что делает расширение. Описание в файле .vsixmanifest должно создавать ожидания относительно того, что делает расширение. Итого, краткое описание того, какие проблемы решает расширение и какие его функции являются ключевыми.
Правило 4: Напишите хорошее Marketplace-описание
Это одна из самых важных вещей, которую вы должны сделать, чтобы ваше расширение стало успешным. Хорошее описание состоит из:
- Скриншотов/гифок того, что будет добавлено расширением
- Подробного описания фич
- Ссылок на детали, если необходимо
Правило 5: Укажите лицензию
Лицензия отображается в Marketplace, в установщике VSIX и в диалоговом окне Extensions Manager. Всегда указывайте лицензию, чтобы создавать ожидания для пользователей. Подумайте о том, чтобы использовать choosealicense.com для поиска подходящей лицензии. Причиной этого правила является устранение любой неоднозначности, что важно для многих пользователей Visual Studio.
Правило 6: Добавьте уведомление о конфиденциальности
Если расширение собирает данные, например телеметрию, добавьте примечание об этом в описании.
Правило 7: Используйте KnownMonikers где возможно
Visual Studio поставляется с тысячами значков, которые доступны в коллекции KnownMonikers. При добавлении значков к кнопкам проверьте: возможно вы можете использовать существующие значки KnownMonikers, ведь они являются частью языка проектирования, знакомого пользователям Visual Studio. Вот полный список KnownMonikers, а также можно использовать расширение KnownMonikers Explorer, чтобы найти подходящий для ваших сценариев.
Правило 8: Создайте ощущение нативности расширения
Следуйте тем же шаблонам и принципам проектирования, которые использует сама Visual Studio. Это делает расширение естественным для пользователей. Это также уменьшает отвлекающие факторы, вызванные плохо проработанным пользовательским интерфейсом. Убедитесь, что все кнопки, меню, панели инструментов и окна инструментов по умолчанию видны только тогда, когда пользователь находится в правильном контексте для их использования. Есть несколько правил:
- Никогда не добавляйте новое меню верхнего уровня (рядом с Файл, Изменить и т.д.)
- Никакие кнопки, меню и панели инструментов не должны быть видны в контекстах, к которым они не относятся
- Если необходима автозагрузка (скорее всего нет), сделайте ее как можно позже.
- Используйте VisibilityConstraints для переключения видимости команд вместо того, чтобы полагаться на автоматическую загрузку
Правило 9: Используйте правильные диапазоны версий
Может быть заманчиво поддерживать версии Visual Studio вплоть до Visual Studio 2010, чтобы каждый мог использовать ваше новое расширение. Проблема заключается в том, что при этом больше нельзя использовать API, представленные позже, чем та старая версия, которую поддерживает расширение. Часто эти новые API важны и помогают повысить производительность и надежность как вашего расширения, так и самой Visual Studio.
Вот наши рекомендации по принятию решения о том, какие версии Visual Studio поддерживать:
- Поддерживайте только предыдущую и текущую версии Visual Studio — по возможности не поддерживайте более старые версии
- Не указывайте диапазон доступных версий. Например. [16.0,). Узнайте больше о версиях тут.
Ваше мнение
Что вы думаете об этом чек-листе? Согласны ли вы с правилами? Пожалуйста поделитесь мыслями ниже в комментариях или в репозитории GitHub. Я надеюсь чек-лист поможет вам создавать крутые расширения, которые станут действительно популярными.
