Надёжное программирование: от кода к технологии / Комментарии / Хабр

Не берусь судить о правильности всего написанного в статье. Скажу только об одном, под чем подписываюсь полностью:

ожидаемый результат не может быть определён с нужной точностью и полнотой

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

Увы - в реальной жизни так бывает не всегда. Например, формула для вычисления какого-то важного параметра может быть неизвестна заранее. Неизвестна никому вообще. Есть только некое исходное предположение, но оно разбивается о факты, как только результаты работы программы начинают с оными фактами сопоставлять (до этого их было не с чем сравнивать - не было возможности "это" посчитать). А какой "должна быть" "правильная" формула... икс-зет.

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

А когда вы добавляете в функцию пару новых входных аргументов, о которых раньше никто не думал, - все предыдущие тесты накрываются медным тазом, все зависимости "плывут", а "надежность" перестает быть чем-то хорошо измеримым - ибо она таки эмержентна...

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

А если это не единичный случай, в общий? Если "правильный результат" меняется в процессе разработки программы и проясняется именно в результате ее использования? Как тогда мерить надежность?

Конечно, это не всех программ касается. Вот только кажется мне, что как раз разработчики таких программ меньше других подвержены риску потери работы в результате совершенствования ИИ - ибо формулировку "ожидаемого результата" принципиально невозможно написать заранее.

Возможно, я не прав, - тогда в чем именно?

Комментарии 8

apevzner 13 часов назад

Ничего не понятно, но очень интересно

ToxaBes 12 часов назад

Мне кажется, что не было смысла разделять на 3 поста то что помещается в одну статью.

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

Большинство вайбкодеров просто не поймут предыдущий абзац. Слишком мало времени прошло, всего пара лет, опыт еще не нарос. Думаю, поэтому вас и заминусили, слишком рано еще, "непонятна".