Не знаю, как вы, а я про эту практику узнал далеко не сразу, поэтому хочу поделиться.

Что это такое?

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

Зачем?

Чтобы понять, зачем это нужно, можно рассмотреть классический пример Uber.

Представим, что мы заказываем такси; чтобы сделать заказ, нам, конечно же, нужно указать начальную и конечную точки.

Предположим, произошла ситуация, когда сервис, который отдаёт адреса, сломался. Мы могли бы не реализовывать никакой GD и надеяться на то, что таких ситуаций не будет или что мы сможем быстро их исправлять. Но если посмотреть с точки зрения бизнеса, то поймём, что каждый такой инцидент — это X потенциальной прибыли, которую мы упустили.

Что сделал Uber?

Они начали сохранять адреса «дом», «работа» и «учёба» отдельно, и даже если вдруг сервис, который отдаёт адреса, сломается, вы всегда сможете заказать такси: дом — работа, работа — дом.

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

Итог: даже в случае инцидентов большая часть пользователей Uber может удовлетворить свои потребности.

Что мне делать с этой информацией?

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

Всем чистого кода и бэклога без багов! 🪲🚵‍♀️🩼