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

Проект APRO как раз можно рассмотреть с этой точки зрения.

**Ловушка сложности**

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

Если при возникновении новой проблемы приходится полагаться только на добавление правил, система становится всё более громоздкой, а стоимость поддержки — резко возрастает, и всё может закончиться провалом. Архитектура APRO, кажется, учитывает этот момент, но в практике всё ещё остаётся вопрос, сможет ли она действительно контролировать взрыв сложности — это ещё предстоит проверить.

**Испытание на согласованность**

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

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

**Повседневное управление исключениями**

И ещё один момент, который легко упустить из виду: системные проекты — это не "редко случающиеся ошибки", а ежедневное возникновение исключительных ситуаций. Как элегантно обрабатывать эти ежедневные исключения, не позволяя при этом логике системы разрушиться — вот что действительно показывает зрелость проекта.