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

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

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

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

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

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

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

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

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