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

S>Когда мы запустили тесты, то есть четыре возможности:
S>1. Тесты показали фейл, ошибка — в тестах
S>2. Тесты показали фейл, ошибка — в коде
S>3. Тесты прошли успешно, в коде есть неотловленные ошибки.
S>4. Тесты прошли успешно, в коде ошибок нет
S>Отличить ситуацию 3 от 4 невозможно даже теоретически.
S>Верификатор даёт три возможных результата:
S>1. Код точно нарушает спецификацию (и у нас есть контрпример)
S>2. Код точно соответствует спецификации (и мы это доказали)
S>3. Не удалось провести верификацию.
S>Вот этот пункт 3 внешне похож на пункт 3 из списка выше, но благодаря существованию пункта 2, можно считать такой вариант фейлом и требовать продолжить разметку кода до тех пор, пока верификатор не получит тот или иной результат.
S>Но это далеко не всегда проще, чем писать тесты. Проектов с хорошим тестовым покрытием — в избытке. Ткни в любой гитхаб, и там всё красивенько.
S>А вот проектов, покрытых верификацией, единицы.

Все это можно сказать короче.
Статический анализ может сказать о наличии ошибок в коде, которые в настоящий момент тестами не определяются. Тесты для этих ошибок сделать можно, но это может быть затруднительно без предварительного статического анализа — мы можем просто не догадаться их сделать. Ну и писать тесты сложнее и требует больше затрат, чем натравить статический анализатор (хоть ИИ, хоть не ИИ) и посмотреть результат.

Так что предмета спора я тут не вижу. Одно другому не мешает, они дополняют друг друга. Но тем не менее в принципе тесты могут обнаружить все ошибки, обнаруживаемые статическим анализатором.


PD>>Более того. Теоретически я могу представить себе некий ИИ — профайлер, который будет код профилировать, как это обычно и делается, но в котором будет ИИ — блок, который по ходу профилировки будет делать ИИ заключения, а потом (или опять же по ходу действия) выдаст, что он о работе этого кода думает. Вот это действительно мощный инструмент получится — сейчас мы чаще всего лишь видим лог профайлера, и даже если видим в рантайме, то выводы делать нам трудно, скорость работы нашего процессора нет та
S>Не очень понятно, что имеется в виду. Обычно мы видим не столько лог профайлера, сколько некую рассчитанную из неё статистику. Потому что сам по себе лог мало-мальски интересного приложения — это миллионы точек, их вручную читать бессмысленно. По одному отсчёту делать какие-то выводы тоже не имеет смысла.

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

S>Если вас интересуют инструменты, которые используют профилирование на ходу, то ИИ тут незачем — он слишком дорогой и медленный. Вот tiered JIT — это как раз оно. Когда из исполняемого прямо сейчас кода выбираются самые влияющие на производительность кусочки и переоптимизируются (с использованием собранных к этому моменту профилей).
S>У нас вот и спецкурс на эту тему в университете ежегодно читают

А в сети его нет или его материалов ? Я бы посмотрел, интересно. На спецкурс ваш я не запишусь

PD>>О господи! Ну неужели я не знаю про cvs и diff ? Я же вовсе не о том говорю, как эти изменения потом увидеть человеку. Это и так понятно. А вот как потом определить, с какими изменениями стоит согласиться, какие стоит отвергнуть, а какие, возможно, не принять, но внести изменения самому, при том, что эти изменения могут иметь достаточно сложную логику и затрагивать несколько файлов — вот это и вопрос.
S>Ну, так для этого человеку интеллект и дан.
S>Если человек на такое неспособен, то пусть делегирует сложную работу ИИ. Тот прекрасно может оценить, стоит ли делать определённые изменения, и нет ли в них нежелательных побочных эффектов.
S>Именно такой пример я привёл по ссылке.

Речь же идет о том, что ИИ эти изменения уже сделал. Теперь ревю человеком. А Вы что, предлагаете тут ИИ самого себя ревьюировать ,

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

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

PD>>А тут под чьей ответственностью ? Передать этот код целиком ИИ, пусть он за все и отвечает ? . Не получится. Отвечать все равно человеку.
S>Мне даже любопытно стало — о какой ответственности речь? На моей памяти за косяки в коде даже выговоров никому не объявляли.

Антон, Вы что-то самому себе противоречите. Вы же только что написали (см. чуть выше, выделили жирным)

А теперь вдруг Вам стало неясно, о какой ответственности может идти речь.

Разумеется, не юридический это вопрос. И не о наказании речь идет, хоть джуна, хоть сеньора. А о том, что этот сеньор, взявшись за разработку этого куска проекта, несет ответственность за ее выполнение и сроки. Неужели это надо объяснять ?

S>Потому, что в хорошо организованной работе стабильность кода держится не на личном подвиге отдельных разработчиков, а на общей инженерной культуре и процессах.
S>Если культуры и процессов нету — то код, скорее всего, будет говном и у живого человека. Ну, разве что ваша фамилия Накамура .
S>А если есть культура и процессы — то ни джун, ни сениор, ни ИИ не сможет нанести существенного вреда. Ни случайно, ни намеренно.

Одно другому не мешает. Разумеется, культура работы должна быть. И в случае ухода или болезни разработчика его кто-то должен заменить. Но пока он на месте, за этот код отвечает в основном именно он.

PD>>Да нет, поздно мне уже. Я лучше просто посмотрю, что у других получится.
S>Странно. Любопытство вроде есть, а желания его удовлетворить нету.

Поздно.

S>Вы ж все равно чужим рассказам не поверите.

Просто рассказам — не поверю, мало ли что говорят. Увижу своими глазами подробный лог — почему не поверю, вполне могу и поверить.

PD>>А я разве спрашивал, может ли он это делать ?
S>Мне не сложно повторно процитировать:
S>

S>...
S>3. Дать свои рекомендации по внесению изменений в него, не делая эти изменения. Какие-то новые идеи высказать, например, или хотя бы улучшения предложить.
S>4. Разработать свой код в качестве contibutor и предложить pull request
S>5. Принять этот pull request (или отвергнуть его)
S>...
S>Может ли он (3) — (5) ? Если сейчас не может — сможет ли ?

Спасибо за цитату, но в нижних строках нашей дискуссии мы давно уже обсуждали не это, а вопрос, стоит ли поручать ИИ вносить изменения в код, написанный человеком. Я не спрашивал, может ли ИИ делать такие изменения, и странно было бы спрашивать, если я разговор об этом начал с того, что упомянул изменения, которые делает IDEA и сказал, что я их не очень люблю.