The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
В любом программном проекте целью является создание чего-то стабильного. Мы не хотим, чтобы оно сломалось перед пользователем. Мы также не хотим, чтобы наш веб-сайт вместо веб-страницы показывал “внутреннюю ошибку приложения”. Мы хотим, чтобы наше программное обеспечение работало, а не выходило из строя. Это вполне допустимое и логичное желание, но чтобы добиться этого, мы должны сделать наше программное обеспечение как можно более хрупким. Это может показаться противоречивым, но такова реальность. Чем хрупче ваше приложение в разработке, тем надежнее оно будет в эксплуатации.
Под хрупкостью я имею в виду философию Fail Fast, которая является противоположностью Fail Safe. Я думаю, вы знаете разницу, но позвольте мне все равно напомнить вам на примере. Вот что означает Fail Safe:
Этот метод предназначен для расчета и возврата размера файла. Сначала он проверяет, существует ли файл. Если файл не существует, метод возвращает ноль. В действительности, файла нет, поэтому размера нет. Мы могли бы пожаловаться на отсутствие файла, но зачем? Зачем шуметь? Давайте сохранять тишину и возвращать ноль. Мы не сбоим, потому что стараемся поддерживать работу приложения. Это называется Fail Safe (надежный сбой).
В отличие от этого, Fail Fast (быстрый сбой) выглядит так:
Мы не можем найти файл? Мы не скрываем этот факт. Мы публично и явно делаем это известным. Мы кричим и плачем. Мы вызываем исключение. Мы хотим, чтобы приложение вылетело, сломалось и потерпело неудачу, потому что кто-то дал нам файл, который не существует. Мы жалуемся и протестуем. Это называется “Fail Fast”.
Какая философия, если мы придерживаемся ее повсюду, сделает наше программное обеспечение надежным и устойчивым к сбоям? Только вторая - “Fail Fast”.
Почему? Потому что чем быстрее и проще сбой произошел, тем быстрее его можно исправить. И исправление будет проще и более заметным. “Fail Fast” - гораздо лучший подход для поддержки. Код становится более чистым. Гораздо легче отследить сбой. Все методы готовы сломаться и вызвать исключение даже при малейшей проблеме.
В этом примере, если метод возвращает ноль, не ясно, существует ли файл и его размер действительно равен нулю, или его имя неправильное и он просто не найден. Подход “Fail Safe” скрывает проблемы и делает код менее поддерживаемым, и поэтому его сложно стабилизировать.
В начале, во время производства, у нас будет много сбоев и ошибок. Но все они будут видимы и понятны. Мы исправим их и покроем unit-тестами. Каждое исправление сделает наше программное обеспечение более стабильным и лучше покрытым тестами.
Программное обеспечение, разработанное с учетом подхода “Fail Safe”, будет выглядеть более стабильным в начале, но оно быстро разрушится и станет не поддерживаемым беспорядком.
Программное обеспечение, разработанное с учетом подхода “Fail Fast”, будет часто вылетать в начале, но с каждым исправлением оно будет становиться более стабильным и надежным.
Вот почему хрупкость является ключевым фактором успеха надежности.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:57
