Решил погуглить, что последний год пишут на тему "поиск ошибок в коде". Раньше находились статьи про разные инструменты, сейчас всё забито статьями с общим названием "Нейросети для поиска ошибок в коде". Заглянул внутрь, например, этой: "Исправить код с помощью нейросети: ИИ для исправления ошибок в коде на Python, JavaScript и в больших проектах".
Спасибо за статью. Не согласен, со словом «нет» в ячейке таблицы: статический анализ – анализирует сквозное влияние изменений.
На самом деле, анализаторы кода уже 100500 лет умеют видеть контекст всей кодовой базы и замечать, как изменение повлияет на работы функций в других файлах. Для этого используются такие технологии как межпроцедурный и межмодульный анализ потока данных.
Естественно, заставляя инструмент анализировать изменения в конкретном файле (инкрементальный анализ) обрубается/усложняется возможность заметить, как эти изменения влияют на другие части проекта. Но и проблемы как таковой нет. Достаточно время от времени выполнять полную проверку проекта, когда включен межмодульный анализ.
Более того ГОСТ Р 71207—2024 (Статический анализ программного обеспечения) явно предписывает выполнять оба вида анализа (см. п. 5.6.).
Статический анализ добавленных или измененных частей ПО следует выполнять после каждого внесенного изменения.
Статический анализ всего разрабатываемого ПО следует выполнять не реже одного раза в 10 рабочих дней, если за данный период времени исходный код был изменен.
Суть – быстро ловим многие ошибки в момент их внесения в код. Время от времени выполняем полный (к сожалению, часто весьма медленный) анализ и выявляем баги при взаимодействии разных модулей. См. вебинар про процессы статического анализа по ГОСТ Р 71207–2024.
Раз история продолжается, я и здесь продублирую позицию по таким комментариям.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Так что это вполне себе метод векторизации, хотя и да, сильно зависимый от компилятора.
Это не метод, а хрень. Это худший вариант кода, что подтверждается замерами. То, что выглядит как оптимизированным, вовсе не обязано таким являться. Вариант с | это уже другой код.
Забыл в статье ещё вот на этот пост сослаться, который мне понравился и который транслирует схожие мысли:
...
Главный риск ИИ-кода — не в том, что он плохой, содержит баги, уязвимости и т.п. В том-то и беда, что он выглядит убедительно хорошим. Агент выдаёт что-то, что компилируется, проходит тесты, рендерит красивый UI. И возникает непреодолимый соблазн пустить это в прод, не заглядывая внутрь.
Нет. Тесты это только часть подхода к качеству. Они не заменят построение архитектуры, контроль заимствованных компонент (SCA), проверку оптимальности выбранных алгоритмов и т.д. Не цепляйтесь за одну лучшую методологию. Тесты хорошо, но недостаточно.
Вы можете сами это легко сделать. Проект состоит из одного файла. Скормите его нейронке и попросите её подробно написать, что не так. Потом расскажите :) Я делал такое, глянул на выхлоп и закрыл. Мне такой фигнёй (сравнением) заниматься не интересно.
Даже приблизительно спрогнозировать не могу :)
Да, но нет :)
Я сегодня как раз делился наблюдением в заметке Минутка улыбок сеньоров, возящихся с legacy-проектами. :)
Спасибо за статью. Не согласен, со словом «нет» в ячейке таблицы: статический анализ – анализирует сквозное влияние изменений.
На самом деле, анализаторы кода уже 100500 лет умеют видеть контекст всей кодовой базы и замечать, как изменение повлияет на работы функций в других файлах. Для этого используются такие технологии как межпроцедурный и межмодульный анализ потока данных.
Естественно, заставляя инструмент анализировать изменения в конкретном файле (инкрементальный анализ) обрубается/усложняется возможность заметить, как эти изменения влияют на другие части проекта. Но и проблемы как таковой нет. Достаточно время от времени выполнять полную проверку проекта, когда включен межмодульный анализ.
Более того ГОСТ Р 71207—2024 (Статический анализ программного обеспечения) явно предписывает выполнять оба вида анализа (см. п. 5.6.).
Суть – быстро ловим многие ошибки в момент их внесения в код. Время от времени выполняем полный (к сожалению, часто весьма медленный) анализ и выявляем баги при взаимодействии разных модулей. См. вебинар про процессы статического анализа по ГОСТ Р 71207–2024.
Чуть подробнее и с примером написал здесь.
Ну то есть новых проектов нет? У Linux Kernel всё было отлично и раньше.
Не удержался. А можно где-то посмотреть на хороший С++ вайб-код? Может кто-то подсказать открытые проекты?
Тем, кто хочет ещё глубже занырнуть в UB - Путеводитель C++ программиста по неопределённому поведению :)
В точку. Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом.
Раз история продолжается, я и здесь продублирую позицию по таким комментариям.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Это бессмысленная дискуссия, в которой я много раз участвовал, когда ещё никакого ИИ не было.
Пишешь какую-то из статей про ошибки в коде, найденные с помощью PVS-Studio. Кто-то приходит и начинает философствовать, что, возможно, эти баги можно найти, если использовать какие-то настройки каких-то компиляторов. И вот надо, чтобы автор статьи пошёл и сравнил, как и какие компиляторы эти ошибки находят.
Вот только это, скорее всего, непросто. Собрать проект с другими ключами и уж тем более другим компилятором — та ещё задачка. Вдобавок ещё автору поручается задача искать какие-то ключи в разных компиляторах. Вот делать мне больше нечего. Это только комментарий легко оставить и дальше пойти.
И, самое главное, это исследование не имеет практического смысла. Да, в мире есть разные подходы к поиску и устранению ошибок. Я показал конкретные, реально существующие ошибки, найденные методом статического анализа кода. Неважно, что есть теоретически. Практически — вот ошибки, а значит, полезно использовать PVS-Studio. В конце концов, если просто найти баги другими способами, так чего же они лежали в коде и ждали, пока я приду?
С ИИ схожая ситуация. Я должен идти и рефакторить чужой проект, чтобы в нём исчезли ошибки? Потом вновь исследовать, писать статью... Чтобы доказать что? Теоретическую возможность выправить код с помощью ИИ? Ну, наверное, можно напрячься. Но на практике-то мы всё равно имеем то, что имеем.
Я считаю, что вправе отказаться тратить десятки часов на бесполезные с практической точки зрения исследование и публикацию. И предлагаю сделать это тому, кто написал комментарий, если ему это интересно. Мне нет.
P.S. Я симметрично груб в ответе набросу, что будто я обязан тестировать рефакторинг чужого проекта разными способами.
Завышенные ожидания, а как на практике – оно как-то так.
Это не метод, а хрень. Это худший вариант кода, что подтверждается замерами. То, что выглядит как оптимизированным, вовсе не обязано таким являться. Вариант с
|это уже другой код.Нормальная позиция. У меня вклад 430 статей на Хабре, у вас 0. Набросать вопросов дело не хитрое...
Ну вот я вчера статью написал "Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом". Где я неправ? :)
Пожалуйста, проведите такой тест и напишите об этом.
Забыл в статье ещё вот на этот пост сослаться, который мне понравился и который транслирует схожие мысли:
Ну там не просто if-ы, а этапа компиляции (
if constexpr). Я к тому, что это работает не так, как вы возможно подумали :)Нет. Тесты это только часть подхода к качеству. Они не заменят построение архитектуры, контроль заимствованных компонент (SCA), проверку оптимальности выбранных алгоритмов и т.д. Не цепляйтесь за одну лучшую методологию. Тесты хорошо, но недостаточно.
Вы можете сами это легко сделать. Проект состоит из одного файла. Скормите его нейронке и попросите её подробно написать, что не так. Потом расскажите :) Я делал такое, глянул на выхлоп и закрыл. Мне такой фигнёй (сравнением) заниматься не интересно.
Продолжу. Ревью вайб-кода с гнильцой, который притворяется оптимизированным С++ кодом.