Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
сомнительно, местами криво - но как же о-ху-е-н-н-о!
Больше всего кайфанул от скорости, у меня литнеры дольше работают чем этот комплекс.
Из забавного - кривой вайбкодинг-проект оно оценило очень высоко, а сложную проработанную и провереную до кровавых мозолей тулзу на уровне джуна/мидла))
Но я не думаю что проблема с тем, что оно гонит много невалидного - я просто пробегая глазами уже вижу что актуально и нужно обратить внимание, а что мусор.
Но самое главное это киллер-фича для кодовых агентов!
То что оно может в MD очень круто (сразу видно человек думал сразу в комплексе) - быстрая тулза в помощь кодовым агентам, для улучшения вайбкодинга.
Вам бы еше правила/инструкции в бинарь зашить, что бы можно одной cli-командой получить подробную инструкцию и можно на ее основе строить скил который будет востребован. Главное прописать что бы не верило в анализ, а использовало его в качестве точки отчета.
подтверждаю такие моменты
Вайбкодинг оно оценивает выше реальности. Даже если это вайбкодинг по плану с проверками и тд что бы попасть в бизнес-логику то такое все равно ниже по оценке чем чистый вайбкодинг
Не всегда подхватывает больше проекты. Может у меня такой стиль, но 1/5 только распознало более менее, остальное явно пропустило целые папки и модули что используются.
Странная система оценок - может мелкой фигне поставить джун/мид/сеньйор, а может огромному проекту с годами истории коммитов оставить без оценки.
Лучше всего работает с вебом. Голанд 20-30% ориентировочно, Си столько же, хотя определяет вроде-бы все файлы в отличии от Го.
В целом как я понял чуда не произошло и такая ошеломительная скорость потому что оно не замечает большую часть кода на больших проектах. Огромный фронт-енд проект он уже прожевывал ожидаемо несколько секунд и в анализ все файлы вошли.
Но все равно я думаю полезная тулза, допилить бы ее только что бы или можно точечно на модули и подмодули фокусировать для анализа или что бы таки захватывало все, пусть и ценой долгих рассуждений на анализ.
Я еще пилю слоп-детектор, а сколько строк кода в навайбкоденном?
Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта
Core команде проще: разработчик знает, что если он сейчас схалявил, ему ещё несколько лет жить с этим. Но это должен быть долгий жизненный цикл и доверие команде.
А вот когда команды начинают бешено тасовать по проектам/продуктам тогда и получается продукт без хозяина. Product owner даже если и есть (а скорее, его нет или 1/10 ставки/FTE из экономии) за этим не уследит.
За 12 лет в роли тимлида и архитектора
вы так и не научились кратко объяснять. Так какую метрику вы хотите минимизировать? Эти, которые на экране? Методики расчета есть? Обоснованные оценки их влияния на бизнес результаты есть?
А те, кто получает неуд становятся очень нервными. Они вам ещё не вломили?
Для оценки компетенций это конечно же не годится.
Но неплохо иметь постоянный контроль проекта за метриками деградации. Только они для каждого проекта разные. И когда метрика превысила порог значит техдолг/архитектура уже требует ремонта
Например
Категории:
1. Контрактная гигиена (связь с каскадной системой)
2. Доменная целостность (illegal states)
3. Слоистость/зависимости
4. Тестовое покрытие/ археология
5. Изменчивость/частота правок
на soft-skills у нас Data Science еще был 5 лет назад, я кстати более ценные для корпорации измеряю, типа насколько разработчик ориентирует в корп-ландшафте
Спасибо за метрики, некоторые в динамике измеряю тоже
некоторые есть в моем стат-анализаторе, Spec-coverage еще вот надо тюнить
Честно говоря, такие метрики вызывают большое раздражение.
Допустим, я применил тут анемичную модель, потому что это бизнес правило относится только к конкретному сценарию, а не к всему домену. И что? Какие-то оценки моих компетенций? Ты спроси почему я отошёл от типичных паттернов, я тебе объясню что другие архитектурные свойства были важнее.
Большая часть метрик это просто code style, а проверка обходится, команда пойдет оптимизировать код под них. Переименовывают DAO в Entity, добавляют папку /domain/, получают зеленый радар и думают, что работают хорошо.
Да, метрики я бы контролировал. Но не для программиста, а для проекта. Для программиста всё сильно сложнее.
Запомни студент: сейчас к людям надо помягше а на вопросы смотреть ширше©
Вес анемичности моделей не настолько высок в вычислении сеньорности кода
кстати когда у нас бизнес-требования хорошо изолированы у нас лучше DDD получается, давно наблюдаю эту закономерность.
В остальном оценка не упирается в конкретные паттерны.
Я могу согласится что следование DDD не везде обосновано, ну и поэтому не такой большой вес у этой метрики.
К людям я мягок, так как еще параллельно преподаю эти 12 лет, и вырастил многих c уровня trainee/junior
Меня никто никогда не учил. Бросили в воду и плыви как хочешь.
Но я всегда был первым/главным или максимум вторым человеком в проекте (в небольших долго живущих командах это не удивительно) и понимал свою ответственность и сам от себя требовал обоснованность решений и проводил post mortem.
Что в больших командах творится не знаю даже. Если мои компетенции так будет мерять у меня глаза на лоб полезут
Я специально не делал разбор по коммиту -- хотя это возможно. я понимаю что можно оценить кодовую базу только целиком.
Кстати своей команде я так уже не раз собирал техдолг и очень бодро его всегда делали и даже сейчас.
Всех же false positive не выловишь и отчет можно еще прогнать через LLM на выявление онных, и отчет -- это точка отсчета для архитектурного анализа, поэтому там везде ссылки vscode://
За 12 лет в роли тимлида и архитектора я написал десятки матриц компетенций и сам и прошел и провел сотни перформанс-ревью. И каждый раз инженерная часть оценки оставалась самой невнятной.
Да, это имеено то, что нужно делать для оценки того, как человек пишет код.
Поэтому уже пора разработчиков оценивать иначе: не по количеству написанного кода, а по качеству инженерных решений, которые они принимают каждый день.
90% таких решений это - тяп-ляп и в продакшен, а там зажариться как-нибудь. И да, смысла от оператора LLM требовать инженерии как-то глупо, так как для этого нужно хотя бы своим мозгом обладать.
Пожалуйста, вставьте в начале статьи большой дисклеймер: "ЭТО МЕТРИКИ, А НЕ ЦЕЛЬ!"
Даже если для вас это очевидно.
И, да, многим даже высшим менеджерам всё ещё нужно рассказывать про закон Гудхарта.
В целом - штука отличная, но "продающий" заголовок и связанные с ним пояснения сделали из отличного инструмента для отслеживания параметров кода - концепцию, которую ненавидят все адекватные разработчики мира, отличающуюся от замера по "количеству строк кода" только сложностью :)
Я тут полностью согласен. Но я за то чтобы метрики для разработчиков делали сами разработчики.
Так как наблюдаю как за последние лет 5 в двух компаниях измеряли разработчиков абсолютные профаны: один по коммитам (что еще не самое плохое), второму вообще не знал зачем нужен DevOps и он мерил зарплатами 😁 и это люди которых ставили и им доверяли CIO
Поэтому разработке лучше самим навязывать свои метрики, до того как придут профаны, коих на рынке сейчас много
Я бы не хотел, чтобы меня измеряли. И тем более работать в команде, где твою “эффективность” оценивают по непрозрачным метрикам
Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объективно грейдим разработчика по коду