Система poka yoke защита от ошибок error proofing

Poka-yoke (звучит как пока ёкэ) — забавный на слух японский термин, который обозначает один из инструментов бережливого производства. Оказывается, мы сталкиваемся с ним каждый день. Только на русском он звучит как «принцип нулевой ошибки» или «защита от дурака».

На английский poka-yoke дословно переводится как «avoid mistakes», т.е. «избегать ошибок». А на практике используется адаптированный перевод — mistake proofing или error proofing (защита от ошибок).

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

Устройства защиты от дурака предохраняют не просто от ошибок, а от ошибок, вызванных человеческим фактором:

• невнимательностью
• забывчивостью
• неосторожностью
• незнанием
• усталостью
• и даже саботажем.

Люди ошибаются, а poka-yoke приспособления не дают им допустить ошибку.

Принцип действия poka-yoke характеризуются:

Устройства poka-yoke работают по принципу pass no defect — не пропустить ни одного дефекта.

История создания методов poka-yoke

Poka-yoke призван устранить ошибки, основанные на человеческом факторе. Защита от ошибок использовалась на предприятиях в том или ином виде задолго до формирования концепции poka-yoke. Формализовали эту систему в Toyota.

Изобретатель методов poka-yoke — японский инженер Сигео Синго (1909-1990), эксперт в области производства и один из создателей производственной системы Toyota. Сигео Синго разработал подход Zero Quality Control (ZQC), или Zero Defects (ноль дефектов).

Zero defects метод основан на убеждении, что возникновению дефектов препятствует такой контроль производственного процесса, при котором дефект не возникнет, даже если машина или человек совершат ошибку.

Акцент контроля качества смещается с проверки готовой продукции на факт брака на предупреждение возникновения брака на каждом этапе производства.

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

Poka-yoke или метод нулевой ошибки — один из ключевых аспектов ZQC. Система poka-yoke использует сенсоры или другие устройства, которые буквально не дают оператору совершить ошибку.

Они регулируют производственный процесс и предотвращают дефекты одним из двух способов:

Poka-yoke не ищет виновных в ошибках, цель метода — найти и устранить слабые места в производственной системе, из-за которых ошибка стала возможной.

Уровни устройств poka-yoke

Способы защиты от дурака делятся на три уровня по возрастанию эффективности:

Принципы защиты от ошибок

Существует шесть принципов или методов защиты от ошибок. Они перечислены в порядке приоритета:

Основные методы poka-yoke

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

Контактные методы

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

Лучшие контактные методы — это пассивные устройства, такие как направляющие штыри или блоки, которые не дают неправильно разместить заготовки на конвейере.

Считывающие методы

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

Методы последовательного движения

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

Типы чувствительных устройств

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

Сенсоры физического контакта

Этот тип устройств работает по принципу физического касания детали или части оборудования. Обычно такое устройство посылает электронный сигнал в момент контакта. Вот некоторые примеры таких устройств:

• Концевые переключатели — подтверждают наличие и положение объектов, которые касаются маленького рычага на переключателе. Самые распространенные и недорогие устройства.
• Сенсорные переключатели — аналогичны концевым выключателям, но активируются легким прикосновением объекта к тонкой «антенне».
• Триметрон — это чувствительные игольчатые датчики, которые посылают сигналы для звукового оповещения или остановки оборудования, когда измерения объекта выходят за пределы допустимого диапазона.

Энергетические сенсорные датчики

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

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

К другим типам энергетических сенсорных устройств относятся:

Сенсоры, которые определяют изменения физических условий

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

7 ключей к внедрению эффективной системы защиты от ошибок

Чтобы эффективно внедрить метод нулевой ошибки, нужно отталкиваться от следующих рекомендаций:

Poka-yoke устройства вокруг нас

Люди допускают ошибки не только на производстве, но и в процессе использования продуктов. Эти ошибки ведут, как минимум, к поломкам, как максимум, к возникновению серьезной опасности. Поэтому производители встраивают защиту от дурака в конструкцию своих изделий.

Poka-yoke в быту

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

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

Ребенок не попробует лекарство, которое упаковано в баночку со специальной защитой от детей.

Лифт автоматически откроет двери, если наткнется на препятствие при закрытии.

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

Poka-yoke в автомобиле

Современные автомобили просто напичканы устройствами защиты от дурака. Правда, они не такие дешевые, как предполагает концепция poka-yoke, но зато спасают жизни.

К ним относятся активные и пассивные системы безопасности, например:

Poka-yoke в программном обеспечении

Классический пример Poka Yoke — элементы интерфейса, которые запрашивают подтверждение на удаление данных, чтобы пользователь случайно не стер нужную информацию. Чтобы вы случайно не удалили изменения в вордовском файле, система предложит вам его сохранить. Google пошел еще дальше и сам сохраняет изменения после ввода каждого символа.

Примерами защиты от дурака могут быть обязательные поля форм и поля с заданным форматом ввода данных.

Книги по теме

Zero Quality Control: Source Inspection and the Poka-Yoke System / Shigeo Shingo

Книга от создателя системы poka-yoke Сигео Синго, впервые опубликованная в 1986 году. В ней автор обосновывает важность применения устройств защиты от ошибок для достижения безупречного качества продукции. Он называет 112 примеров устройств poka-yoke, работающих в цехах. Внедрение этих устройств обошлось меньше $100.

Poka-Yoke: Improving Product Quality by Preventing Defects / Nikkan Kogyo Shimbun

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

Вердикт

Система poka-yoke — очередное гениальное изобретение японцев. За 30 лет устройства poka-yoke эволюционировали вместе с производственным оборудованием. Они перестали быть дешевыми, как гласит один из принципов концепции, но стали гораздо эффективнее.

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

Само понятие защиты от ошибок стало шире: специальные устройства, конструктивные особенности и просто предупреждения оберегают нас от ошибок в повседневной жизни.
Благодаря poka-yoke у нас определенно меньше проблем.

Poka-yoke (звучит как пока ёкэ) — забавный на слух японский термин, который обозначает один из инструментов бережливого производства. Оказывается, мы сталкиваемся с ним каждый день. Только на русском он звучит как «принцип нулевой ошибки» или «защита от дурака».

На английский poka-yoke дословно переводится как «avoid mistakes», т.е. «избегать ошибок». А на практике используется адаптированный перевод — mistake proofing или error proofing (защита от ошибок).

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

Устройства защиты от дурака предохраняют не просто от ошибок, а от ошибок, вызванных человеческим фактором:

• невнимательностью
• забывчивостью
• неосторожностью
• незнанием
• усталостью
• и даже саботажем.

Люди ошибаются, а poka-yoke приспособления не дают им допустить ошибку.

Принцип действия poka-yoke характеризуются:

Устройства poka-yoke работают по принципу pass no defect — не пропустить ни одного дефекта.

Poka-yoke призван устранить ошибки, основанные на человеческом факторе. Защита от ошибок использовалась на предприятиях в том или ином виде задолго до формирования концепции poka-yoke. Формализовали эту систему в Toyota.

Изобретатель методов poka-yoke — японский инженер Сигео Синго (1909-1990), эксперт в области производства и один из создателей производственной системы Toyota. Сигео Синго разработал подход Zero Quality Control (ZQC), или Zero Defects (ноль дефектов).

Zero defects метод основан на убеждении, что возникновению дефектов препятствует такой контроль производственного процесса, при котором дефект не возникнет, даже если машина или человек совершат ошибку.

Акцент контроля качества смещается с проверки готовой продукции на факт брака на предупреждение возникновения брака на каждом этапе производства.

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

Poka-yoke или метод нулевой ошибки — один из ключевых аспектов ZQC. Система poka-yoke использует сенсоры или другие устройства, которые буквально не дают оператору совершить ошибку.

Они регулируют производственный процесс и предотвращают дефекты одним из двух способов:

Poka-yoke не ищет виновных в ошибках, цель метода — найти и устранить слабые места в производственной системе, из-за которых ошибка стала возможной.

Уровни устройств poka-yoke

Способы защиты от дурака делятся на три уровня по возрастанию эффективности:

Принципы защиты от ошибок

Существует шесть принципов или методов защиты от ошибок. Они перечислены в порядке приоритета:

Основные методы poka-yoke

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

Контактные методы

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

Лучшие контактные методы — это пассивные устройства, такие как направляющие штыри или блоки, которые не дают неправильно разместить заготовки на конвейере.

