Про разработку сложного софта

[plakhov]

Распространено мнение, согласно которому с увеличением программной системы число ошибок в ней обязано расти сверхлинейно (в зависимости от пессимизма носителя встречаются различные конкретизации, от "квадратично" до "экспоненциально"), и этот эффект неотвратим, как закон природы. Это мнение неверно.

Частично оно вызвано тем, что стандартный способ обеспечения отказоустойчивости, воспетый Кларком в "Свидании с Рамой", в софте плохо применим: три копии имеют большую отказоустойчивость, чем одна, только если речь идет об отказах оборудования, и то с оговорками.

Несколько раз я уже писал о том, как обходится этот "закон природы" в частных случаях (1, 2, 3, 4, 5), попробую обобщить.

Кроме abstraction leaks бывают и, назовем их так, abstraction sinks - методы, подсистемы, и алгоритмы, которые умеют "переваривать" ошибки и протечки соседей. К abstraction sink'у всегда можно подключить очередной "черный ящик", реализующий некоторый заранее обговоренный интерфейс. Работа системы в целом будет улучшаться, если этот "черный ящик" работает разумно, и не ухудшаться, если он ошибается (в том числе, если "заранее обговоренный" интерфейс оказывается протекающей абстракцией). После этого конкретные "чёрные ящики" могут писать эскимосские аутсорсеры, умные студенты, эволюционные процедуры, whatever, они могут быть сколь угодно "глючными" - лишь бы хоть иногда преодолевали порог полезности.

Здесь следует считать, что каждый черный ящик работает в собственной песочнице, т.е. не может, например, испортить память, или выбросить "неловимое" исключение. Если он примет управление и "упадет", начнет жутко тормозить, или зависнет, то можно продолжить работу так, как будто его никогда и не было. Как именно этого добиться в боевых условиях - вопрос интересный, но, надеюсь, понятно, что решаемый (если осознанно ставить себе такую задачу). Для простоты можно принять не очень реалистичное допущение, что каждый "черный ящик" запущен на собственном железе, и общается с abstraction sink'ом по сети.

Известно по крайней мере два типа abstraction sink'ов: машинное обучение ("черными ящиками" в этом случае являются отдельные features), и алгоритмы поиска и планирования ("черные ящики" - эвристики выбора "макроходов"). Ни тот, ни другой - не панацея, но их применение позволяет очень долго наращивать сложность системы уже после того, как она перестает помещаться у человека в голове, и оставлять её при этом работающей. Намного дольше, чем в привычных иерархическом или объектно-ориентированном подходах, где недопущение abstraction leak'ов критически важно.

Кое-какие современные задачи иначе и не решаются. Те, которые решаются именно так, по не до конца мне понятному совпадению чаще всего относятся к "искусственному интеллекту".

Для старых друзей: в геймдеве всё это практически не применимо. :)

Comments

[nudnik.ru (from livejournal.com)]

Пост травли старых друзей, ок.

[(Anonymous)]

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

[sleepy-drago.livejournal.com]

не смешно даже. В каждой программной системе есть подсистемы генерирующие базовые данные. Они не дублируются. И никакой машинный sink не вытащит корректные данные если их (уже) нет.

Кстати в играх эти sink'и сплошь и рядом еще лучше чем, так как кому какая разница если вместо 65537 партиклов нарисуется 65536 или часть предмета затекстурируется другой текстурой ? Люди даже терпят в мультиплейере когда клиент показывает что они выиграли а с сервера приходит проиграли и клиент как ни в чем небывало поверх рисует проиграли :)) и ничего. Но количество багов от этого почему-то не уменьшается.

А когда данные ходят кругами и результат влияет на будущий вход ...

В общем не смотря на личности и авторитеты ктото тут сильно не прав.

[clayrat.livejournal.com]

это ж эрланг
там принцип let it fail

[pg.livejournal.com]

