Ошибка быстрого и надежного

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

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

Но аргумент, который я продолжаю противодействовать, заключается в следующем: "Мы не можем допустить, чтобы этот материал вышел из строя, клиент ожидает, что это сработает, почему бы вам не решить эту проблему". И это будет аргументом в пользу надежности: будь либеральным в том, что вы принимаете, консервативным в том, что вы отправляете.

Следует также отметить, что это, в основном, проблемы с прерывистостью. Мы видим их в тестах интеграции, но их трудно воспроизвести. Используются время и concurrency.

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

Я должен сказать, что система не "сбой" в производстве, но мой модуль может просто показать ошибку оператору и попросить их связаться со службой поддержки. Крушение было бы большой проблемой, но если я четко сообщаю об ошибке, то разве это не правильно? Я подозреваю, что мои сверстники просто не хотят, чтобы у клиента были проблемы, период. Но мой модуль отказывается от данных из других модулей нашего продукта, а не от пользователя. Поэтому мне кажется, что мы просто не решаем проблемы.

Итак, мне нужно быть более прагматичным или удерживать свою почву?

Ответ 1

Спасибо всем. Случай, который вызвал этот вопрос, закончился хорошо, и отчасти благодаря тому, что я получил от ответов выше.

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

Я планировал добавить новый обработчик и кодовый путь для этого случая, который будет правильно выполняться, как если бы это был специальный прецедент, который ранее был недокументирован.

У нас была дискуссия, в которой я повторил необходимость решения проблемы на границе, но также был готов помочь. Я изложил свой план на другой стороне, потому что у меня возникло подозрение, что мое положение было воспринято как слишком педантичное, и что решение было воспринято так, как мне нужно было отключить ложную проверку безобидных данных, даже если это было неправильно. В действительности, тем не менее, способ, которым я работаю, в основном основан на данных, поэтому я объяснил, почему он должен быть правильным и как поведение управляется им, и как при размещении этих данных я буду внедрять специальный путь кода.

Я думаю, что это усугубило мою позицию, и это привело к более детальному обсуждению другого побочного отвращения к фиксации данных. Оказалось, что более усталость иметь дело с системой, подверженной ошибкам, чем фактическое препятствие. Было относительно простое решение, было просто страшно внести изменения, мышление, которое довольно укоренилось.

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

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

Опять же, спасибо всем, кто ответил. Я слишком новичок, чтобы оценивать комментарии, но я ценю все представленные перспективы.

Ответ 2

Я разделяю предпочтение/принцип "fail fast". Не думайте об этом, как о конфликте принципов, тем не менее, это скорее конфликт понимания. У вашего коллеги есть какое-то невысказанное требование ( "не показывать пользователю плохое время" ), что подразумевает пропущенное требование. У вас не было возможности задуматься об этом предложении заранее, поэтому это требование оставило неприятный вкус во рту. Забудьте эту точку зрения, повторно подходите к ней как к новому проекту с фиксированным требованием, с которым вы можете работать.

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

Будьте осторожны в том, как вы предотвращаете идеи. Постоянно ссылаясь на другие системы, "слишком сложные и хрупкие", возможно, неправильно потирает людей. Экспресс просто системы новы для вас и занимают больше времени, чтобы понять. Постарайтесь понять их, поэтому вы не уменьшаете ожидания людей от ваших возможностей.

Ответ 3

Я бы сказал, что это зависит от того, что произойдет, если вы не остановитесь. Кто-то paycheck обрабатывается неправильно? Высылается неправильный заказ? Это стоило бы остановиться.

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

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

То, что это действительно происходит, - это то, что человек, который оценивает вашу производительность, хочет от вас, особенно после того, как вы объясните им проблему, по электронной почте.

Ответ 4

Проще говоря, это звучит как "не проверять что-то, с чем вы не можете справиться". Тот факт, что вы поймаете ошибку и можете сообщить об этом, означает, что вы ее не распространяете. Но это также означает, что, поскольку вы можете сообщить об этом, у вас есть механизм блокировки ошибки и, следовательно, потенциально справиться с ней самостоятельно и исправить ее, а не сообщать об этом.

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

В нижней строке вам нужны оба. Вам нужно попытаться сделать данные максимально бесплатными, а также сообщить об этом неожиданно.

Я не думаю, что вы можете запереть дверь и скрестить руки, говоря: "Это не моя проблема". Тот факт, что он исходит из "старых, хрупких систем", не имеет смысла. ВАШ код не является старым хрупким и, безусловно, эффективным местом, с точки зрения всей интегрированной системы, для "исправления" данных, как только вы обнаружите проблему. Yea старые модули будут продолжать GIGO для других, меньших систем, но эти устаревшие модули в сочетании с вашим новым модулем являются сплоченным целым и, таким образом, составляют "систему".

Типичная реальная проблема здесь - это просто уравнение времени/значения для написания всего этого исправления кода и новых функций. Это разные дебаты. Но если у вас есть время, и вы знаете, что вы можете сделать, чтобы очищать входящие данные, "будьте либеральными в том, что вы принимаете" - это правильная политика.

Ответ 5

Я не буду вдаваться в причины, но вы правы.

По моему опыту, PHB не хватает части мозга, требуемой для понимания того, почему неудача быстро имеет достоинства и "надежность", как определено do-whatever-it-takes-eat-errors-if-needed, это плохая идея. Это безнадежно. У них просто нет аппаратного обеспечения, чтобы это понять. Они, как правило, говорят "хорошо, что вы хорошо знаете, но как насчет пользователя" - это просто их версия думать о детях, и сигнализирует о завершении конвертации со мной в любое время, когда он появился.

Мой совет - встать на свои места. Вечно.

Ответ 6

Это сложная штука. Если ваш модуль получает плохие данные и "нормально" для вас просто ничего не делать с ними и не возвращать, я бы предложил написать в журнал ошибок вместо того, чтобы показывать пользователю ошибку.

Ответ 7

Это зависит от класса ошибки, которую вы получаете. Если способ взлома системы означает, что вы можете продолжать работу без подачи плохих данных в другие части системы, вы должны сделать все, что в ваших силах, чтобы работать с любым вводом.

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

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

Ответ 8

Вопрос от ваших сверстников: "Почему бы вам не обойти эту проблему"

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

Однако ваш вопрос не указывает домен, в котором работает ваше программное обеспечение. Если вы знаете, что входящие данные ошибочны, можно ли снова запросить данные? Действительно ли можно оправиться от ситуации?

Я упомянул, что "домен" здесь важен. Итак, если у вас есть приложение, которое отображает потоковые видеоданные, например, и, может быть, ваш беспроводной сигнал слабый, поэтому поток поврежден, если система "не работает быстро" и отображает сообщение об ошибке? Или должно отображаться более плотное изображение и попытка повторного подключения, если это необходимо, в зависимости от масштабов проблемы?

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

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