Считывающие методы

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

Методы последовательного движения

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

Типы чувствительных устройств

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

Сенсоры физического контакта

Этот тип устройств работает по принципу физического касания детали или части оборудования. Обычно такое устройство посылает электронный сигнал в момент контакта. Вот некоторые примеры таких устройств:

• Концевые переключатели — подтверждают наличие и положение объектов, которые касаются маленького рычага на переключателе. Самые распространенные и недорогие устройства.
• Сенсорные переключатели — аналогичны концевым выключателям, но активируются легким прикосновением объекта к тонкой «антенне».
• Триметрон — это чувствительные игольчатые датчики, которые посылают сигналы для звукового оповещения или остановки оборудования, когда измерения объекта выходят за пределы допустимого диапазона.

Энергетические сенсорные датчики

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

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

К другим типам энергетических сенсорных устройств относятся:

Сенсоры, которые определяют изменения физических условий

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

7 ключей к внедрению эффективной системы защиты от ошибок

Чтобы эффективно внедрить метод нулевой ошибки, нужно отталкиваться от следующих рекомендаций:

Poka-yoke устройства вокруг нас

Люди допускают ошибки не только на производстве, но и в процессе использования продуктов. Эти ошибки ведут, как минимум, к поломкам, как максимум, к возникновению серьезной опасности. Поэтому производители встраивают защиту от дурака в конструкцию своих изделий.

Poka-yoke в быту

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

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

Ребенок не попробует лекарство, которое упаковано в баночку со специальной защитой от детей.

Лифт автоматически откроет двери, если наткнется на препятствие при закрытии.

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

Poka-yoke в автомобиле

Современные автомобили просто напичканы устройствами защиты от дурака. Правда, они не такие дешевые, как предполагает концепция poka-yoke, но зато спасают жизни.

К ним относятся активные и пассивные системы безопасности, например:

Poka-yoke в программном обеспечении

Классический пример Poka Yoke — элементы интерфейса, которые запрашивают подтверждение на удаление данных, чтобы пользователь случайно не стер нужную информацию. Чтобы вы случайно не удалили изменения в вордовском файле, система предложит вам его сохранить. Google пошел еще дальше и сам сохраняет изменения после ввода каждого символа.

Примерами защиты от дурака могут быть обязательные поля форм и поля с заданным форматом ввода данных.

Книги по теме

Zero Quality Control: Source Inspection and the Poka-Yoke System / Shigeo Shingo

Книга от создателя системы poka-yoke Сигео Синго, впервые опубликованная в 1986 году. В ней автор обосновывает важность применения устройств защиты от ошибок для достижения безупречного качества продукции. Он называет 112 примеров устройств poka-yoke, работающих в цехах. Внедрение этих устройств обошлось меньше $100.

Poka-Yoke: Improving Product Quality by Preventing Defects / Nikkan Kogyo Shimbun

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

Вердикт

Система poka-yoke — очередное гениальное изобретение японцев. За 30 лет устройства poka-yoke эволюционировали вместе с производственным оборудованием. Они перестали быть дешевыми, как гласит один из принципов концепции, но стали гораздо эффективнее.

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

Само понятие защиты от ошибок стало шире: специальные устройства, конструктивные особенности и просто предупреждения оберегают нас от ошибок в повседневной жизни.
Благодаря poka-yoke у нас определенно меньше проблем.

Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип «poka-yoke».

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

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

Итак, как мы можем предотвратить это? С помощью принципа «poka-yoke».

Что такое poka-yoke?

Poka-yoke – японский термин, который переводится на английский примерно как «mistake-proofing» (защита от ошибки), а в русском варианте более известен, как «защита от дурака». Это понятие возникло в бережливом производстве, где оно относится к любому механизму, который помогает оператору оборудования избежать ошибок.

Помимо производства, poka-yoke часто используется в бытовой электронике. Возьмём, к примеру, SIM-карту, которая благодаря своей асимметричной форме может быть вставлена в адаптер только правильной стороной.

Противоположным примером (без использования принципа poka-yoke) является порт PS/2, имеющий одинаковую форму разъёма и для клавиатуры, и для мыши. Их можно отличить только по цвету и поэтому легко перепутать.

Ещё концепция poka-yoke может использоваться в программировании. Идея в том, чтобы сделать публичные интерфейсы нашего кода как можно более простыми и понятными и генерировать ошибки, как только код будет использоваться неправильно. Это может показаться очевидным, но на самом деле мы часто сталкиваемся с кодом, в котором этого нет.

Обратите внимание, что poka-yoke не предназначен для предотвращения преднамеренного злоупотребления. Цель лишь в том, чтобы избежать случайных ошибок, а не в защите кода от злонамеренного использования. Так или иначе, пока кто-то имеет доступ к вашему коду, он всегда сможет обойти предохранители, если действительно этого захочет.

Прежде чем обсуждать конкретные меры, позволяющие сделать код более защищённым от ошибок, важно знать, что механизмы poka-yoke можно разделить на две категории:

• предотвращение ошибок
• обнаружение ошибок.

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

С другой стороны, механизмы обнаружения ошибок находятся вне нашего кода. Они контролируют наши приложения, чтобы отслеживать возможные ошибки и предупреждать нас о них. Примером может быть программное обеспечение, которое определяет, имеет ли устройство, подключённое к порту PS/2, правильный тип, и, если нет, сообщает пользователю, почему оно не работает. Такое ПО не могло бы предотвратить ошибку, поскольку разъёмы одинаковые, но оно может обнаружить её и сообщить об этом.

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

Примеры предотвращения ошибок

Объявление типов

Ранее известное как Type Hinting в PHP 5, объявление типов – это простой способ защиты от ошибок при вызове функций и методов в PHP 7. Назначив аргументам функции определённые типы, становится сложнее нарушать порядок аргументов при вызове этой функции.

Например, давайте рассмотрим уведомление, которое мы можем отправить пользователю:

