Fail Fast

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

Хрупкой, я имею в виду философию Fail Fast, которая является противоположностью Fail Safe.  

Я считаю, что вы знаете разницу, но позвольте мне напомнить вам в любом случае, например. Это безопасный режим:

public int size(File file) {
  if (!file.exists()) {
    return 0;
  }
  return file.length();
}

Этот метод должен вычислять и возвращать размер файла. Сначала проверяется, существует ли файл. Если он не существует, метод возвращает ноль. Действительно, файл отсутствует, поэтому размер не указан. Мы могли бы пожаловаться, что файл отсутствует, но для чего? Зачем шуметь? Давайте сохраним его и возвращаем ноль. Мы не терпим неудачу, потому что мы пытаемся заставить приложение работать. Это называется Fail Safe.Напротив, именно так выглядит Fail Fast:

public int size(File file) {
  if (!file.exists()) {
    throw new IllegalArgumentException(
      "There is no such file; I can't get its length."
    );
  }
  return file.length();
}

Мы не можем найти файл? Мы не скрываем этого факта. Мы делаем эту ситуацию общедоступной и видимой. Мы кричим и плачем. Мы создаем исключение. Мы хотим, чтобы приложение разбилось, сломалось и потерпело неудачу, потому что кто-то дал нам файл, которого не существует. Мы жалуемся и протестуем. Это называется Fail Fast.

Подход Fail Safe скрывает проблемы и делает код менее ремонтопригодным, и поэтому трудно стабилизировать 

Какая философия, если следовать ей повсюду, способна сделать наше программное обеспечение надежным и отказоустойчивым? Только - Fail Fast. Поскольку чем быстрее и легче произойдет сбой, тем быстрее он будет исправлен. И исправление будет проще и более заметным. 

Fail Fast - гораздо лучший подход к ремонтопригодности. Код становится чище. Отслеживать отказ гораздо проще. Все методы готовы разбить и выбросить исключение даже в мельчайших проблемах. 

В этом примере, если метод возвращает ноль, неясно, существует ли файл и его размер на самом деле равен нулю или его имя неверно и оно просто не найдено. Подход Fail Safe скрывает проблемы и делает код менее ремонтопригодным, и поэтому его трудно стабилизировать.

В начале, во время производства, у нас будет много сбоев и ошибок. Но все они будут видны и понятны. Мы исправим их и покроем их с помощью юнит-тестов. Каждое исправление сделает наше программное обеспечение более стабильным и лучше охвачено испытаниями. 

Программное обеспечение, разработанное с учетом подхода Fail Safe, с самого начала будет выглядеть более стабильным, но оно быстро деградирует и неизбежно превращается в бесполезный беспорядок.

Программное обеспечение, разработанное с учетом подхода Fail Fast, будет часто вылетать в начале, но улучшит его стабильность при каждом исправлении и в конечном итоге станет очень стабильным и надежным. Вот почему хрупкость является ключевым фактором успеха для надежности.