Совместная разработка, и как найти лентяя в команде. История о том как я пришёл к созданию плагина для OpenSource. Если у Вас закрались в голову мысли, что один из персонажей не работает, я думаю этот инструмент будет для Вас полезен.А чтобы не читать всю статью инструменты можно быстро посмотретьJETBRAINS MARKETPLACEVISUAL STUDIO MARKETPLACE Найти лентяя
Всем хорошего дня или вечера, Хабровцы! Это моя реальная история о том, как однажды в команде разработчиков .NET-стека появился лентяй, который «лутал» денежки, пока все остальные работали в поте лица.
ПредысторияНачалось всё в прошлом году: мне поступило предложение создать сайт с личным кабинетом и приложение для телефона — приложение, которое по фото ищет совпадения (не суть важно, что за приложение).
Я, как разработчик .NET, изучил материал, оценил возможности, составил архитектуру проекта и принял решение о численности команды.
Архитектура продумана и понятна, план работы расписан, команда собрана — приступаем.
Первые два месяца работаешь с энтузиазмом и ничего не замечаешь, деньги платят нормально.
Тесты → созвоны → обсуждения → рассуждения → созвоны → тесты...
Хотя кому я объясняю? Вы и сами всё понимаете — будни разработчика.
Вот когда уже на горизонте показывается что-то более-менее похожее на приложение, начинаешь понимать масштаб проделанной работы. Вроде три месяца ты писал, а результат мог бы быть намного лучше. В нашей команде не было лидера как такового — я собирал команду и строил архитектуру, точнее её часть, но руководителем группы я себя не считал, хотя это было необходимо.
Захотел я разобраться, кто и что делает, почему, вроде, ты работаешь, все работают, а прогресс медленный. Решил посмотреть на изменения в Git: у каждого своя ветка, иногда работаем в одной. Начал изучать ветки репозитория и понимаю, что их не 4 и не 10, а целых 17. Для тестов, для проверки фич, чтобы попробовать... Переключаясь по веткам, понимаю, что кто-то мог не слить ветки, и коммитов просто гора. А как посмотреть, кто что делал именно в ветке после пяти месяцев разработки в режиме ежедневных 3–4 коммитов? Это утомительно.
Обратился я к могучему Google. Может быть, есть инструменты, которые позволяют просматривать репозиторий? И оказалось, что инструментов практически нет. Есть просмотр DIFF, информация о количестве коммитов у разработчика, но нужны его доступы... Словом, я пошёл неверным путём.
У меня были сомнения, что один из наших Антигероев просто сидел и делал коммиты по типу:
var a = 1;
Следующий коммит :
var a = 1; //Поставил коммит
И вот по такой схеме он работал, хотя код писать умеет. На созвонах вроде присутствует. Тогда я не знал, как он на самом деле работает — это выяснилось позже. По истечении восьми месяцев мы сдали проект, все получили свои кровные за труд, но справедливости не было — вот что меня бесило. Потом, конечно, я прошёлся по веткам, всё изучил и понял, кто был камнем в команде, но было уже поздно.
И вот спустя несколько проектов я задумался: я пишу программы и какие-то разработки под себя, а в Open Source я практически ничего полезного не написал. Опыт позволяет, время есть... Открыл я свои старые репозитории. Подумал: обновлю и выложу в открытый доступ. Кому надо — найдёт.
Старые репозитории из времён, когда опыта было мало — это настоящий ящик Пандоры.
Не найдя для себя ничего полезного в старом коде, я решил создать плагин для Visual Studio, который решал бы проблему «нахлебников». А почему бы не сделать полноценное расширение?
Как и что происходило, я думаю, не стоит описывать подробно.
Создаёшь аккаунт на маркетплейсе Microsoft, создаёшь карточку продукта, заполняешь данные и выкладываешь.
Моя идея была в том, чтобы можно было посмотреть, кто сколько файлов накомитил и сколько коммитов сделал.
Реализация заняла три полноценных дня или неделю в режиме расслабления — и плагин готов.
Конечно, на первых этапах выглядело ужасно:

Одна из первых итераций
Но немного поигравшись с XAML, привёл к более приличному виду:

Последняя итерация

Как будто тут и было.
Готово!
Плагин этот — Open Source и полностью бесплатен.
Это мой первый опубликованный плагин, и я очень горжусь тем, что он в магазинах и есть скачивания. Не знаю, насколько он актуален для вас, может быть, у вас уже есть свои инструменты. Но если интересно, как устроен плагин и какие библиотеки используются — пользуйтесь, модифицируйте. Наверняка уже есть сотни таких решений, и моё не уникально. Но это мой первый.
Возможно, ваше видение поможет в обновлении плагина.
Плагины доступны для Visual Studio и для Rider:
P. S. Ссылка на исходник есть в магазине приложений.
P. P. S. В голове и в процессе реализации есть другой плагин для совместной работы, и он уже почти готов. Когда есть Visual Studio Live Share, а для Rider — Code With Me, Live Share часто тормозит. Rider работает нормально, но только при временном нахождении в других странах. Чтобы всё работало через один плагин — такого я не видел. Но эта история будет в следующей главе.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Ваш агент не тупой — ему просто неудобно | 0 | 6.87 | 28-07-2026 |
| 2 | Ты не найдёшь эту ошибку. Потому что её нет в твоём коде. Как Self-describing API спасает от чужих рефакторингов | 5 | 8 | 07-07-2026 |
| 3 | 7 месяцев вайбкодинга: как в одиночку делать то, что раньше требовало команду | 0 | 9 | 01-08-2026 |
| 4 | Почему ваш GitLab CI медленный: 6 ошибок в настройке Runner | 0 | 7 | 13-07-2026 |
| 5 | Адаптация в команде есть? А если найду? | 0 | 5 | 17-06-2026 |
| 6 | GitFlic CI/CD: первый конвейер с нуля — от коммита до деплоя | 0 | 5 | 07-07-2026 |
| 7 | Продакшн‑разработка в одиночку с AI‑агентами: принуждай к правилам, а не объясняй их | 0 | 8.25 | 24-07-2026 |
| 8 | Ленивый LINQ: разбираем yield и ленивые вычисления по кирпичикам | 0 | 7.44 | 21-07-2026 |
| 9 | Один файл, одна команда: как мы упростили запуск dev-окружения с помощью Runium | 0 | 12.11 | 24-07-2026 |
| 10 | Вводим рейтинг по алкоголизму | 0 | 11.18 | 25-07-2026 |