Fail fast что это
Fail-fast design при автоматизации сборок с помощью Nuke
Что такое fail-fast design?
Что уже есть в Nuke?
Можно ли расширить fail-fast инструменты?
Вступление
Кто не знаком с Nuke вы всегда можете ознакомиться или на официальном сайте или посмотреть вот эту презентацию.
Далее в статье мы поговорим о существующем в Nuke fail-fast подходе и о том, как его можно развивать.
Что такое fail-fast design?
На официальном сайте указано, что Nuke следует fail-fast философии. Раз уж это является основной темой статьи, то логично было бы разобраться что это такое.
Википедия на этот счёт говорит следующее:
Длинная и скучная цитата из Википедии
In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system’s state at several points in an operation, so any failures can be detected early. The responsibility of a fail-fast module is detecting errors, then letting the next-highest level of the system handle them.
В моем примитивном понимании это то, что мы, как программисты, делаем каждый день. А именно вызываем исключение максимально близко к месту появления проблемы, то есть как только поняли что что-то идёт не по плану.
В контексте систем автоматизации сборок получается посмотреть на fail-fast design немного под другим углом. Всё дело в том, что любая система автоматизации сборок это по сути набор шагов, каждый шаг изолированно выполняет свою часть работы и имеется некая взаимосвязь между ними. Допустим у нас есть Nuke проект для деплоя некого абстрактного веб-приложения, тогда его план будет выглядеть примерно так:
Пример очередности выполнения шагов
Что будет если что-то пойдёт не так на шаге Deploy? Логично что деплой упадёт и наш код не будет доставлен на нужное окружение. Но кроме этого стоит учесть что уже были выполнены шаги Build, Migration, StopIisPool. А значит кроме этого у нас ещё и выключен пул, а значит приложение не работает, хотя могло бы.
Читатель может справедливо заметить, что это проблемы пайплайна и это нужно было бы учесть и например, сделать включение пула обязательным действием вне зависимости от всего остального, но fail-fast design подталкивает нас к мысли «Зачем запускать то, что всё равно упадёт?».
Лучше не работать с мыслью «Зачем запускать то, что всё равно упадёт?», потому что тогда можно вообще перестать писать код)
Что уже есть в Nuke?
Из коробки в Nuke доступна проверка параметров перед запуском. На всякий случай напомню что Параметр в Nuke это переменная значение которой может передаваться через аргументы командной строки или как переменная окружения.
Реализовывается такая проверка следующим образом:
Расшифровка кода выше
Target в Nuke это делегат из-за этого и получается такая сомнительная конструкция в виде смайлика => _ =>
Результат выполнения Nuke если не был передан обязательный параметр
В целом из fail-fast в Nuke это всё, поэтому перейдём к моим размышлениям на эту тему.
Можно ли расширить fail-fast инструменты?
В моей команде мы используем собственную библиотеку на основе Nuke для автоматизации сборок, собственную потому что есть много нюансов и тонкостей которые необходимо часто переиспользовать. У нас довольно много проектов и различных сценариев в которых используется Nuke поэтому базовая библиотека именно то, что нужно.
В нашей библиотеке довольно много зависимостей поэтому мы используем dependency injection внутри Nuke на основе IServiceCollection. Поэтому мне хотелось бы проверять перед запуском не только параметры, но и классы-сервисы в которым делегируется определенная работа.
Такие сервисы, которые выполняют свою работу в рамках Nuke я разделил на 2 группы и получились следующие интерфейсы:
Использование в Nuke с помощью метода расширения выглядит таким образом:
В коде выше по сути есть 2 этапа:
Находим все зависимости для класса T
Для каждого класса выполняем метод CheckService()
На всякий случай замечу, что AlreadyCheckedTypes передаётся для того, чтобы не проверять много раз один и тот же сервис.
Метод который проверяет сервисы тоже достаточно прост:
Далее уже при создании каждого сервиса реализовываем логику проверки, если это конечно же необходимо. Например для сервиса, который работает с файловой системой проверка может выглядеть как-то так:
Заключение
Буду рад комментариями и предложениям/критике по поводу изложенного выше материала.
Fail Fast! принцип: Отлаживайте меньше и создавайте более надежное ПО
Предположим мы должны написать простую веб-страницу, которая отображает рядом с фонтаном предупреждение о том, что вода в нём загрязнена.
Следующий HTML-код выполняет эту задачу:
Результат работы этого кода в браузере будет выглядеть следующим образом:
На второй вопрос легко ответить. Достаточно выполнить ошибочный HTML-код в браузере. На момент написания статьи браузеры Firefox, Google Chrome, Internet Explorer, Opera и Safari покажут следующий результат:
Очевидно, что в браузерах используется подход Forgive!, так как наш сайт продолжил работу и не было никаких сообщений об ошибке. Единственное отличие в том, что теперь стало больше текста, выделенного жирным шрифтом. Но всё сообщение всё ещё отображается целиком и люди предупреждены. Незачем сильно беспокоиться!
Делаем вывод: подход Forgive! работает хорошо!
Давайте попробуем воспроизвести другую ошибку.Вместо тэга мы напишем незаконченный тэг перед словами DO NOT, следующим образом:
Ранее перечисленные браузеры покажут следующий результат:
Есть повод паниковать! Теперь наша программа делает абсолютно обратное тому, что мы хотим, чтобы она делала. Последствия ужасны. Наше приложение, призванное спасать жизни, мутирует в приложение-убийцу.
Делаем вывод: подход Forgive! работает плохо!
Как видно из приведённых примеров, последствия ошибки при использования Forgive! подхода очень отличаются и могут варьироваться от полностью безобидных до катастрофических. Итак, каким будет корректный ответ на вопрос «Что должно произойти?»
Однако, ситуация кардинально меняется, когда приложение выполняется у клиента после релиза. К сожалению, не существует правила-на-все-времена. Практика показывает, что обычно лучше и после релиза использовать подход Fail fast! по умолчанию. Конечный негативный результат выполнения приложения, которое игнорирует ошибки и просто продолжает выполняться непредсказуемо, обычно хуже, чем негативный результат от приложения, которое внезапно прекратило работу. Если приложение бухгалтерского учёта внезапно «упало», пользователь будет зол. Если приложение продолжило работу после возникновения ошибки и создало неверный результат, пользователь будет очень зол. «Зол» лучше чем «очень зол». В этой ситуации подход Fail fast! лучше.
Если функция возвращает код ошибки в случае возникновения трудностей, ты должен проверить код этой ошибки, даже если эта проверка троекратно увеличит размер кода твоего и вызовет боль в твоих пальцах, потому что если ты помыслишь «это не может случиться со мной», боги обязательно накажут тебя за высокомерие.
Контрактное программирование ещё один пример использования особенностей Fail fast!. Потому что неверные входные/выходные аргументы и атрибуты объектов немедленно определяются и вызывают ошибки в процессе выполнения.
Если Вы выбрали среду программирования (= язык программирования + библиотеки + фреймворки), которая придерживается этого важного правила, то Вы будете отлаживать меньше и создавать более надёжный код за меньшее время.
Environment. Fail Fast Метод
Определение
Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.
Завершает процесс сразу после записи сообщения в журнал событий приложений Windows, после чего включает сообщение и дополнительные сведения об исключении в отчет об ошибках, отправляемый в корпорацию Майкрософт.
Перегрузки
Завершает процесс сразу после записи сообщения в журнал событий приложений Windows, после чего включает сообщение в отчет об ошибках, отправляемый в корпорацию Майкрософт.
Завершает процесс сразу после записи сообщения в журнал событий приложений Windows, после чего включает сообщение и сведения об исключении в отчет об ошибках, отправляемый в корпорацию Майкрософт.
FailFast(String)
Завершает процесс сразу после записи сообщения в журнал событий приложений Windows, после чего включает сообщение в отчет об ошибках, отправляемый в корпорацию Майкрософт.
Параметры
Примеры
в следующем примере запись журнала записывается в журнал событий приложения Windows и завершает текущий процесс.
Комментарии
Этот метод завершает процесс без выполнения каких-либо активных try / finally блоков или методов завершения.
Environment.FailFast метод записывает message строку в журнал событий приложения Windows, создает дамп приложения, а затем завершает текущий процесс. message Строка также включается в отчеты об ошибках в корпорацию Майкрософт.
Используйте Environment.FailFast метод вместо Exit метода, чтобы завершить работу приложения, если состояние приложения повреждено после восстановления, и выполнение try / finally блоков и методов завершения приложения приведет к повреждению ресурсов программы.
сведения выводятся в корпорацию майкрософт с помощью отчеты об ошибках Windows. дополнительные сведения см. в разделе отчеты об ошибках Windows: начало работы.
вызов Environment.FailFast метода для завершения выполнения приложения, выполняющегося в Visual Studio отладчике, приводит к возникновению исключения ExecutionEngineException и автоматически активирует помощник по отладке управляемого кода (MDA) фаталексекутионенгиниррор.
Применяется к
FailFast(String, Exception)
Завершает процесс сразу после записи сообщения в журнал событий приложений Windows, после чего включает сообщение и сведения об исключении в отчет об ошибках, отправляемый в корпорацию Майкрософт.
Параметры
Комментарии
Этот метод завершает процесс без выполнения каких try / finally либо активных блоков или методов завершения.
Environment.FailFast метод записывает message строку в журнал событий приложения Windows, создает дамп приложения, а затем завершает текущий процесс.
Если exception имеет значение null или если exception не возникает исключение, этот метод действует так же, как FailFast(String) перегрузка метода.
Fail-Безопасный Итератор против Fail-Быстрый Итератор
Быстрое и практическое сравнение отказобезопасных и отказоемкости итераторов на Java.
1. Введение
Отказ-Быстрые системы прерывают работу как можно быстрее, немедленно обнажая сбои и останавливая всю операцию.
В то время как Системы fail-Safe не прерываются операцию в случае сбоя. Такие системы стараются как можно больше избегать сбоев.
2. Отказ-быстрые итераторы
Быстро итераторы в Java не подыграют, когда базовая коллекция изменяется.
При итерации, на каждом Далее () вызова, текущее значение modCount сравнивается с первоначальным значением. Если есть несоответствие, это бросает ПараллельноМодификацияИсключение который прерывает всю операцию.
В фрагменте кода выше, ПараллельноМодификацияИсключение получает бросили в начале следующего цикла итерации после изменения была выполнена.
Однако, если Коллекционая ‘ы удалить () метод используется для удаления элемента, он бросает исключение:
3. Отказобезопасные Итераторы
Итераторы Fail-Safe выступают за отсутствие сбоев из-за неудобства обработки исключений.
Эти итераторы создают клон фактического Коллекционая и итерировать над ним. Если какая-либо модификация происходит после создания итератора, копия остается нетронутой. Следовательно, эти Итераторы продолжать цикл над Коллекционая даже если он изменен.
Тем не менее, важно помнить, что нет такой вещи, как действительно Fail-Безопасный итератор. Правильный термин слабо последовательный.
Таким образом, в фрагменте кода выше, итерация циклы пять раз, что означает он обнаруживает недавно добавленный элемент в Коллекционая .
4. Заключение
В этом учебнике мы видели, что Fail-Safe и Fail-Fast Итераторы означает и как они реализуются в Java.
Fail-fast design при автоматизации сборок с помощью Nuke
Что такое fail-fast design?
Что уже есть в Nuke?
Можно ли расширить fail-fast инструменты?
Вступление
Кто не знаком с Nuke вы всегда можете ознакомиться или на официальном сайте или посмотреть вот эту презентацию.
Далее в статье мы поговорим о существующем в Nuke fail-fast подходе и о том, как его можно развивать.
Что такое fail-fast design?
На официальном сайте указано, что Nuke следует fail-fast философии. Раз уж это является основной темой статьи, то логично было бы разобраться что это такое.
Википедия на этот счёт говорит следующее:
Длинная и скучная цитата из Википедии
In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system’s state at several points in an operation, so any failures can be detected early. The responsibility of a fail-fast module is detecting errors, then letting the next-highest level of the system handle them.
В моем примитивном понимании это то, что мы, как программисты, делаем каждый день. А именно вызываем исключение максимально близко к месту появления проблемы, то есть как только поняли что что-то идёт не по плану.
В контексте систем автоматизации сборок получается посмотреть на fail-fast design немного под другим углом. Всё дело в том, что любая система автоматизации сборок это по сути набор шагов, каждый шаг изолированно выполняет свою часть работы и имеется некая взаимосвязь между ними. Допустим у нас есть Nuke проект для деплоя некого абстрактного веб-приложения, тогда его план будет выглядеть примерно так:
Пример очередности выполнения шагов
Что будет если что-то пойдёт не так на шаге Deploy? Логично что деплой упадёт и наш код не будет доставлен на нужное окружение. Но кроме этого стоит учесть что уже были выполнены шаги Build, Migration, StopIisPool. А значит кроме этого у нас ещё и выключен пул, а значит приложение не работает, хотя могло бы.
Читатель может справедливо заметить, что это проблемы пайплайна и это нужно было бы учесть и например, сделать включение пула обязательным действием вне зависимости от всего остального, но fail-fast design подталкивает нас к мысли «Зачем запускать то, что всё равно упадёт?».
Лучше не работать с мыслью «Зачем запускать то, что всё равно упадёт?», потому что тогда можно вообще перестать писать код)
Что уже есть в Nuke?
Из коробки в Nuke доступна проверка параметров перед запуском. На всякий случай напомню что Параметр в Nuke это переменная значение которой может передаваться через аргументы командной строки или как переменная окружения.
Реализовывается такая проверка следующим образом:
Расшифровка кода выше
Target в Nuke это делегат из-за этого и получается такая сомнительная конструкция в виде смайлика => _ =>
Результат выполнения Nuke если не был передан обязательный параметр
В целом из fail-fast в Nuke это всё, поэтому перейдём к моим размышлениям на эту тему.
Можно ли расширить fail-fast инструменты?
В моей команде мы используем собственную библиотеку на основе Nuke для автоматизации сборок, собственную потому что есть много нюансов и тонкостей которые необходимо часто переиспользовать. У нас довольно много проектов и различных сценариев в которых используется Nuke поэтому базовая библиотека именно то, что нужно.
В нашей библиотеке довольно много зависимостей поэтому мы используем dependency injection внутри Nuke на основе IServiceCollection. Поэтому мне хотелось бы проверять перед запуском не только параметры, но и классы-сервисы в которым делегируется определенная работа.
Такие сервисы, которые выполняют свою работу в рамках Nuke я разделил на 2 группы и получились следующие интерфейсы:
Использование в Nuke с помощью метода расширения выглядит таким образом:
В коде выше по сути есть 2 этапа:
Находим все зависимости для класса T
Для каждого класса выполняем метод CheckService()
На всякий случай замечу, что AlreadyCheckedTypes передаётся для того, чтобы не проверять много раз один и тот же сервис.
Метод который проверяет сервисы тоже достаточно прост:
Далее уже при создании каждого сервиса реализовываем логику проверки, если это конечно же необходимо. Например для сервиса, который работает с файловой системой проверка может выглядеть как-то так:
Заключение
Буду рад комментариями и предложениям/критике по поводу изложенного выше материала.