Это такой тонкий развод? IMHO понятно, что есть системы, позволяющие подобную декомпозицию, а есть - не позволяющие.

Кстати, если ты про наш поиск - то не забывай Лешу, который, фактически, и есть такой "abstraction sink", все остальное без его приемки рассыпалось бы. А это не машина, а живой человек.

[ushastyi.livejournal.com]

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

С другой стороны, возможны архитектуры, в которых похожий подход возможен. Но разработка таких архитектур -- отдельная сложная задача. Возможно, для поиска это и применимо, так как данные нестрогие по своей природе. Кстати да, в случае нестрогих требований к корректности результата такой подход представляется более реалистичным.

[elephantum.livejournal.com]

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

То есть я бы поспорил, о наблюдаемости эффектов "закона природы" на системах такого типа.

Есть другие системы, богатые бизнес-логикой, например тот же Биллинг, это структурно сложная система, в ней не работают подходы "сконвертируем все входные сигналы к единообразному виду и обработаем одинаково".

Пока писал понял: можно выделить три вида сложности системы:
- структурная (алгоритмическая) сложность программной системы
- сложность данных
- кумулятивная, поведенческая сложность

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

[rdia.livejournal.com]

Прошу прощения, правильно ли я понимаю, что в эти "abstraction sink" входит и ОС UNIX с классическим взаимодействием скрип-программа? Где подпрограммы типа grep, cat, tar и т.д. могут память вообще не высвобождать.

Или нет?

[dev-zzo.livejournal.com]

надо сказать, что это неприменимо не только в геймдеве. в написании firmware для разных девайсов, например (чем, собственно, я сейчас и занимаюсь).
тем не менее, прочитать было интересно!

[vlad-volkov.livejournal.com]

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

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

[alex ulyanov (from livejournal.com)]

А точки зрения синергетики нельзя это объяснить?

[g00dmann.livejournal.com]

Я не знаю, как правильно называется такой класс задач, но основной их признак - автоматом проверить, с каким качеством задача решена, проще, чем решить.

Класс задач достаточно узкий, но теоретически методика отличная, все красивенько и нарядненько. Элегантно получаем вроде бы приличное решение для не самой простой задачи, после чего спокойно его тюнингуем. Ага, как бы не так. В реале все получается не так прикольно, т.к. алгоритм для "автоматом проверить" как правило выбирается совсем не тот. Т.е., если не копать вглубь, то все вроде зашибись, а вот если копнуть... То жопа. :)

К тому же, в угоду качеству "автоматом проверить" логика черных ящиков иногда полностью отрывается от реальности.

Но если этого не замечать и тащиться от методики проверки качества, то да, все здорово. :)

[dtjurev.livejournal.com]

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

[http://users.livejournal.com/_winnie/]

abstraction syncs и leaks бывают на микроуровне и архитектуре в малом.

Приняли решение заливать неинициализированную память нулями в аллокаторе - получили хороший sink и помощь в отладке.

Решили синхронизировать на разных компьютерах операции с double - получили очень хрупкий объект. Пересылаем fixed point по сетке - получили маскировку неважных ошибок.

Запретили не-explicit конструкторы (совсем уж микро) - получили чуть-чуть sink.

Пишем на Haskell вместо assembler (крайности, для иллюстративности) - избежали массы ненужных ошибок.

Дядя Дима выкидывает сложную физику из "заваленный камнями лифт" и меняет на скриптовую катсцену.

WinWord/VisualStudio делает автосейвы каждую минуту - уже можно жить с каким-то багом который обрушивает Visual Studio раз в два дня.

Сервер ММО толерантен к ошибкам в скриптовых функциях на питоне, разумно расставлены try/catch - и сервер выглядит адекватным для 90% игроков, у разрабов есть пара дней для спокойной починки. Вообще сервер ММО целиком про abstracion sinks, все легкие способы работать на одном крыле, и пришивать крылья на лету - стараются использовать.