Заметки Андрея Романова

​Подход Fail Fast

В разработке есть довольно здравые и широко применимые подходы, о которых почему-то редко рассказывают в учебных курсах или книгах, и ты со временем либо интуитивно приходишь к ним сам (зачастую не в состоянии осознанно их сформулировать), либо узнаешь о них случайно. Для меня одним из таких подходов оказался Fail Fast. Давно о нём где-то поверхностно услышал и отложил в закладки, а сейчас добрался до исходной статьи Джима Шора Fail Fast (PDF, ~120 КБ).

Джим пишет, что одни из самых неприятных багов — те, которые проявляются не сразу и вызывают отложенные последствия, по которым сложно определить исходную проблему. Такие баги обычно вызваны тем, что в процессе выполнения программы ошибки всеми силами глушатся и игнорируются, чтобы сохранить работоспособность программы.

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

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

Джим приводит аналогичный пример про конфигурацию прямо в начале своей статьи: при отсутствии значения в конфигурации лучше вообще не запускать приложение и выводить сообщение о проблеме, чем использовать какое-то значение по умолчанию. В первом случае разработчик попробует запустить приложение и получит ошибку вида «Ключ ____ отсутствует в конфигурации», а во втором случае он уйдёт отдыхать и узнает о проблеме от недовольных пользователей, которые не могли решать свои задачи всё время его отсутствия.

Важно отметить, что этот подход не про полную остановку программы при обнаружении ошибки, а в первую очередь про то, чтобы сделать проблемы заметными. Джим приводит в пример пакетную обработку данных, при которой можно обойтись отправкой сообщения об ошибке разработчику (например, через Sentry) и ненавязчивым сообщением пользователю о том, что часть данных обработать не удалось. Основная идея в том, чтобы разработчик узнал о проблеме как можно раньше и чтобы сообщение о проблеме направило его как можно ближе к причине.

www.tgoop.com/andrew_r_notes/204

5.9K viewsedited  Jan 12, 2021 at 17:21

​Подход Fail Fast

В разработке есть довольно здравые и широко применимые подходы, о которых почему-то редко рассказывают в учебных курсах или книгах, и ты со временем либо интуитивно приходишь к ним сам (зачастую не в состоянии осознанно их сформулировать), либо узнаешь о них случайно. Для меня одним из таких подходов оказался Fail Fast. Давно о нём где-то поверхностно услышал и отложил в закладки, а сейчас добрался до исходной статьи Джима Шора Fail Fast (PDF, ~120 КБ).

Джим пишет, что одни из самых неприятных багов — те, которые проявляются не сразу и вызывают отложенные последствия, по которым сложно определить исходную проблему. Такие баги обычно вызваны тем, что в процессе выполнения программы ошибки всеми силами глушатся и игнорируются, чтобы сохранить работоспособность программы.

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

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

Джим приводит аналогичный пример про конфигурацию прямо в начале своей статьи: при отсутствии значения в конфигурации лучше вообще не запускать приложение и выводить сообщение о проблеме, чем использовать какое-то значение по умолчанию. В первом случае разработчик попробует запустить приложение и получит ошибку вида «Ключ ____ отсутствует в конфигурации», а во втором случае он уйдёт отдыхать и узнает о проблеме от недовольных пользователей, которые не могли решать свои задачи всё время его отсутствия.

Важно отметить, что этот подход не про полную остановку программы при обнаружении ошибки, а в первую очередь про то, чтобы сделать проблемы заметными. Джим приводит в пример пакетную обработку данных, при которой можно обойтись отправкой сообщения об ошибке разработчику (например, через Sentry) и ненавязчивым сообщением пользователю о том, что часть данных обработать не удалось. Основная идея в том, чтобы разработчик узнал о проблеме как можно раньше и чтобы сообщение о проблеме направило его как можно ближе к причине.

BY Заметки Андрея Романова