Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот и давай обсудим. Для выяснения.

PD>Раз тесты отдельно, ИИ — отдельно, значит на мой вопрос о том, запускает ли он тесты под собой в стиле профайлера, ответ — нет, не запускает.

PD>Впрочем, ты это фактически сам признал, дезавуировав (удалив) свое заявление. Но RSDN все помнит.
Я ничего не дезавуировал. Просто не нужно читать то, чего нет в тексте

S>>При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.https://pvs-studio.com/en/blog/posts/cpp/0543/
Всё верно. Сначала запускаем компилятор. Он отлавливает ошибки типизации.
Потом линтер — он отлавливает нарушения конвенций и сомнительные места, которые компилятор не проверяет.
Хорошие линтеры могут делать довольно сложные проверки (см. напр. PVS Studio).

Потом юнит-тесты — они проверяют соответствие кода решения коду тестов

И вот когда все это уже отработало, и можно бы уже и PR мерджить, приходит ИИ. И всё ещё находит проблемы, которые ни один из предыдущих инструментов не увидел.
Так понятно?

PD>Я готов допустить в принципе, что он тут лучше других статических анализаторов. Есть некоторые сомнения, просто из тех соображений, что авторы той же PVS Studio ее десяток, если не больше, лет пилят и всех собак в округе съели, а тут явился кто-то и одним махом их всех превзошел. Но допустим все же.
Не обязательно "превзошёл". Он делает очень много из того, что PVS Studio не делает и не может делать (по крайней мере, до тех пор, пока внутрь неё не завернут LLM).
Например — проверить, не нарушает ли PR какие-то из правил, которые написаны в документах проекта на естественном языке.
PD>Но любой статический анализ никогда не может дать ту информацию, которую дает анализ в рантайме. То есть анализ, проведенный профайлером или Code Coverage.
Это работает в обе стороны.

PD>Например Code Coverage мне покажет каждую строчку, которая не выполнялась при прохождении тестов. Он не будет говорить, что тут что-то неверно, да, но он четко скажет, что вот этот if или else или метод никогда не выполнялся, а значит, верно тут или нет — при данном наборе тестов вообще неизвестно. Я своих студентов в это тыкал постояннно.
Конечно. Но code coverage работает в одну сторону, а ИИ умеет в противоположную: "сделай code coverage = 95%".

PD>Ну а что тут еще может добавить профайлер — думаю, сам знаешь, лень описывать. Например, может ли твой ИИ сказать, сколько раз выполнялся этот метод ? Кто тут главный потребитель времени ? Кто тут больше всего создает мусора в хипе ? Я уж молчу про взаимодействие потоков и дедлоки.
Перед ИИ не ставится такая задача. Вернёмся к старту топика:

1. Освоить имеющийся материал по этому фреймворку
2. Применить эти знания на практике, то есть сделать код с использованием его для конкретной задачи
3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
4. Разработать свой код в качестве contibutor и предложить pull request
5. Принять этот pull request (или отвергнуть его)
6. Внести изменения в release и сделать следующую версию.

Где тут "сколько раз выполнялся данный метод"? Нету? Ну и правильно. Потому что мы обсуждаем темы уровня "принять этот PR или отвергнуть". Сможет это сделать профайлер?
При этом ИИ запросто может работать по инструкции вида "посмотри на результат бенчмарков, и если PR замедляет ключевые бенчмарки хуже, чем X, запусти тесты под профайлером и предложи способы оптимизировать места основного вклада в это замедление".

PD>Вот так и ИИ войдет в этой области.


PD>Вполне принимаю. Пусть ищет. Еще один инструмент.
Всё верно. Он не заменяет существующие инструменты. Он работает поверх них.

PD>Тогда тем более я должен бояться изменений, которые сделает ИИ. IDEA все же делает их локально, в пределах нескольких строк. Если не понравится это точечное изменение — откачу, и все. А тут какой-то глобальный анализ, затрагивающий много строк разных файлов, и я совсем не уверен, что там все будет сделано правильно. А в итоге — мой код уже не мой код, и я ему как своему доверять не могу. И не коллега его правил. С коллегой можно побеседовать, он объяснит, почему он такие изменения сделал, обсудим, может, он признает, что где-то неправ, может, я признаю. А тут мне что, дискуссию с ИИ начинать ?
А почему нет? Он прекрасно поддерживает такие дискуссии. И изменения показывает, и обосновывает почему. И ошибается, бывает — и так же, как коллегу, ему на это указываешь, и он исправляет. В отличие от коллеги, он доступен 24 часа в сутки, и не начинает ныть, что ты придираешься, и что он устал, и вообще ты сам должен понимать, что тут написано, а если нет — иди нафиг, не умеешь ревьювить — не берись.

PD>И даже если удастся ее провести, а ну как его аргументы меня не убедят ? Я такого намного больше боюсь.
Не убедят — не примешь изменение. Делов-то.

PD>Я с этим согласен. Пусть делает, ничего плохого. Только все же лучше пусть код не правит, а представит мне на рассмотрение со своим аргументами.
Всё так и работает. Не, можно вайбкодить и в стиле "напиши мне какую-нибудь сетевую игру. Не трогай меня, пока всё не будет готово", но результат будет не сильно лучше, чем если такую же задачу поставить десятикласснику.
А в нормальном подходе разработка ведётся в режиме диалога. Ставишь задачу — он обрисовывает варианты её реализации, ты утверждаешь какой-то из них (или объясняешь, почему ни один не подходит, и вы продолжаете дискуссию до принятия решения), это документируется. Если решение затрагивает другие, уже решённые задачи — в их спецификации вносятся исправления, или, наоборот, в текущую доку вносятся исправления, чтобы противоречий не было.
Дальше он к этой реализации предлагает варианты архитектуры, ты утверждаешь какой-то из них. Точно так же — если где-то в документах есть что-то несогласующееся с новой архитектурой, это обсуждается и правится.
Дальше он предлагает тест-план, который опять же утверждаешь ты. Потом он пишет тесты по этому плану, потом код. Потом гоняет код и тесты, пока они не заработают. Потом он замеряет coverage и добивает тесты до нужного уровня покрытия. Потом, если надо, выполняется бенчмаркинг, анализируются результаты, и ты принимаешь решение — обновить требования перформанса, или оптимизировать. Предлагаются варианты стратегий оптимизации, обсуждаются. Утверждённый вариант документируется, и так далее.

PD>А то ведь может крайне неприятная ситуация возникнуть. Вот есть у меня код, который я писал и тестировал несколько лет назад. Я ему вполне доверяю и о нем не думаю. А в нем ошибка все же есть, только она никогда не проявлялась, так уж вышло. Я этот код в новый проект вставил, без анализа. Он ошибку в нем нашел. Спасибо ему. И поправил. И неверно поправил, потому что он что-то в моем коде не понял. И результатом этого исправления будет вот что. Код будет работать иначе для этого редкого случая, может и лучше. Вот только в половине остальных обычных случаях он работать перестанет. И что мне теперь делать, если, начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей
Как что? Прогнать цикл регрессионного тестирования, естественно. Не может же быть такого, что код был не покрыт тестами? А если вдруг так случилось, что был непокрыт, то надо не с поиска ошибки начинать, а с фиксации дизайна в тестах и подъёме покрытия до 90-95%. А уже потом рассматривать любые идеи про починку. ИИ тут ничего не меняет — ну, кроме 10х подьёма продуктивности разработчика, поэтому те вещи, которые раньше откладывались с мыслью "да тут полгода пердолиться нужно" делаются за выходные.