<?php

    class Notification {
        private $userId;
        private $subject;
        private $message;

        public function __construct(
            $userId,
            $subject, 
            $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId()
        {
            return $this->userId;
        }

        public function getSubject()
        {
            return $this->subject;
        }

        public function getMessage()
        {
            return $this->message;
        }
    }

Без объявления типов можно случайно передать переменные неверного типа, что может нарушить работу приложения. Например, мы можем предположить, что $userId должен быть string, в то время как на самом деле он может быть int.

Если мы передадим в конструктор неправильный тип, то ошибка, вероятно, останется незамеченной до тех пор, пока приложение не попытается что-то сделать с этим уведомлением. И в этот момент, скорее всего, мы получим какое-то загадочное сообщение об ошибке, в котором ничто не будет указывать на наш код, где мы передаём string вместо int. Поэтому обычно предпочтительнее заставить приложение сломаться как можно скорее, чтобы как можно раньше в ходе разработки обнаружить подобные ошибки.

В этом конкретном случае можно просто добавить объявление типов – PHP остановится и немедленно предупредит нас фатальной ошибкой, как только мы попытаемся передать параметр не того типа:

<?php

    declare(strict_types=1);

    class Notification {
        private $userId;
        private $subject;
        private $message;

        public function __construct(
            int $userId,
            string $subject, 
            string $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId() : int
        {
            return $this->userId;
        }

        public function getSubject() : string
        {
            return $this->subject;
        }

        public function getMessage() : string
        {
            return $this->message;
        }
    }

Обратите внимание, что по умолчанию PHP попытается привести неверные аргументы к их ожидаемым типам. Чтобы этого не произошло и сгенерировалась фатальная ошибка, важно разрешить строгую типизацию (strict_types). Из-за этого объявление скалярных типов не является идеальной формой poka-yoke, но служит неплохой отправной точкой для уменьшения количества ошибок. Даже при отключённой строгой типизации объявление типов всё равно может служить подсказкой, какой тип ожидается для аргумента.

Кроме того, мы объявили типы возвращаемых данных для наших методов. Это упрощает определение того, какие значения мы можем ожидать при вызове той или иной функции.

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

Объекты-значения

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

Когда аргументы имеют разные типы, PHP может предупредить нас о нарушении порядка аргументов, но это не cработает, если у нас несколько аргументов с одним и тем же типом.

Чтобы в этом случае избежать ошибок, мы могли бы обернуть наши аргументы в объекты-значения (value objects):

class UserId {
        private $userId;

        public function __construct(int $userId) {
            $this->userId = $userId;
        }

        public function getValue() : int
        {
            return $this->userId;
        }
    }

    class Subject {
        private $subject;

        public function __construct(string $subject) {
            $this->subject = $subject;
        }

        public function getValue() : string
        {
            return $this->subject;
        }
    }

    class Message {
        private $message;

        public function __construct(string $message) {
            $this->message = $message;
        }

        public function getMessage() : string
        {
            return $this->message;
        }
    }

    class Notification {
        /* ... */

        public function __construct(
            UserId $userId,
            Subject $subject, 
            Message $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId() : UserId { /* ... */ }

        public function getSubject() : Subject { /* ... */ }

        public function getMessage() : Message { /* ... */ }
    }

Поскольку наши аргументы теперь имеют очень специфический тип, их почти невозможно перепутать.

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

Валидация

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

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

Чтобы предотвратить подобные ошибки, мы могли бы добавить некоторую валидацию в конструктор UserId:

class UserId {
        private $userId;

        public function __construct($userId) {
            if (!is_int($userId) || $userId < 0) {
                throw new InvalidArgumentException(
                    'UserId should be a positive integer.'
                );
            }

            $this->userId = $userId;
        }

        public function getValue() : int
        {
            return $this->userId;
        }
    }

Таким образом, мы всегда можем быть уверены, что при работе с объектом UserId он имеет правильное состояние. Это избавит нас от необходимости постоянно проверять данные на разных уровнях приложения.

Обратите внимание, что здесь мы могли бы добавить объявление скалярного типа вместо использования is_int, но это заставит нас включать строгую типизацию везде, где используется UserId. Если это не сделать, то PHP будет пытаться приводить другие типы к int всякий раз, когда они передаются в качестве UserId. Это может стать проблемой, так как мы могли бы, например, передать float, который может оказаться неправильной переменной, поскольку идентификаторы пользователя обычно не являются float. В других случаях, когда мы могли бы, например, работать с объектом Price, отключение строгой типизации может привести к ошибкам округления, поскольку PHP автоматически преобразует float-переменные в int.

Неизменяемость

По умолчанию объекты в PHP передаются по ссылке. Это означает, что, когда мы вносим изменения в объект, он мгновенно изменяется во всём приложении.

Хотя у этого подхода есть свои преимущества, он имеет и некоторые недостатки. Рассмотрим пример уведомления, отправляемого пользователю посредством SMS и электронной почты:

interface NotificationSenderInterface
    {
        public function send(Notification $notification);
    }

    class SMSNotificationSender implements NotificationSenderInterface
    {
        public function send(Notification $notification) {
            $this->cutNotificationLength($notification);

            // Send an SMS...
        }

        /**
         * Makes sure the notification does not exceed the length of an SMS.
         */
        private function cutNotificationLength(Notification $notification)
        {
            $message = $notification->getMessage();
            $messageString = substr($message->getValue(), 160);
            $notification->setMessage(new Message($messageString));
        }
    }

    class EmailNotificationSender implements NotificationSenderInterface
    {
        public function send(Notification $notification) {
            // Send an e-mail ...
        }
    }

    $smsNotificationSender = new SMSNotificationSender();
    $emailNotificationSender = new EmailNotificationSender();

    $notification = new Notification(
        new UserId(17466),
        new Subject('Demo notification'),
        new Message('Very long message ... over 160 characters.')
    );

    $smsNotificationSender->send($notification);
    $emailNotificationSender->send($notification);

Поскольку объект Notification передаётся по ссылке, получился непреднамеренный побочный эффект. При сокращении длины сообщения в SMSNotificationSender связанный объект Notification был обновлен во всём приложении, так что сообщение тоже было обрезанным, когда позже отправлялось в EmailNotificationSender.

Чтобы исправить это, сделаем объект Notification неизменяемым. Вместо того чтобы предоставлять set-методы для внесения в него изменений, добавим with-методы, которые делают копию исходного Notification перед внесением этих изменений:

class Notification {
        public function __construct( ... ) { /* ... */ }

        public function getUserId() : UserId { /* ... */ }

        public function withUserId(UserId $userId) : Notification {
            $c = clone $this;
            $c->userId = clone $userId;
            return $c;
        }

        public function getSubject() : Subject { /* ... */ }

        public function withSubject(Subject $subject) : Notification {
            $c = clone $this;
            $c->subject = clone $subject;
            return $c;
        }

        public function getMessage() : Message { /* ... */ }

        public function withMessage(Message $message) : Notification {
            $c = clone $this;
            $c->message = clone $message;
            return $c;
        }
    }

Теперь, когда мы вносим изменения в класс Notification, например, сокращая длину сообщения, они больше не распространяются на всё приложение, что позволяет предотвратить появление различных побочных эффектов.

Однако обратите внимание, что в PHP очень сложно (если не невозможно) сделать объект по-настоящему неизменяемым. Но для того чтобы сделать наш код более защищённым от ошибок, будет достаточно добавить «неизменяемые» with-методы вместо set-методов, так как пользователям класса больше не нужно будет помнить о необходимости клонировать объект перед внесением изменений.

Возвращение null-объектов

Иногда мы сталкиваемся с функциями и методами, которые могут вернуть либо какое-то значение, либо null. И эти null’евые возвращаемые значения могут представлять проблему, поскольку почти всегда нужно будет проверять значения на null, прежде чем мы сможем что-то с ними сделать. Об этом опять же легко забыть.

Чтобы избавиться от необходимости проверки возвращаемых значений, мы могли бы возвращать вместо этого null-объекты. Например, у нас может быть ShoppingCart со скидкой или без:

interface Discount {
        public function applyTo(int $total);
    }

    interface ShoppingCart {
        public function calculateTotal() : int;

        public function getDiscount() : ?Discount;
    }

При вычислении конечной стоимости ShoppingCart перед вызовом метода applyTo нам теперь всегда нужно проверять, что вернула функция getDiscount(): null или скидку:

    $total = $shoppingCart->calculateTotal();

    if ($shoppingCart->getDiscount()) {
        $total = $shoppingCart->getDiscount()->applyTo($total);
    }

Если не выполнить эту проверку, то мы получим предупреждение PHP и/ или другие побочные эффекты, когда getDiscount() вернёт null.

С другой стороны, этих проверок можно избежать, если мы вернём null-объект, когда скидка не предоставляется:

class ShoppingCart {
        public function getDiscount() : Discount {
            return !is_null($this->discount) ? $this->discount : new NoDiscount();
        }
    }

    class NoDiscount implements Discount {
        public function applyTo(int $total) {
            return $total;
        }
    }

Теперь, когда мы вызываем getDiscount(), мы всегда получаем объект Discount, даже если скидка отсутствует. Таким образом, мы можем применить скидку к итоговой сумме, даже если её нет, и нам больше не нужна инструкция if:

    $total = $shoppingCart->calculateTotal();
    $totalWithDiscountApplied = $shoppingCart->getDiscount()->applyTo($total);

Опциональные зависимости

По тем же причинам, по которым мы желаем избежать null’евых возвращаемых значений, мы хотим избавиться и от опциональных зависимостей, просто сделав все зависимости обязательными.

Возьмём, к примеру, следующий класс:

class SomeService implements LoggerAwareInterface {
        public function setLogger(LoggerInterface $logger) { /* ... */ }

        public function doSomething() {
            if ($this->logger) {
                $this->logger->debug('...');
            }

            // do something

            if ($this->logger) {
                $this->logger->warning('...');
            }

            // etc...
        }
    }

Есть две проблемы:

1. Нам постоянно нужно проверять наличие логгера в нашем методе doSomething().
2. При настройке класса SomeService в нашем сервис-контейнере кто-то может забыть сконфигурировать логгер, или он может вообще не знать, что у класса есть возможность это сделать.

Мы можем упростить код, сделав LoggerInterface обязательной зависимостью:

class SomeService {
        public function __construct(LoggerInterface $logger) { /* ... */ }

        public function doSomething() {
            $this->logger->debug('...');

            // do something

            $this->logger->warning('...');

            // etc...
        }
    }

Теперь наш публичный интерфейс стал менее громоздким, и всякий раз, когда кто-то создаёт новый экземпляр SomeService, он знает, что класс требует экземпляр LoggerInterface, и поэтому он никак не сможет забыть указать его.

Кроме того, мы избавились от необходимости постоянной проверки наличия логгера, что делает doSomething() более лёгким для понимания и менее восприимчивым к ошибкам всякий раз, когда кто-то вносит в него изменения.

Если бы мы захотели использовать SomeService без логгера, то могли бы применить ту же логику, что и с возвращением null-объекта:

$service = new SomeService(new NullLogger());

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

Public-методы

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

Свести количество public-методов к минимуму поможет аналогия с транзакциями. Рассмотрим, к примеру, перевод денег между двумя банковскими счетами:

$account1->withdraw(100);
$account2->deposit(100);

Хотя база данных с помощью транзакции может обеспечить отмену снятия денег, если пополнение не может быть сделано (или наоборот), она не может помешать нам забыть вызвать либо $account1->withdraw(), либо $account2->deposit(), что приведёт к некорректной операции.

К счастью, мы легко можем исправить это, заменив два отдельных метода одним транзакционным:

$account1->transfer(100, $account2);

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

Примеры обнаружения ошибок

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

Unit-тесты

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

Поскольку кто-то может забывать проводить unit-тестирование, рекомендуется автоматически запускать тесты при внесении изменений с использованием таких сервисов, как Travis CI и GitLab CI. Благодаря им разработчики получают уведомления, когда что-то ломается, что также помогает убедиться, что сделанные изменения работают так, как задумывалось.

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

Отчёты о покрытии кода тестами и мутационное тестирование

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

Ещё один способ убедиться, что у нас достаточно unit-тестов, — использование мутационных тестов, например, с помощью Humbug. Как следует из названия, они проверяют, достаточно ли наш код покрыт тестами, слегка изменяя исходный код и запуская после этого unit-тесты, которые должны генерировать ошибки из-за сделанных изменений.

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

Статические анализаторы кода

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

Помимо анализаторов, встроенных в большинство IDE, в процесс сборки наших приложений можно включить сторонние и даже пользовательские анализаторы для выявления конкретных проблем. Неполный список анализаторов, подходящих для проектов на PHP, можно найти на GitHub.

Существуют также онлайн-решения, например, SensioLabs Insights.

Логирование

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

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

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

Не подавлять ошибки

Даже при логировании ошибок случается, что некоторые из них подавляются. PHP имеет тенденцию продолжать работу, когда происходит «восстанавливаемая» ошибка. Однако ошибки могут быть полезны при разработке или тестировании новых функций, поскольку могут указывать на ошибки в коде. Вот почему большинство анализаторов кода предупреждают вас, когда обнаруживают, что вы используете @ для подавления ошибок, так как это может скрывать ошибки, которые неизбежно появятся снова, как только приложение станет использоваться.

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

Помимо error_reporting, важно всегда включать strict_types, чтобы PHP не пытался автоматически приводить аргументы функций к их ожидаемому типу, поскольку это может приводить к трудно обнаруживаемым ошибкам (например, ошибкам округления при приведении float к int).

Использование вне PHP

Поскольку poka-yoke скорее концепция, чем конкретная методика, её также можно применять в сферах, не связанных с PHP.

Инфраструктура

На уровне инфраструктуры многие ошибки могут быть предотвращены путём создания общей среды разработки, идентичной среде production, с использованием таких инструментов, как Vagrant.

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

REST API

При создании REST API можно внедрить poka-yoke, чтобы упростить использование API. Например, мы можем убедиться, что возвращаем ошибку всякий раз, когда неизвестный параметр передаётся в URL или в теле запроса. Это может показаться странным, поскольку мы, очевидно, хотим избежать «поломки» наших API-клиентов, но, как правило, лучше как можно скорее предупреждать разработчиков, использующих наш API, о некорректном использовании, чтобы ошибки были исправлены на ранней стадии процесса разработки.

Например, у нас в API может быть параметр color, но кто-то, кто использует наш API, может случайно использовать параметр colour. Без каких-либо предупреждений эта ошибка может запросто попасть в продакшн, пока её не заметят конечные пользователи.

Чтобы узнать, как создавать API, которые не доставят вам хлопот, прочтите книгу Building APIs You Won’t Hate.

Конфигурация приложения

Практически все приложения нуждаются в какой-либо пользовательской настройке. Чаще всего разработчики предоставляют как можно больше значений настроек по умолчанию, что упрощает конфигурирование. Однако, как в примере с color и colour, можно легко ошибиться в параметрах конфигурации, что заставит приложение неожиданно вернуться к значениям по умолчанию.

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

Предотвращение ошибок пользователя

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

Заключение

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

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

Чтобы ещё больше уменьшить количество ошибок, мы должны стремиться к тому, чтобы public-интерфейсы нашего кода были максимально простыми и понятными.

Большая часть несчастных случаев на производстве происходят из-за человеческого фактора: человек торопится, пытается сделать, как ему кажется, лучше, либо просто не знает, как работать с тем или иным оборудованием, и в результате получает травмы. А возможно ли организовать работу так, чтобы само оборудование исключало риск возникновения ошибки? Рассказываем в статье.

История Poka-Yoke 

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

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

Shigeo Shingo предложил решение, которое стало первым механизмом Poka-Yoke. В новом подходе перед коробкой с деталями помещалась небольшая тарелка, и первая задача рабочего на этапе сборки — вынуть из коробки две пружины и поместить их на тарелку. Если после сборки оставалась какая-то пружина, то рабочий знал, что он забыл ее вставить, и мог быстро устранить ошибку, не доводя до брака.

Изначально Shigeo Shingo назвал эту механику «Baka-Yoke» или «Защита от дурака», но потом изменил название на более толерантное «Poka-Yoke», чтобы не обижать рабочих.

Термин Poka-Yoke происходит от японских слов «Pokа» («непреднамеренная ошибка») и «Yoke» («предотвращать»). Poka-Yoke уже более полувека служит инструментом системы производственного качества компании Toyota, основная идея которой заключается в проектировании производственных процессов, исключающих ошибки или, по крайней мере, легко выявляемых для исправления. 

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

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

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

Одна из основных целей Poka-Yoke — не допустить дефекта или негативных последствий в случае, если пользователь продолжает совершать действия, пренебрегая предупреждениями.

«При чем здесь сервис?» — спросите вы. Poka-Yoke показал отличные результаты в повышении устойчивости производственных процессов и качества производимых товаров, которыми самостоятельно пользуются люди без какого-либо контроля со стороны производителя.

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

Согласно универсальной теории сервиса, определения и понятия которого описываются в фундаментальной работе профессора Университета Бригэма Янга доктора Скотта Сэмпсона «Understanding Service Businesses», сервис — это продукт, в производстве которого клиент принимает непосредственное участие, в отличие от производства стиральных машин или автомобилей.

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

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

Однако уволить или понизить зарплату вы ему не можете, потому что он стажер. Таким же неопытным сотрудником в сервисном производстве является Ваш клиент. 

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

Насколько хорошо вы знаете своего клиента?

В чём основная сложность при взаимодействии с пользователем и с тем фактом, что клиент принимает непосредственное участие в сервисном производстве?

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

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

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

Голос потребителя

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

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

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

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

Как видите из примера поведения клиентов, сервисные процессы взаимодействия должны обладать двумя характеристиками:

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

---

О том, как проектировать сервисные процессы, обладающие подобными свойствами, с «примерами из практики», расскажем из второй части статьи про волшебную формулу Poka-Yoke.

Фото на обложке: Shutterstock / Dilok Klaisataporn

Рабочая инструкция

Системы защиты от ошибок (Poka Yoke)

1.ЦЕЛЬ

Установить порядок разработки и использования систем защиты от ошибок при выпуске продукции.

2.ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

• Poka-Yoke (яп., произносится «пока-ёкэ»; рус. — защита от ошибок) — один из элементов системы бережливого производства, позволяющий операторам при работе избежать ошибок в результате невнимательности. (установка неправильной детали, пропуск детали, установка детали другой стороной и т.д.).
• НД — нормативный документ.
• ОГТ — отдел главного технолога.
• ООО — отдел обслуживания оборудования.
• ДР — дирекция по развитию.

Ответственность за включение систем защиты от ошибок в техпроцесс сборки изделий несут сотрудники ДР. За функционирование и проверку их работоспособности — ООО. В случае возникновения необходимости применения дополнительных систем защиты от ошибок в ходе массового производства, ответственность за их разработку и внедрение несут сотрудники ОГТ.

3.ОПИСАНИЕ

Системы защиты от ошибок разделяют на:

• сигнализирующие (без остановки производства) — обнаруживающие ошибку и предупреждающие о ней, не разрешая осуществлять передачу дефектного изделия на следующую стадию производства;
• блокирующие (с остановкой производства) — не позволяющие совершить ошибку.

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

Исторически первый случай осознанного применения систем Poka Yoke — это изобретение ткацкого станка, который останавливался при обрыве нити, и таким образом не был способен производить дефектную ткань.

Другие примеры защиты от ошибок:

• При конструировании детали придание ей такой формы, которая позволяет установить ее только в правильном положении. Вариант, — уникальное размещение реперных знаков на разных печатных платах одинаковых габаритов для автоматического их распознавания в станках.
• Установка над контейнерами с деталями фотоэлементов, настроенных таким образом, что если оператор, доставая деталь, не пересек рукой световой луч, то изделие не будет передано на следующую стадию.
• Применение для комплектующих специальных ящиков с ячейками, форма которых совпадает с формой комплектующих. Что позволяет обеспечивать применение правильных деталей при сборке.
• Остановка станков при сбоях с включением звукового и/или светового сигнала для привлечения внимания оператора.
• Печать идентификационных этикеток только при получении положительного результата тестирования.
• Приведение в действие пресса одновременным нажатием двух кнопок, разнесенных друг от друга на расстояние, не позволяющее нажать их одной рукой (предотвращается попадание рук оператора под прессу

Рисунок 1 — пример устройства контактного типа для защиты от ошибок.

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

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

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

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

Работа начинается с выявления характера реальных или предполагаемых дефектов. Затем определяются их причины (с помощью метода «5 почему») и выявляются параметры, изменяемые одновременно с действием этой причины. После аналитической стадии переходят к стадии творческой, придумывая, как исключить саму возможность появления дефекта. Или хотя бы предупредить о возможном его появлении. В результате появляется идея системы Poka-Yoke.

Места установки систем защиты от ошибок помечаются в карте потока процесса специальным значком «PY»

B планах управления следует предусматривать регулярную проверку работоспособности установленных систем защиты от ошибок (обязательно — при каждом запуске процесса сборки изделий).

5.ССЫЛКИ

• СТП «Технологическая подготовка производства и управление технологической документацией»
• СТП «План управления»
• СТП «Порядок подачи, оценки и реализации кайдзен-предложений»
• CTП «FMEA»
• РИ «Определение ключевых характеристик продуктов и процессов»
• Ф «Карта потока процесса»
• Ф «5 почему»

Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип «poka-yoke».

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

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

Итак, как мы можем предотвратить это? С помощью принципа «poka-yoke».

Что такое poka-yoke?

Poka-yoke – японский термин, который переводится на английский примерно как «mistake-proofing» (защита от ошибки), а в русском варианте более известен, как «защита от дурака». Это понятие возникло в бережливом производстве, где оно относится к любому механизму, который помогает оператору оборудования избежать ошибок.

Помимо производства, poka-yoke часто используется в бытовой электронике. Возьмём, к примеру, SIM-карту, которая благодаря своей асимметричной форме может быть вставлена в адаптер только правильной стороной.

Противоположным примером (без использования принципа poka-yoke) является порт PS/2, имеющий одинаковую форму разъёма и для клавиатуры, и для мыши. Их можно отличить только по цвету и поэтому легко перепутать.

Ещё концепция poka-yoke может использоваться в программировании. Идея в том, чтобы сделать публичные интерфейсы нашего кода как можно более простыми и понятными и генерировать ошибки, как только код будет использоваться неправильно. Это может показаться очевидным, но на самом деле мы часто сталкиваемся с кодом, в котором этого нет.

Обратите внимание, что poka-yoke не предназначен для предотвращения преднамеренного злоупотребления. Цель лишь в том, чтобы избежать случайных ошибок, а не в защите кода от злонамеренного использования. Так или иначе, пока кто-то имеет доступ к вашему коду, он всегда сможет обойти предохранители, если действительно этого захочет.

Прежде чем обсуждать конкретные меры, позволяющие сделать код более защищённым от ошибок, важно знать, что механизмы poka-yoke можно разделить на две категории:

• предотвращение ошибок
• обнаружение ошибок.

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

С другой стороны, механизмы обнаружения ошибок находятся вне нашего кода. Они контролируют наши приложения, чтобы отслеживать возможные ошибки и предупреждать нас о них. Примером может быть программное обеспечение, которое определяет, имеет ли устройство, подключённое к порту PS/2, правильный тип, и, если нет, сообщает пользователю, почему оно не работает. Такое ПО не могло бы предотвратить ошибку, поскольку разъёмы одинаковые, но оно может обнаружить её и сообщить об этом.

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

Примеры предотвращения ошибок

Объявление типов

Ранее известное как Type Hinting в PHP 5, объявление типов – это простой способ защиты от ошибок при вызове функций и методов в PHP 7. Назначив аргументам функции определённые типы, становится сложнее нарушать порядок аргументов при вызове этой функции.

Например, давайте рассмотрим уведомление, которое мы можем отправить пользователю:

<?php

    class Notification {
        private $userId;
        private $subject;
        private $message;

        public function __construct(
            $userId,
            $subject, 
            $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId()
        {
            return $this->userId;
        }

        public function getSubject()
        {
            return $this->subject;
        }

        public function getMessage()
        {
            return $this->message;
        }
    }

Без объявления типов можно случайно передать переменные неверного типа, что может нарушить работу приложения. Например, мы можем предположить, что $userId должен быть string, в то время как на самом деле он может быть int.

Если мы передадим в конструктор неправильный тип, то ошибка, вероятно, останется незамеченной до тех пор, пока приложение не попытается что-то сделать с этим уведомлением. И в этот момент, скорее всего, мы получим какое-то загадочное сообщение об ошибке, в котором ничто не будет указывать на наш код, где мы передаём string вместо int. Поэтому обычно предпочтительнее заставить приложение сломаться как можно скорее, чтобы как можно раньше в ходе разработки обнаружить подобные ошибки.

В этом конкретном случае можно просто добавить объявление типов – PHP остановится и немедленно предупредит нас фатальной ошибкой, как только мы попытаемся передать параметр не того типа:

<?php

    declare(strict_types=1);

    class Notification {
        private $userId;
        private $subject;
        private $message;

        public function __construct(
            int $userId,
            string $subject, 
            string $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId() : int
        {
            return $this->userId;
        }

        public function getSubject() : string
        {
            return $this->subject;
        }

        public function getMessage() : string
        {
            return $this->message;
        }
    }

Обратите внимание, что по умолчанию PHP попытается привести неверные аргументы к их ожидаемым типам. Чтобы этого не произошло и сгенерировалась фатальная ошибка, важно разрешить строгую типизацию (strict_types). Из-за этого объявление скалярных типов не является идеальной формой poka-yoke, но служит неплохой отправной точкой для уменьшения количества ошибок. Даже при отключённой строгой типизации объявление типов всё равно может служить подсказкой, какой тип ожидается для аргумента.

Кроме того, мы объявили типы возвращаемых данных для наших методов. Это упрощает определение того, какие значения мы можем ожидать при вызове той или иной функции.

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

Объекты-значения

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

Когда аргументы имеют разные типы, PHP может предупредить нас о нарушении порядка аргументов, но это не cработает, если у нас несколько аргументов с одним и тем же типом.

Чтобы в этом случае избежать ошибок, мы могли бы обернуть наши аргументы в объекты-значения (value objects):

class UserId {
        private $userId;

        public function __construct(int $userId) {
            $this->userId = $userId;
        }

        public function getValue() : int
        {
            return $this->userId;
        }
    }

    class Subject {
        private $subject;

        public function __construct(string $subject) {
            $this->subject = $subject;
        }

        public function getValue() : string
        {
            return $this->subject;
        }
    }

    class Message {
        private $message;

        public function __construct(string $message) {
            $this->message = $message;
        }

        public function getMessage() : string
        {
            return $this->message;
        }
    }

    class Notification {
        /* ... */

        public function __construct(
            UserId $userId,
            Subject $subject, 
            Message $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId() : UserId { /* ... */ }

        public function getSubject() : Subject { /* ... */ }

        public function getMessage() : Message { /* ... */ }
    }

Поскольку наши аргументы теперь имеют очень специфический тип, их почти невозможно перепутать.

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

Валидация

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

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

Чтобы предотвратить подобные ошибки, мы могли бы добавить некоторую валидацию в конструктор UserId:

class UserId {
        private $userId;

        public function __construct($userId) {
            if (!is_int($userId) || $userId < 0) {
                throw new InvalidArgumentException(
                    'UserId should be a positive integer.'
                );
            }

            $this->userId = $userId;
        }

        public function getValue() : int
        {
            return $this->userId;
        }
    }

Таким образом, мы всегда можем быть уверены, что при работе с объектом UserId он имеет правильное состояние. Это избавит нас от необходимости постоянно проверять данные на разных уровнях приложения.

Обратите внимание, что здесь мы могли бы добавить объявление скалярного типа вместо использования is_int, но это заставит нас включать строгую типизацию везде, где используется UserId. Если это не сделать, то PHP будет пытаться приводить другие типы к int всякий раз, когда они передаются в качестве UserId. Это может стать проблемой, так как мы могли бы, например, передать float, который может оказаться неправильной переменной, поскольку идентификаторы пользователя обычно не являются float. В других случаях, когда мы могли бы, например, работать с объектом Price, отключение строгой типизации может привести к ошибкам округления, поскольку PHP автоматически преобразует float-переменные в int.

Неизменяемость

По умолчанию объекты в PHP передаются по ссылке. Это означает, что, когда мы вносим изменения в объект, он мгновенно изменяется во всём приложении.

Хотя у этого подхода есть свои преимущества, он имеет и некоторые недостатки. Рассмотрим пример уведомления, отправляемого пользователю посредством SMS и электронной почты:

interface NotificationSenderInterface
    {
        public function send(Notification $notification);
    }

    class SMSNotificationSender implements NotificationSenderInterface
    {
        public function send(Notification $notification) {
            $this->cutNotificationLength($notification);

            // Send an SMS...
        }

        /**
         * Makes sure the notification does not exceed the length of an SMS.
         */
        private function cutNotificationLength(Notification $notification)
        {
            $message = $notification->getMessage();
            $messageString = substr($message->getValue(), 160);
            $notification->setMessage(new Message($messageString));
        }
    }

    class EmailNotificationSender implements NotificationSenderInterface
    {
        public function send(Notification $notification) {
            // Send an e-mail ...
        }
    }

    $smsNotificationSender = new SMSNotificationSender();
    $emailNotificationSender = new EmailNotificationSender();

    $notification = new Notification(
        new UserId(17466),
        new Subject('Demo notification'),
        new Message('Very long message ... over 160 characters.')
    );

    $smsNotificationSender->send($notification);
    $emailNotificationSender->send($notification);

Поскольку объект Notification передаётся по ссылке, получился непреднамеренный побочный эффект. При сокращении длины сообщения в SMSNotificationSender связанный объект Notification был обновлен во всём приложении, так что сообщение тоже было обрезанным, когда позже отправлялось в EmailNotificationSender.

Чтобы исправить это, сделаем объект Notification неизменяемым. Вместо того чтобы предоставлять set-методы для внесения в него изменений, добавим with-методы, которые делают копию исходного Notification перед внесением этих изменений:

class Notification {
        public function __construct( ... ) { /* ... */ }

        public function getUserId() : UserId { /* ... */ }

        public function withUserId(UserId $userId) : Notification {
            $c = clone $this;
            $c->userId = clone $userId;
            return $c;
        }

        public function getSubject() : Subject { /* ... */ }

        public function withSubject(Subject $subject) : Notification {
            $c = clone $this;
            $c->subject = clone $subject;
            return $c;
        }

        public function getMessage() : Message { /* ... */ }

        public function withMessage(Message $message) : Notification {
            $c = clone $this;
            $c->message = clone $message;
            return $c;
        }
    }

Теперь, когда мы вносим изменения в класс Notification, например, сокращая длину сообщения, они больше не распространяются на всё приложение, что позволяет предотвратить появление различных побочных эффектов.

Однако обратите внимание, что в PHP очень сложно (если не невозможно) сделать объект по-настоящему неизменяемым. Но для того чтобы сделать наш код более защищённым от ошибок, будет достаточно добавить «неизменяемые» with-методы вместо set-методов, так как пользователям класса больше не нужно будет помнить о необходимости клонировать объект перед внесением изменений.

Возвращение null-объектов

Иногда мы сталкиваемся с функциями и методами, которые могут вернуть либо какое-то значение, либо null. И эти null’евые возвращаемые значения могут представлять проблему, поскольку почти всегда нужно будет проверять значения на null, прежде чем мы сможем что-то с ними сделать. Об этом опять же легко забыть.

Чтобы избавиться от необходимости проверки возвращаемых значений, мы могли бы возвращать вместо этого null-объекты. Например, у нас может быть ShoppingCart со скидкой или без:

interface Discount {
        public function applyTo(int $total);
    }

    interface ShoppingCart {
        public function calculateTotal() : int;

        public function getDiscount() : ?Discount;
    }

При вычислении конечной стоимости ShoppingCart перед вызовом метода applyTo нам теперь всегда нужно проверять, что вернула функция getDiscount(): null или скидку:

    $total = $shoppingCart->calculateTotal();

    if ($shoppingCart->getDiscount()) {
        $total = $shoppingCart->getDiscount()->applyTo($total);
    }

Если не выполнить эту проверку, то мы получим предупреждение PHP и/ или другие побочные эффекты, когда getDiscount() вернёт null.

С другой стороны, этих проверок можно избежать, если мы вернём null-объект, когда скидка не предоставляется:

class ShoppingCart {
        public function getDiscount() : Discount {
            return !is_null($this->discount) ? $this->discount : new NoDiscount();
        }
    }

    class NoDiscount implements Discount {
        public function applyTo(int $total) {
            return $total;
        }
    }

Теперь, когда мы вызываем getDiscount(), мы всегда получаем объект Discount, даже если скидка отсутствует. Таким образом, мы можем применить скидку к итоговой сумме, даже если её нет, и нам больше не нужна инструкция if:

    $total = $shoppingCart->calculateTotal();
    $totalWithDiscountApplied = $shoppingCart->getDiscount()->applyTo($total);

Опциональные зависимости

По тем же причинам, по которым мы желаем избежать null’евых возвращаемых значений, мы хотим избавиться и от опциональных зависимостей, просто сделав все зависимости обязательными.

Возьмём, к примеру, следующий класс:

class SomeService implements LoggerAwareInterface {
        public function setLogger(LoggerInterface $logger) { /* ... */ }

        public function doSomething() {
            if ($this->logger) {
                $this->logger->debug('...');
            }

            // do something

            if ($this->logger) {
                $this->logger->warning('...');
            }

            // etc...
        }
    }

Есть две проблемы:

1. Нам постоянно нужно проверять наличие логгера в нашем методе doSomething().
2. При настройке класса SomeService в нашем сервис-контейнере кто-то может забыть сконфигурировать логгер, или он может вообще не знать, что у класса есть возможность это сделать.

Мы можем упростить код, сделав LoggerInterface обязательной зависимостью:

class SomeService {
        public function __construct(LoggerInterface $logger) { /* ... */ }

        public function doSomething() {
            $this->logger->debug('...');

            // do something

            $this->logger->warning('...');

            // etc...
        }
    }

Теперь наш публичный интерфейс стал менее громоздким, и всякий раз, когда кто-то создаёт новый экземпляр SomeService, он знает, что класс требует экземпляр LoggerInterface, и поэтому он никак не сможет забыть указать его.

Кроме того, мы избавились от необходимости постоянной проверки наличия логгера, что делает doSomething() более лёгким для понимания и менее восприимчивым к ошибкам всякий раз, когда кто-то вносит в него изменения.

Если бы мы захотели использовать SomeService без логгера, то могли бы применить ту же логику, что и с возвращением null-объекта:

$service = new SomeService(new NullLogger());

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

Public-методы

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

Свести количество public-методов к минимуму поможет аналогия с транзакциями. Рассмотрим, к примеру, перевод денег между двумя банковскими счетами:

$account1->withdraw(100);
$account2->deposit(100);

Хотя база данных с помощью транзакции может обеспечить отмену снятия денег, если пополнение не может быть сделано (или наоборот), она не может помешать нам забыть вызвать либо $account1->withdraw(), либо $account2->deposit(), что приведёт к некорректной операции.

К счастью, мы легко можем исправить это, заменив два отдельных метода одним транзакционным:

$account1->transfer(100, $account2);

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

Примеры обнаружения ошибок

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

Unit-тесты

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

Поскольку кто-то может забывать проводить unit-тестирование, рекомендуется автоматически запускать тесты при внесении изменений с использованием таких сервисов, как Travis CI и GitLab CI. Благодаря им разработчики получают уведомления, когда что-то ломается, что также помогает убедиться, что сделанные изменения работают так, как задумывалось.

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

Отчёты о покрытии кода тестами и мутационное тестирование

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

Ещё один способ убедиться, что у нас достаточно unit-тестов, — использование мутационных тестов, например, с помощью Humbug. Как следует из названия, они проверяют, достаточно ли наш код покрыт тестами, слегка изменяя исходный код и запуская после этого unit-тесты, которые должны генерировать ошибки из-за сделанных изменений.

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

Статические анализаторы кода

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

Помимо анализаторов, встроенных в большинство IDE, в процесс сборки наших приложений можно включить сторонние и даже пользовательские анализаторы для выявления конкретных проблем. Неполный список анализаторов, подходящих для проектов на PHP, можно найти на GitHub.

Существуют также онлайн-решения, например, SensioLabs Insights.

Логирование

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

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

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

Не подавлять ошибки

Даже при логировании ошибок случается, что некоторые из них подавляются. PHP имеет тенденцию продолжать работу, когда происходит «восстанавливаемая» ошибка. Однако ошибки могут быть полезны при разработке или тестировании новых функций, поскольку могут указывать на ошибки в коде. Вот почему большинство анализаторов кода предупреждают вас, когда обнаруживают, что вы используете @ для подавления ошибок, так как это может скрывать ошибки, которые неизбежно появятся снова, как только приложение станет использоваться.

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

Помимо error_reporting, важно всегда включать strict_types, чтобы PHP не пытался автоматически приводить аргументы функций к их ожидаемому типу, поскольку это может приводить к трудно обнаруживаемым ошибкам (например, ошибкам округления при приведении float к int).

Использование вне PHP

Поскольку poka-yoke скорее концепция, чем конкретная методика, её также можно применять в сферах, не связанных с PHP.

Инфраструктура

На уровне инфраструктуры многие ошибки могут быть предотвращены путём создания общей среды разработки, идентичной среде production, с использованием таких инструментов, как Vagrant.

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

REST API

При создании REST API можно внедрить poka-yoke, чтобы упростить использование API. Например, мы можем убедиться, что возвращаем ошибку всякий раз, когда неизвестный параметр передаётся в URL или в теле запроса. Это может показаться странным, поскольку мы, очевидно, хотим избежать «поломки» наших API-клиентов, но, как правило, лучше как можно скорее предупреждать разработчиков, использующих наш API, о некорректном использовании, чтобы ошибки были исправлены на ранней стадии процесса разработки.

Например, у нас в API может быть параметр color, но кто-то, кто использует наш API, может случайно использовать параметр colour. Без каких-либо предупреждений эта ошибка может запросто попасть в продакшн, пока её не заметят конечные пользователи.

Чтобы узнать, как создавать API, которые не доставят вам хлопот, прочтите книгу Building APIs You Won’t Hate.

Конфигурация приложения

Практически все приложения нуждаются в какой-либо пользовательской настройке. Чаще всего разработчики предоставляют как можно больше значений настроек по умолчанию, что упрощает конфигурирование. Однако, как в примере с color и colour, можно легко ошибиться в параметрах конфигурации, что заставит приложение неожиданно вернуться к значениям по умолчанию.

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

Предотвращение ошибок пользователя

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

Заключение

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

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

Чтобы ещё больше уменьшить количество ошибок, мы должны стремиться к тому, чтобы public-интерфейсы нашего кода были максимально простыми и понятными.

What is Poka Yoke?

Poka yoke, ‘mistake-proofing’ in Japanese, prevents avoidable mistakes from occurring. This applies to any environment, be it in manufacturing, hospitals or even in the home.

This article looks at the following:

• Meaning
• Origin and application
• Examples in the automotive industry
• Error-proofing examples in manufacturing
• Mistake-proofing examples in daily life
• Other examples

Definition of Poka Yoke

This is a Japanese word that means mistake proofing of equipment or processes to make them safe and reliable.

These are simple, yet effective design features that make it almost impossible for errors to occur.

In fact, the original term was Baka-Yoke or “fool-proof”. Due to the inappropriateness of the term, “mistake-proofing” became the preferred term.

The aim of mistake-proofing is to remove the need for people to think about the products or processes they are using. This is because the products have a design that makes it impossible to use them in the wrong way.

When someone uses the product the wrong way, it does not function and it becomes obvious to the user that they are doing the wrong thing. The simple yet effective design features make it difficult for errors to occur during usage of the product.

Origin and Application

The concept developed out of the need to achieve quality in production processes. It was Shigeo Shingo, one of the pioneers of the Toyota Production System, who proposed the concept. He was a quality guru who proposed the idea of ‘Zero Defects’ as a quality paradigm.

The thinking was that a process should be able to detect and prevent errors from occurring. This would lead to a final product of high quality.

Poka Yoke Examples in the Automotive Industry

Many people lose their lives or get maimed through vehicular accidents each year. Safety of users of automobiles is of paramount importance and many measures have been taken to make them safe. The following are examples of mistake-proofing in the automotive industry:

• Radar and video cameras in new vehicle models are able to tell the distance and speed of other road users. This helps them prevent collisions in case of sudden stops. The device here is more of a warning and preventive measure but it does not strictly fit into the concept of behaviour modification. The driver may choose to ignore the warning which will lead to an accident. The device does not stop the accident from happening in the first place.
• Automatic breaking system stops the vehicle in case the driver fails to brake when an obstacle suddenly appears on the road. If the system above is used with this device, it will be a better preventive measure as the system will note that a warning has been ignored. The sensors will then kick in and stop the vehicle – a key component of poka yoke is at play here.

• Lane-keeping assist alerts the driver that he is about to deviate from his lane. If the driver is not responsive, the vehicle intervenes and returns to the correct lane on its own. This device also fits well with the automatic intervention philosophy of poka yoke. There is no way the driver will commit an error because the vehicle will stop him from doing so.

• Electronic stability control helps reduce the possibility of accidents that can occur when a vehicle skids uncontrollably due to over-steering by the driver. The condition being controlled here is the slippery road — when this condition comes into play the system kicks in to prevent an unwanted result from occurring.
• Cross-traffic alerts warn drivers of impending traffic when they are reversing from a parking position. Like the first example of mistake-proofing in the automotive sector, this device is more of a warning and must be used in-conjunction with other devices to be successful.
• Adaptive headlights are able to respond to the conditions on the road so as to assist the driver have better visibility. For example, they are able to illuminate curved roads and also during bad weather.
• Airbags deflate quickly after an accident to prevent injury to the occupants of the vehicle.
• Seat belt pre-tensioners assist in holding the passenger in place in case of an accident and prevent them from sliding through.

• Blind spot assist warns the driver when there are objects within the blind-spot range that are not visible.

• EBS braking distributes power evenly and the discs expand symmetrically when hot. This minimises uneven tear of the discs
• Brakes that continuously self-monitors and reports any problems to the central control unit. This prevent the likelihood of an accident attributable to the breaking system

Poka Yoke Examples in Everyday Life

Products that we use every day have features that make them safe and convenient. The following are a few examples of how mistake-proofing is used for everyday household products:

• Micro-wave oven does not work until the door is shut.
• Washing machines only start when the door is closed and cannot be opened until the cycle is over.

• Electric plugs have an earth pin that is longer than the other pins and is the first to make contact with the socket. The protective shield of the neutral and earth sockets are then opened safely.
• Electric sockets are shaped in a manner that only one way of plugging-in is possible. This prevents the possibility of a short-circuit occurring.

• Child resistant tops for medicines and household chemicals makes it difficult for children to consume the contents.
• Elevator doors have a sensor that causes them to open when there is an obstruction-this prevents injury to someone trying to enter as the doors are closing.
• Box cutters have a retractable blade that only pops out when the handle is held.
• Lawn mowers have a safety bar on the handle that when released, switches off the machine.
• Circuit breakers in the home electrical system prevent electrical overloads.
• Overflow outlets in bathroom and kitchen sinks prevent flooding of the house when the drain is blocked.
• The Door of a washing machine or dryer makes the machine stop when it is opened, so as to prevent injury from accidents

Examples of Poka Yoke in Manufacturing

In lean manufacturing systems, poka yoke also includes a philosophy of constantly working to prevent mistakes from occurring in the first place. The internal processes in lean manufacturing systems are supposed to produce quality products the first time. Error-proofing in this case is a quality assurance technique that ensures quality is in-built and results in better products.

For the final product to be of high quality, all the inter-connected process steps have to give first time quality. If an mistake or defect is allowed to move to the next step, the likelihood of it appearing in the finished product is very high. It is therefore necessary to develop ways of preventing a defective product moving to downstream process.

This is important because a finished product is considered to be the most expensive form of inventory due to the accumulated costs along the value chain. If a defect occurs in the finished product, the costs of production increase due to the effort required to correct it.

• Magnets in a grain packaging plant detect and remove metal pieces before they are packed.
• Interlock switches which detect the position of a machine guard and switch off the machine when the guard is lifted. The machine will never operate when the guard has been lifted and this prevents accidents to the operator.
• Light curtains in a factory detect when someone is near very dangerous machines and switches off the machine to prevent injuries.
• Safety mats near machine areas that pose a danger automatically trigger stoppage when someone steps on them. This prevents injury to personnel (such are technicians) who are trying to access dangerous sections of a machine.
• Power guards on high inertia machines with moving parts prevent opening until the parts have stopped completely in order to prevent accidents.
• Machines that must be controlled using both hands ensure that some distance is kept between the operator and dangerous machine parts.
• In the food industry, gloves and other small pieces of personal protective equipment must be blue in colour for ease of detection in case they fall into food. This is because blue foods are rare in nature and the color difference makes it easy to detect that a foreign object has fallen into the food.
• Using standardized containers at the workstation enables workers to know exact quantities without having to weigh or count the contents.
• Use of colour coded date labels to mark the production dates of products. This way the different batches are easily identifiable for the purpose of product rotation. The system is especially useful in the food industry where rotation of batches is very important because of hygiene considerations.

Mistake-Proofing of Products

Safety concerns necessitate the use of mistake proofing techniques on the final product in order to prevent harm to the final consumer.

It also provides ease of use to the product so as to enable the final consumers to be able to solve their problems effectively.

Adding user-friendly features to a product aims at solving safety as well as convenience concerns and makes it almost impossible to use the product in the wrong way.

Other Poka Yoke Examples

There are many other examples of products that have fool-proofing ranging from USB cables to child proof sockets. Here are a few examples:

• Glow-in-the-dark strips around the toilet bowl prevent users from urinating on the sides.
• Mop slippers save time for the busy person as they prepare to go to work or school.
• Scrap collecting bowl has a ledge that is attached to the table top to collect vegetable scraps before they fall on the ground.
• Oven rack guard prevents accidental burns as one is removing food from the oven chamber.
• Locator stickers that are put on commonly lost items such as keys and can be traced using the phone.
• Upside-down tomato sauce bottles enable the consumer to use up all the tomato sauce and also lets the water that collects at the bottom come out first.
• Mobile phones are designed in such a way that when they fall, the cover separates so as to minimise the shock that would damage them.
• Color-coding of electrical wires is meant to prevent short circuiting that can occur if they are not matched properly.
• Ice blocks that prevent someone from drinking too much.
• A company invented a fork that tells you when you have eaten too much thus preventing you from getting over-weight

Poka Yoke Examples in Nature

Mistake-proofing also occurs in natural systems and the human body system is a good example of how it works to prevent errors from occurring:

• Coughing is a natural reaction that prevents the error of foreign bodies from entering into the lungs. The sensitive wall linings of the respiratory tract detect and eject minute particles through coughing.
• Veins have valves that are designed to prevent the error of back-flow of blood as it travels through the system. They also allow some blood to collect within the system without busting as they have a larger internal diameter.
• Arteries have thick walls that can withstand the high pressure that blood from the heart exerts on the circulatory system.
• Tearing is a necessary reaction to the entry of foreign bodies into the eye.
• Mucus membrane traps bacteria and prevents the error of pathogens entering the system.
• The skin is the first defence against entry of foreign bodies and the oils and enzymes prevent harmful bacteria into the human body.
• Inflammation reaction of swelling happens when blood vessels leak fluid into the tissues. The chemicals attract white blood cells (phagocytes) that eat germs and dead/ damaged cells. This reaction prevents the spread of harmful toxins and pathogens to the rest of the human body and is a form of natural error-proofing.

Error-Proofing in the Space Industry

The space industry requires accurate procedures to be constantly carried out so as to ensure the successful completion of space missions. Any small error in the implementation of these procedures can lead to a major disaster.

The industry has therefore developed many mistake-proofing devices to prevent errors from occurring and this has resulted in the high success rates of space mission over the years. The following are a few examples of error-proofing in the space industry:

• Escape capsule is designed to help the astronauts safely return to earth in case if there is an emergency during launch of the spacecraft. An abort motor fires over half a million pounds of thrust to steer the capsule away from the booster rocket. Another motor steers the capsule in the right direction and then a jettison motor separates the escape rocket from the capsule which has parachutes to allow it to safely land on earth. This error proofing device will save lives in case the launch of the rocket fails.
• Checklists used in the pre-flight preparation are detailed and are designed to ensure all the parameters are within the allowed range before the flight can commence.

Fool-Proofing in Nuclear Power Plants

Nuclear accidents can have devastating effects as was seen in the Chernobyl disaster. Nuclear power plants use the defense-in-depth concept of barriers to the prevent fission material from being released from the reactor core to the environment.

The fuel rods have cladding that prevent the release of fission material in the event of a melt-down. The reactor is designed to assist in the cooling of the rods in case there is a decrease in the cooling water in the core. This is very important as the heat released during the decay of radioactive material can start a chain reaction that is unstoppable.

Error Prevention in the Service Industry

The service industry is very important in that there is direct and constant interaction with the customer and any failure on the part of providers of services can result in losing good business.

This failure to serve a customer as per their expectation can be considered an error and many service providers have put in place a number of error-proofing processes to prevent this from happening.

The following are just a few examples of how service providers mitigate against the chances of causing mistakes in their businesses:

• Electronic tags in airline luggage handling systems ensure that passenger luggage is not lost after check-in. Airline staff are able to locate misplaced luggage anywhere in the world as the tag contains all the necessary passenger and flight information that is used in tracking it.
• Electronic waiter pads in restaurants ensure that the right order goes to the right table at the shortest possible time. This order matching technology prevents the error of waiters taking the wrong order and also enhances fast delivery to the customer.
• Queue management systems in banks and other public venues are designed in such a way that customers are served according to the order in which they came in promptly thus preventing customer dissatisfaction.

Examples in Aeroplanes

The fact that air travel is considered to be safer than road travel can be attributed to a number of fool-proofing devices that have been put in place over the years. While air accidents still occur, they have significantly been reduced because of these devices:

• De-icing chemicals make it difficult for ice to form on the wings of aeroplanes which can cause serious accidents.
• Auto-pilot keeps the plane flying in case of inclement weather or when the pilot is ill-disposed.
• Captain meals on planes must be different from the meals served to other passengers so as to prevent cases of food poisoning affecting the pilot, which can be very dangerous especially mid-flight.
• Fuel jettisoning is an important procedure during emergency landings as it prevents major fires from the fuel held in the tanks.
• Instrument control-panel is located in such a manner that the pilot and engineer are able to view all readings easily.

Conclusion

From the above comprehensive list of examples, it becomes obvious that there are certain characteristics of error-proofing devices that help in achieving the aims of mistake-proofing. These characteristics include:

• Simplicity, which means that the solutions are not complex and unambiguously resolve the problem of error occurring.
• Automatic Nature: they do not require any further intervention from the person using the device.
• Safety is a key characteristic of poka yoke devices in that they also prevent the users from injuries.
• Feedback is immediate in the case of failure when the conditions go out of specification.
• Quality is ingrained in the process and the solutions encourage the right methods to be used by operators of the devices. It is a way of standardizing the correct methods of performing a process.
• Location at the source of a potential problem within a process.
• Reduction in the number of process steps required to complete a process as the inspection aspect is minimized or completely eliminated.

Related Posts