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

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

Или не удалять постфактум (то есть после моих замечаний) свою строку. Я-то первый раз цитировал, когда она там еще была


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

Вполне. Ради бога, я же не против. Я вполне за. Было N инструментов, добавился N+1-й. Очень хорошо. Только панацею из него делать не надо.

PD>>Но любой статический анализ никогда не может дать ту информацию, которую дает анализ в рантайме. То есть анализ, проведенный профайлером или Code Coverage.
S>Это работает в обе стороны.

Как сказать... Вообще-то хороший набор тестов даст и то (в принципе даже все даст), что и статический анализ. Аргумент тут простой — статический анализ , не запуская код, обнаруживает ошибки, значит, может быть и тест, который эту же ошибку обнаружит. Если такой тест сделать вообще нельзя, то это ошибка ли ?
Другое дело, что статический анализ прост и для него есть инструменты. Натравил их — получи. А тесты делать надо, да и есть риск того, что именно под эту ошибку тест и не будет сделан.

Так что да, они дополняют друг друга.

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

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

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

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

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

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

Пусть входит, бога ради.


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

Ну не совсем поверх, скорее параллельно. Поверх профайлера он все же не работает, как мы выяснили уже.

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

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

В том-то и дело, что черт его знает. Не принять точечное изменение, которое сделала IDEA — несложно. И то, если пустить ее на автомате делать эти изменения, потом придется просматривать все изменения. А вот если это сделает ИИ, да еще на per-project основе, внося изменения по данной проблеме в несколько файлов кода — поди потом найди изменения, относящиеся именно к этой проблеме и отличи их от других. А если он еще несколькими взаимосвязанными проблемами одновременно займется, то тут, боюсь, кроме полного отказа от его изменений ничего и не может быть.

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

Звучит хорошо. Насколько реально все это можно, и не будет ли ситуации вроде ответа от вполне человеческих служб (ну вроде чата поддержки какого-то банка, где уже удалось пробиться через бота к реальному человеку, но этот человек все шлет и шлет свои стандартные ответы вместо того, чтобы ответить по существу — и делает это потому, что среди стандартных ответов у него ответа на мой вопрос нет, а за их пределы он выйти не имеет права) — не знаю. Но хотелось бы посмотреть на реальный лог таких общений по какому-то, пусть не слишком сложному проекту. Чтобы понять, что из этого фактически сейчас имеет место быть

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

Про тесты понятно. И покрыто было. И после его изменений половина тестов упала. А вот про любые идеи про починку понятно меньше. Я же написал — начиная проект, я на отладку этого кода и часа не запланировал, да и не помню уже его деталей. Так что на починку может уйти очень много времени.
Поэтому будет лучше, если он сам вносить изменения не будет, а предложит их мне для обсуждения. Может, я вообще эти изменения отвергну. Ну нашел он ошибку, которая нефатальна и может проявиться раз в 100 лет. Ну и черт с ней. Или не черт с ней, а скажи просто, в чем она заключается. Я после этого пойму, насколько она серьезна. Может, и исправлю, если за 10 минут смогу, а может, не стану — пусть через 100 лет кто-то ее поправит

В общем, я против автоматического редактирования кода.