Здравствуйте, Sinclair, Вы писали:
PD>>Все это можно сказать короче.
PD>>Статический анализ может сказать о наличии ошибок в коде, которые в настоящий момент тестами не определяются. Тесты для этих ошибок сделать можно, но это может быть затруднительно без предварительного статического анализа — мы можем просто не догадаться их сделать. Ну и писать тесты сложнее и требует больше затрат, чем натравить статический анализатор (хоть ИИ, хоть не ИИ) и посмотреть результат.
S>Нет. Тесты принципиально ничего не могут нам сказать о поведении кода за пределами списка тестовых случаев. А для любых мало-мальски интересных задач количество возможных вариантов входных данных запредельно велико.
Разумеется, но не об этом же речь, а о том, что в принципе может быть сделан тест, который вот этот вид ошибки обнаруживает. Иными словами, она должна проявиться в рантайме хоть когда-нибудь. Если она в рантайме не проявляется никогда — ошибка ли она ? Я уже это говорил, а Вы почему-то назвали это демагогией.
S>Стат.анализ может, в отличие от тестов, сказать "ошибок ТОЧНО НЕТ". Не "я не нашёл", а "их нет".
Ну это мне как-то сомнительно. Даже банальное s = h*w может вызвать ошибку при переполнении. Как можно сказать что тут нет ошибки ?
PD>>Так что предмета спора я тут не вижу. Одно другому не мешает, они дополняют друг друга. Но тем не менее в принципе тесты могут обнаружить все ошибки, обнаруживаемые статическим анализатором.
S>Тут не спор, а скорее обсуждение точки зрения. Нас, вообще говоря, не интересует "поиск ошибок". Поэтому бессмысленно обсуждать, способна ли одна технология найти те ошибки, которые находит другая.
S>Нас интересует доказательство отсутствия ошибок.
Ну вот и докажите, что s = h*w содержит или не содержит ошибку. В статике, конечно, без выполнения.
PD>>Имеется в виду, что не статистику (которая выдается по окончании профайлинга) он будет анализировать, а прямо по ходу профайлинга смотреть, что происходит и делать выводы.
S>Нереалистично. Профилирование это адски затормозит, а особой ценности в инфе, полученной "по ходу", а не интегрально за полчаса, нету.
Возможно. Но звучит заманчиво. Хотя возможно, и нереализуемо.
PD>>А в сети его нет или его материалов ? Я бы посмотрел, интересно.
S>Нету. Это сбертех читает, у них материалы закрытые.
PD>>Джуна — да. Но джуну обычно поручают сравнительно локальные изменения, с более или менее конкретно поставленной задачей.
S>Ну так и перед ИИ никто вас не заставляет ставить задачи эпических масштабов. Можно, конечно, использовать промпт вроде "вот тебе доступ к репозиторию, измени код так, чтобы у нас продажи выросли в два раза без роста затрат на саппорт". А потом бегать и всем рассказывать, что все ИИ — тупые и делают чё попало.
S>А можно поручить сравнительно локальные изменения, с более или менее конкретно поставленной задачей.
А вот человеку можно и первое поручить. Не джуну, конечно, а хорошему специалисту, а то и команде их с участием специалистов разного профиля. Именно так задачу и поставить. "Измените код так, чтобы у нас продажи выросли в два раза без роста затрат на саппорт". На вопрос — а что именно сделать, дать ответ — думайте сами. Все.
Собственно, все исследовательские проекты так и выглядят. Надо бы сделать, чтобы получилось вот такое, а как это добиться — бог знает. Думайте сами.
Я в таком проекте работал 3 года в начале 2000-х. Потоковая обработка фотографий, на каждое фото дается фиксированное время, не уложитесь — обработка этого фото снимается и выписывается penalty. При обработке фото делаются запросы к БД, не SQL, специальной БД, сделанной под эту задачу от какой-то фирмы. У нас все есть, и все работает, но время запросов слишком большое, а поэтому слишком много penalty. Сделайте, чтобы работало быстрее. Это вся постановка задачи. На мое предложение провести реверс-инжиниринг этой БД и посмотреть, что там делается, был получен категорический запрет — нарушает лицензионное соглашение.
Вот и все. Делайте, что хотите, для этого мы Вас сюда и взяли.
