Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Как сказать... Вообще-то хороший набор тестов даст и то (в принципе даже все даст), что и статический анализ. Аргумент тут простой — статический анализ , не запуская код, обнаруживает ошибки, значит, может быть и тест, который эту же ошибку обнаружит. Если такой тест сделать вообще нельзя, то это ошибка ли ?
PD>Так что речь идет не о смешении терминов, а просто о том, что если статический анализ находит ошибку, то можно сделать тест, который эту ошибку ловит при его прохождении.
Это как раз понятно. Я просто плохо объясняю: статический анализ не обязательно находит ошибку. Но его принципиальное отличие от тестирования — в получаемых результатах.
Когда мы запустили тесты, то есть четыре возможности:
1. Тесты показали фейл, ошибка — в тестах
2. Тесты показали фейл, ошибка — в коде
3. Тесты прошли успешно, в коде есть неотловленные ошибки.
4. Тесты прошли успешно, в коде ошибок нет
Отличить ситуацию 3 от 4 невозможно даже теоретически.
Верификатор даёт три возможных результата:
1. Код точно нарушает спецификацию (и у нас есть контрпример)
2. Код точно соответствует спецификации (и мы это доказали)
3. Не удалось провести верификацию.
Вот этот пункт 3 внешне похож на пункт 3 из списка выше, но благодаря существованию пункта 2, можно считать такой вариант фейлом и требовать продолжить разметку кода до тех пор, пока верификатор не получит тот или иной результат.
Но это далеко не всегда проще, чем писать тесты. Проектов с хорошим тестовым покрытием — в избытке. Ткни в любой гитхаб, и там всё красивенько.
А вот проектов, покрытых верификацией, единицы.
PD>Если с этим не согласны , из этого следует, что статический анализ может обнаружить ошибки, которые никогда в рантайме не проявляются (тест сделать нельзя). Несколько странное утверждение получится.
Это демагогия. Это примерно как рассуждать о спортлото как источнике заработка. Ведь выигрышные последовательности номеров существуют — кто мешает просто писать их на билетиках?
Так и тут — почему бы вам просто не писать тесты сразу с контрпримерами к коду.
Вопрос не в том, можно ли проверить выигрышность билета. А в том, чтобы найти способ подобрать за разумные деньги выигрышный набор номеров.
PD>Именно так. Но если просто "после" и не указывая, что этот запуск не имеет отношения к работе ИИ и ИИ его никак не учитывает — я имел право понимать, что и это им используется. Стоит формулировать точнее. А еще стоило бы просто сразу сказать — ИИ срабатывает после выполнения тестов, но их выполнение никакого отношения к его работе не имеет. Я же об этом ясно спрашивал — да или нет ? Был бы дан сразу ответ "не имеет" — не было бы и этой ветки.
Ну так он и был сразу дан. Цитирую:
Нет, я говорю о том, что обычные, не ИИ инструменты в проекте уже есть. И они все ничего не нашли. А вот ИИ посмотрел — и увидел, что логика нарушена.
PD>Совершенно верно, только не может (в том виде, как Вы его действия описали), а сможет (когда-нибудь). Вот если он действительно будет запускать тесты с профилировкой (может, с существующим профайлером, может, со специально для него написанным), то он сможет анализировать все результаты профайлинга и делать выводы.
Всё это он уже умеет. Агент может делать примерно всё, что делаете вы.
В том числе — запускать тесты с инструментированием и смотреть на результаты code coverage.
В том числе — запускать тесты с инструментированием и смотреть на результаты профилирования.
Примерно любой современный тулчейн управляется из командной строки и выдаёт результаты в виде того или иного текста. LLM отлично справляются с порождением команд и разбором результатов. DIXI.
PD>Более того. Теоретически я могу представить себе некий ИИ — профайлер, который будет код профилировать, как это обычно и делается, но в котором будет ИИ — блок, который по ходу профилировки будет делать ИИ заключения, а потом (или опять же по ходу действия) выдаст, что он о работе этого кода думает. Вот это действительно мощный инструмент получится — сейчас мы чаще всего лишь видим лог профайлера, и даже если видим в рантайме, то выводы делать нам трудно, скорость работы нашего процессора нет та 
Не очень понятно, что имеется в виду. Обычно мы видим не столько лог профайлера, сколько некую рассчитанную из неё статистику. Потому что сам по себе лог мало-мальски интересного приложения — это миллионы точек, их вручную читать бессмысленно. По одному отсчёту делать какие-то выводы тоже не имеет смысла.
Ну так вот ИИ, конечно же, умеет читать выхлоп этих инструментов и делать из них выводы. Не "по ходу профилировки", естественно, а по его итогам.
Если вас интересуют инструменты, которые используют профилирование на ходу, то ИИ тут незачем — он слишком дорогой и медленный. Вот tiered JIT — это как раз оно. Когда из исполняемого прямо сейчас кода выбираются самые влияющие на производительность кусочки и переоптимизируются (с использованием собранных к этому моменту профилей).
У нас вот и спецкурс на эту тему в университете ежегодно читают
PD>О господи! Ну неужели я не знаю про cvs и diff ? Я же вовсе не о том говорю, как эти изменения потом увидеть человеку. Это и так понятно. А вот как потом определить, с какими изменениями стоит согласиться, какие стоит отвергнуть, а какие, возможно, не принять, но внести изменения самому, при том, что эти изменения могут иметь достаточно сложную логику и затрагивать несколько файлов — вот это и вопрос.
Ну, так для этого человеку интеллект и дан.
Если человек на такое неспособен, то пусть делегирует сложную работу ИИ. Тот прекрасно может оценить, стоит ли делать определённые изменения, и нет ли в них нежелательных побочных эффектов.
Именно такой пример я привёл по ссылке.
PD>Совершенно верно. Это и к людям так же относится. Но с одним существенным отличием. Если, скажем, я написал код, а потом кто-то его серьезно правит, то теперь именно он скорее ответственен за этот код. Он мой код понял и серьезно изменил, он и отвечает. Я могу вообще устраниться, да может, меня в этом проекте уже и нет, так что мне поздно претензии предъявлять. Это теперь код под его ответственностью, а он, положим, имеет квалификацию не ниже моей.
Боюсь, если вы возьмёте джуна на работу и не станете проверять его код, то потом свалить ответственность на него под тем предлогом, что он что-то там много всего изменил, не выйдет. Ну, то есть джуна-то может быть и накажут (а может быть и нет — если окажется, что он не нарушал никаких инструкций), а вот его куратору (то есть вам) выпишут по первое число.
PD>А тут под чьей ответственностью ? Передать этот код целиком ИИ, пусть он за все и отвечает ? . Не получится. Отвечать все равно человеку.
Мне даже любопытно стало — о какой ответственности речь? На моей памяти за косяки в коде даже выговоров никому не объявляли.
Потому, что в хорошо организованной работе стабильность кода держится не на личном подвиге отдельных разработчиков, а на общей инженерной культуре и процессах.
Если культуры и процессов нету — то код, скорее всего, будет говном и у живого человека. Ну, разве что ваша фамилия Накамура
.
А если есть культура и процессы — то ни джун, ни сениор, ни ИИ не сможет нанести существенного вреда. Ни случайно, ни намеренно.
PD>Да нет, поздно мне уже. Я лучше просто посмотрю, что у других получится.
Странно. Любопытство вроде есть, а желания его удовлетворить нету.
Вы ж все равно чужим рассказам не поверите.
PD>А я разве спрашивал, может ли он это делать ?
Мне не сложно повторно процитировать:
...
3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
4. Разработать свой код в качестве contibutor и предложить pull request
5. Принять этот pull request (или отвергнуть его)
...
Может ли он (3) — (5) ? Если сейчас не может — сможет ли ?
