Часто чую, що деякі системні проєкти на ранніх етапах хвалять неймовірно, але з часом вони починають давати збої. У цьому явищі є одна фундаментальна причина: ми зазвичай дивимося лише на те, чи може система запуститися на початку, і ігноруємо більш важливе — чи зможе система стабільно підтримуватися далі.

Проєкт APRO саме з цієї точки зору можна переглянути заново.

**Пастка складності**

Будь-яка реальна система, що використовується у великому масштабі, неминуче стикається з однією проблемою: постійне додавання вимог, виправлення багів, безліч крайніх випадків. Ці зміни самі по собі не є поганими, погано — чи зможе система витримати цю суму змін.

Якщо кожного разу при появі нової проблеми доводиться лише додавати правила для її вирішення, система стане все більш громіздкою, і в кінцевому підсумку витрати на підтримку зростуть у рази. Це призведе до краху. Архітектура APRO, здається, враховує цей момент, але в реальній практиці ще потрібно побачити, чи справді вдасться контролювати вибух складності.

**Випробування послідовності**

У процесі оновлення системи старі правила, нові параметри та історична поведінка часто існують одночасно. Щоб система довго працювала добре, потрібно гарантувати логічну послідовність у всьому процесі еволюції, а не кожного разу копати нову яму під час оновлення.

Для таких проєктів, як APRO, що мають суворі структурні обмеження, ця проблема особливо гостра. Адже якщо правила часто порушуються, довіра користувачів різко падає, і це дуже важко виправити.

**Щоденне оброблення виключних ситуацій**

Ще один легко ігноруємоий момент: системні проєкти — це не випадки "іноді помиляємося", а щоденне виникнення виключних ситуацій. Як елегантно обробляти ці щоденні виключення і при цьому не руйнувати цілісну логіку системи — ось справжній тест зрілості проєкту.