Глобально, все ок. Но каждая новая строчка сгенерированная ai это тех долг. На ревью происходит тотальный пиздец. CTO говорит о необходимости внедрении ai в Этапы ревью
Расскажите там как у вас дела, коллеги
Просто отклоняй большие MR, где есть подозрение на слоп.
>Расскажите там как у вас дела, коллеги
мы отказались от код ревью в принципе. теперь ревью агентам отдали.
если разраб проебал прод из-за своего нейрослопа, то он виноват. одного такого уже уволили.
Кайф, очевидный проеб СТО и прочих staff level типов, но уволят ваську мидла )
Да никак. Так же, как и до ии с кодом мясных коллег - всем похуй. Я не знаю, кто зафорсил эти сраные ревью, чужой код никто никогда не читает. Если лично мне нейрослоп мешает в моей задаче, я поправлю, иначе поебать. Если код работает - он хороший, а техдолг придумали шизы с окр.
>каждая новая строчка сгенерированная ai это тех долг
Хуевый из тебя лид, некомпетентный. Код от людей априори дерьмо. Возьми с гитхаба любую библиотеку средней степени паршивости и отдай на ревью ИИ - там код кишит ошибками. Люди всегда писали максимально дерьмовый код. Исключение - опенсорс личные проекты для резюме.
Этот >>3736775 прав
Я конечно не лид, но в чем проблема ревьюить через тесты? Типо есть задача, ее закрыли, ты смотришь на тесты и расширенную границу покрытия включающую твою задачу, если все ок, то закрываешь ревью, если качество покрытия тебя не устраивает, то отклоняешь мердж.
Мне вот интересно, а как вы собираетесь проводить ревью через ии агентов? Вы локально ллм разворачиваете у себя с тонкой настройкой контекста, или на платных площадках? Просто если бизнес в РФ, то сейчас сложно адекватно пользоваться зарубежными сервисами, а самому все это строить как будто бы не стоит того. Мб лучше саму архитектуру поменять разбив на те-же микросервисы, если проект на столько большой, что ревью тратит огромное количество времени
проблема в ответственности, квалификации и вовлеченности в проект. почти во всех проектах где работал, ревью было номинальным. лид со своими шавками за пару секунд проводили "ревью" и жали аппрув, задача уходила не пред-пром где все фейлилось, а шишки летели на разраба. т.к. никакой культуры разработки не было, то и тесты были говно, а продовый код был неподдерживаемым месивом куда тупо докидывали нового говна. типичная история это придти, за полгода начать пилить фитчи, а через год срулить в другую компанию, бросив помойный проект перед очередным релизом
Согласен, культура многое решает на проекте. Я вот шиз в ddd. Для средненьких по объёму проектах самое то. Главная фича, это общение с писателями тз на 1 языке. Они понимают за домены проекта исходя из своих бизнес задач, и пишут в разы внятнее что конкретно им надо. И не надо тратить кучу времени на лишние созвоны.
По поводу лидов на говнопроектах. Скажем так, даже на урезанном бюджете можно состряпать хотя бы простенькую согласованность. Если ее нет, это говорит о низких скилах самого лида. Как минимум всегда можно нарисовать график с простой структурой и общие правила стиля для кода. Новым ребятам можно дать пару дней на вход и изучение структуры/стиля проекта. Потом недельку за ними последить и поправить косяки, а дальше, если человек не совсем тупой, уже сможет самостоятельно писать относительно чисто и внятно. Но это конечно работает если проект пилится активно, а не доработки на пару часов.
Соответственно время на ревью я бы разделил на 2 этапа, 1 - первую неделю чекать соблюдение стиля и структуры, 2 - все бизнес задачи смотреть только по тестам, я выше в ветке уже писал подробнее. Так не надо будет тратить кучу времени на копание в чужом коде. Ты просто смотришь изменения в тестах, и если они соответствуют покрытию задачи, то пропускаешь, если где-то есть пробелы, то возвращаешь с комментарием, какого покрытия не хватает. Вот и все. А ковырять весь код, как будто обезьяний труд имхо.
> можно состряпать
>можно нарисовать
>можно дать
>я бы разделил
лид просто хер положит на твои "можно" и "я бы". пилишь таски которые тебе сверху спускают и все
>Я вот шиз в ddd. Для средненьких по объёму проектах самое то
единицы умеют грамотно в баундед контекст сепарейшн. еще меньше в качественный код на ддд. в основном лепят трехслойку из контроллер, сервис, рипазитари. сервис в сервис, тесты на моках и т.д.
>Главная фича, это общение с писателями тз на 1 языке
обычно они болт клали на разрабов и тупо скидывают хотелки в духе "ну сделайте норм))"
Ну тут мне видимо повезло, у меня на работе сейчас 2 писателя, которые имеют по 3 всевышних и сами огромное количество лет отработали в позициях тех диров и лидов. Сейчас один является техдиром в компании, а второй стошником. + мне дают полную свободу действий в плане проектирования архитектуры проекта и все упирается в качество продукта, т.к. сфера автоматизации тб с довольно строгим регламентом.
У нас траблы скорее по аналитикам и продажникам, т.к. все завязано на крупных контрактах, а выходить ребята на новые рынки не очень спешат, хотя сравнивая конкурентов мы имеем много уникальных фич и качество, + крепкий базис для расширения областей. Но как мне объясняли, там все по сарафанке работает, а новыми нишами никто не спешит заниматься, кроме тех дира, который по кд старается дрочить соседние департаменты.
при невозможности уволить всех, кто пишет код, проще всего уволиться самому, потому как классическая разработка уже мертва и бежит лишь по инерции. даркфактори разработка это ближайшее будущее (6 месяцев). "у всех есть все фичи и все продукты одинаковые" это среднесрочное будущее.
подписывайтесь на мой тед толк.
>Типо есть задача, ее закрыли, ты смотришь на тесты и расширенную границу покрытия включающую твою задачу, если все ок, то закрываешь ревью, если качество покрытия тебя не устраивает, то отклоняешь мердж
Как узнать что тесты покрывают все? Я напомню что хорошие тесты должны фиксировать реализацию фичи и если в дальшейшем агент или человек начнет там править код сильно, то тесты должны упасть и показать это. Если ты не прочитал техническую реализации фичи, то сложно оценить насколько хорошо написаны тесты, имхо.
>>3736775
>техдолг придумали шизы с окр
Ну это ты просто никогда не работал на проектах с 10-15 летней историей и не видел что такое реальныйт техдолг и к чему он приводит.
>если в дальшейшем агент или человек начнет там править код сильно, то тесты должны упасть и показать это
Я к тому что тесты не просто должны показывать что код работает, а еще и должны падать если кто-то потом начинает менять реализацию и бизнес логику.
Говоря о тестах которые нужно проверять, я в первую очередь имею ввиду e2e тесты. Каждая реализация новой задачи для бизнеса является сценарием. Это может быть старый сценарий с фиксами/правками. Тогда ты добавляешь в пакет тестов новые тесты для проверки работы задачи.
Если это новый сценарий, то тогда надо сделать новый пакет тестов под этот сценарий. Я нагрешил только в плане тестов, т.к. делал их через генераторы, чисто для чистоты и читабельности самих тестов. Т.е. 90+% сценариев читается как обычный вызов функций с очевидным действием, единственное что я оставил в самих тестах нетронутым, это проверки данных, на которые и следует обращать внимание для фиксации изменений.
Как понять что уровень покрытия тестов затрагивает все? Тебе и не нужно этого знать на уровне реализации, юнит тесты чекать не надо, это тесты для самих разрабов, а не для лида.То что лид должен знать, это те самые сценарии, ну извините меня, как ты можешь ставить задачу, если нет понимания, что сейчас делает твоя система, и на что она способна.
Пример, есть задача, условно добавить в лк аватарки, ты понимаешь, что это затрагивает агрегат лк, а также сущности файлов и юзера. По итогу должны быть добавлены сценарии и тесты к ним на создание, удаление, выборку и т.д. по ним + проверки, что это не обязательное добавление (твои старые тесты сценариев должны остаться неизменными и т.д.)
И самое прекрасное, что какой бы сложной не была реализация задачи, все сценарии их работы интуитивно понятны даже не разрабам. Все что должен знать лид, это понимание наличия проверок для узких мест, которые опять же крутятся внутри конкретных сущностей и агрегатов, где взаимодействие с конечным пользователем находится внутри цельного сценария. Поэтому и тесты e2e по сути своей и есть описание сценария сродне обычной документации.
>Тебе и не нужно этого знать на уровне реализации, юнит тесты чекать не надо, это тесты для самих разрабов, а не для лида
Я про разрабов говорю. Лид вообще не должен ревью кода делать в 90% пулл реквестах, разве что только в самых критичных, где прям нужна экспертиза по бизнес-процессам, и только выделенные куски этой самой бизнес логики и тесты которые ее проверяют.
А так разрабы должны сами друг у друга все коды ревьювить, а не лид должен за ними говно подчищать.
давно уже не слоп, начиная с Opus 4.6 код очень качественный пишется.
Хз, сидим на fable / opus 5, нейронка на любой пук в проекте выдает изменений на тысячи строк кода. Предпочитает переизобретать все подряд вместо выстраивания арзитектуры и переиспользования. Бардак растет, читать ПР невозможно, что происхоит в проекте уже кажется никто не знает. Это и есть слоп. То что могло бы решатся твиком 5 строчек и внятными тестами строк на 100 всегда делается минимум 300 строками программного кода + 700 строками тестов.
У нас рано или поздно просле разработки прототипа начинается процесс "деслопизации" и там просто тонны строчек кода идут на помойку
У вас:
- код говно
- не сделали с помощью самого Клода доку по асем слоям
Когда Клод вам "изменений на тысячи строк кода" делает, то код точно дерьмо. Проверил лично на говнопроекте.
Надеюсь, что тебя уволят, тупой пидор.