Exemples de dispositifs de prévention des erreurs. Les méthodes de détrompage sont divisées en trois niveaux par ordre d'efficacité croissante.

21.09.2019

Ce qui a fait frémir le système énergétique de l'Oural pour que la Biélorussie se sente

Faits intéressants sur Donald Trump

Le candidat républicain Donald Trump remporte l'élection présidentielle américaine

Quelle alarme de démarrage automatique est la meilleure - comparaison des modèles et des fabricants

Autres noms de la méthode : "Poka-yoke", "Invisible Error Prevention".

But de la méthode

Augmenter la valeur d'usage des produits en évitant les erreurs dans la production existante.

L'essentiel de la méthode

Le concept de prévention des événements indésirables causés par une erreur humaine est simple. S'ils ne sont pas autorisés à se produire dans la production existante, la qualité sera élevée et les améliorations seront minimes. Cela conduit à une satisfaction client accrue et, en même temps, à des coûts de production réduits.

Plan d'action

1. Former une équipe de spécialistes : représentants de la direction, service qualité, service technique et fabrication.

2. Identifier les problèmes qui doivent être résolus et les raisons de leur existence.

3. Développer des mesures pour améliorer la production et prévenir la possibilité d'erreurs, guidées par les règles d'application de la méthode poka-yoke.

4. Éliminer les erreurs potentielles en utilisant des montages, des instruments et des équipements améliorés dans le processus de production.

Caractéristiques de la méthode

Une version moderne de la protection contre les erreurs, connue sous le nom de poka-yoke (poka-yoke1), est apparue au Japon pour améliorer la qualité des produits en évitant les erreurs de production. Auparavant, les spécialistes japonais utilisaient le terme baka-yoke. La traduction littérale du terme "baka-yoke" est "protection contre la bêtise", en d'autres termes, c'est dispositif de protection, grâce à quoi les défauts ne se forment tout simplement pas. Il est à noter que les principales dispositions de ce concept ont été largement utilisées par Ford dès 1908.

Il existe de nombreuses méthodes et techniques pour prévenir les erreurs, allant des simples altérations et modifications apportées aux équipements et aux procédés de fabrication, et se terminant par une modernisation majeure de la conception des produits.

Exemple d'utilisation réception simple protection contre les erreurs

Dans l'atelier, malgré toutes les statistiques, le repérage et le contrôle, deux erreurs identiques se répètent sans cesse : la pièce A se retrouve souvent dans la fenêtre 2 lors de la pose du bloc, et inversement, la pièce B se retrouve dans la fenêtre 1.

Une simple technique de protection contre les erreurs - poka-yoke - vous permet de trouver une solution qui rend toute erreur impossible. Les configurations de la fenêtre 1 et de l'élément de montage A sont modifiées de telle manière qu'un remplacement lors de l'installation est même théoriquement impossible.

Règles d'application des techniques de protection contre les erreurs

1. Rapprochez-vous le plus possible de la source du problème, de l'endroit où le problème est réellement survenu et où il pourrait réapparaître.

2. Introduire immédiatement tous les types de contrôle et de mesures nécessaires pour prévenir la récurrence du problème.

3. En développement et en conception, utiliser des méthodes et des techniques complexes pour résoudre le problème, et en production, appliquer des solutions simples et rapides.

4. Améliorez la production rapidement, sans analyses complexes et de manière à ce que toutes les personnes soient incluses dans la solution problèmes communs et l'élimination des incohérences.

Avantages de la méthode

Application cohérente différentes manières et les techniques de prévention des erreurs peuvent réduire considérablement leur nombre, ce qui contribue à réduire les coûts et à augmenter la satisfaction des clients.

Inconvénients de la méthode

La résistance rencontrée lors de l'introduction forcée de dispositifs de protection contre les erreurs dans la production fait souvent échouer les efforts visant à améliorer le processus.

résultat attendu

Haute valeur de consommation des produits.

Méthode juste à temps

Juste-à-temps (Eng. Just-in-Time, juste à temps) - un des piliers de base Système de production Toyota, une méthode d'organisation de la production. Elle réside dans le fait que pendant processus de production les pièces nécessaires à l'assemblage sont sur la ligne de production exactement au moment où il est nécessaire, et dans le strict quantité requise. En conséquence, une entreprise qui applique systématiquement ce principe élimine les temps d'arrêt, minimise les stocks ou peut atteindre un stock nul. Les principales caractéristiques sont de n'avoir que les fournitures nécessaires en cas de besoin ; améliorer la qualité à l'état de "zéro défaut" ; réduire le temps de cycle en réduisant le temps d'équipement, la taille de la file d'attente et la taille des lots de production ; modifier progressivement les opérations elles-mêmes ; et effectuer ces activités à moindre coût.

La méthode du juste à temps a été inventée en 1954. chez Toyota Corporation. Elle est née des restrictions économiques qui prévalaient alors au Japon. Comme le Japon avait peu de ressources naturelles et des prix de l'immobilier très élevés, les entreprises japonaises devaient veiller à ne pas autoriser les déchets, tels que les entrepôts pour les stocks importants de biens éventuellement excédentaires.

Candidatures juste à temps

· JIT dans la zone de production - couvre le processus de production géré avec l'aide de JIT ;

· JAT dans le domaine des livraisons ;

· JAT dans le domaine de la vente - assure l'approvisionnement de nombreux consommateurs qui soumettent leurs demandes aux systèmes d'information en ligne.

La gestion japonaise réalise le juste-à-temps en évitant systématiquement trois composants indésirables :

MURI - excédent

MUDA - pertes

ARMU - déséquilibre

Les avantages peuvent être identifiés cette méthode:

· Réduction des coûts pour l'entretien des stocks d'entrepôt (employés d'entrepôt, matériel d'entrepôt, loyer installations de stockage et etc.).

· Réduire le temps de la commande(en raison de la taille réduite du lot, du temps de changement, des temps d'arrêt).

· Meilleur approvisionnement en matériaux, pièces et produits semi-finis en raison du rapprochement des fournisseurs avec les fabricants (en plus, plus d'emplois, développement des régions).

· Planification à long terme pour les fournisseurs et la meilleure vente de marchandises.

· Rationalisation de la production par la spécialisation des fournisseurs sur les biens commandés, etc.

Problèmes possibles applications :

· Coûts élevés de transport et d'aménagement de l'itinéraire de transport (forte charge sur la route, possibilité d'embouteillages, bruit dû au transport).

· Forte dépendance vis-à-vis d'un seul fournisseur (en cas de non-respect des conditions de livraison, des pertes de production sont possibles).

· Forte dépendance au respect de la qualité des matériaux fournis (coûts de contrôle des intrants, réclamations).

· Un échange constant d'informations est nécessaire (l'obligation de confirmer la situation financière du fournisseur et du fabricant).

· Pénalités élevées pour les fournisseurs en raison du non-respect des délais de livraison, forte dépendance à un consommateur.

· La nécessité pour les fournisseurs de rapprocher la production et les entrepôts du consommateur.

· Pertes importantes pour les fournisseurs dues à la spécialisation dans les situations de crise.

Projet de cours par discipline

"Moyens et méthodes de management de la qualité"

(extra-muros entraînement)

Exigences d'exécution

(Volume approximatif : 20-30 pages (hors demandes de certification QMS), format de papier A4, taille de police 14 (Times New Roman), interligne - 1.)

Introduction(0,5 - 1 page).

Partie théorique

1. Gestion. La qualité comme objet de management

2. une brève description de versions actuelles de la série ISO 9000 (9000, 9001, 9004).

3. Aspects théoriques de l'application des outils et méthodes de gestion de la qualité nécessaires pour mener à bien la section 2 du travail (brièvement, les principales dispositions et étapes).

3.1 Mission de l'entreprise.

3.2 Objectifs de l'entreprise.

3.3 Base théorique mener une analyse SWOT et une analyse PEST.

3.4 Fondements théoriques pour déterminer les paramètres de qualité et évaluer la qualité d'un produit / service.

3.5 Fondements théoriques de l'analyse FMEA.

3.6 Fondements théoriques de la construction du schéma d'Ishikawa.

3.7 Fondements théoriques pour la construction d'un diagramme de Pareto.

3.8 caractéristiques générales Concepts de fabrication au plus juste

3.9 Base théorique pour l'application de la méthode Poka-Yoke

Partie pratique

1 . Brève description de l'entreprise . Donnez une description de l'entreprise, y compris les informations suivantes : historique, structure organisationnelle, activités, gamme et caractéristiques des produits/services fournis, informations sur le système de gestion de la qualité (le cas échéant), description de la ou des unités traitant des questions de qualité , perspectives et stratégie de développement).

2 . Mission d'entreprise. Formuler la mission de l'entreprise sélectionnée.

3. Les objectifs de l'entreprise.

3.1 Conception structure hiérarchique objectifs, selon structure organisationnelle, indiquant les objectifs de croissance de l'entreprise, conformément aux exigences clés. Spécifiez les exécuteurs responsables de la division entreprise pour la mise en œuvre de ces objectifs. Enregistrez les résultats dans le tableau 1.

Tableau 1. Matrice des objectifs de l'entreprise

3.2 Construire un arbre d'objectifs pour une durée d'un an, face à la direction de l'entreprise pour mener à bien la mission (Figure 1).

Riz. 1 Représentation structurelle simplifiée de l'arbre d'objectifs

4. Analyse SWOT/PEST

Effectuez une analyse SWOT (ou PEST, au choix) de l'entreprise. Remplissez la matrice appropriée en fonction des résultats de l'analyse.

Formuler des conclusions sur la base des résultats de l'analyse. Élaborer des recommandations pour l'entreprise en fonction des résultats de l'analyse.

5. Caractéristiques des paramètres de qualité du produit/service.

Sélectionnez un produit/service à analyser. Décrivez la liste des paramètres de qualité du produit (service) et les exigences pour ceux-ci.

6.Analyse AMDE

Pour compléter cette section, les informations sur le produit/service sélectionné dans la section 5 sont utilisées.

6.1 Déterminer la liste des défauts potentiels (incohérences) du produit (service) sélectionné à la section 5. Pour chaque défaut potentiel, définissez une liste de conséquences. Déterminer l'indicateur complexe S, qui caractérise le niveau global de toutes les conséquences de chaque défaut potentiel (non-conformité) pour le consommateur, sur une échelle de 10 points (1 est le niveau minimum de conséquences ou leur absence, 10 est le niveau maximum de conséquences ).

6.2 Pour chaque défaut, identifier une liste de causes potentielles. Pour un défaut, plusieurs causes potentielles peuvent être identifiées. Pour chaque cause de défaut, déterminez O, la probabilité de son apparition, sur une échelle de 10 points (1 occurrence est peu probable, 10 occurrences est inévitable).

6.3 Pour chaque défaut potentiel et chaque cause potentielle, attribuez un score de détection de difficulté D sur une échelle de 10 points (10 est un défaut presque indétectable, 1 est un défaut détectable de manière fiable).

6.4. Pour chaque défaut potentiel et chaque cause potentielle, calculez le numéro de priorité de risque de RPD à l'aide de la formule (1). PHR peut prendre des valeurs de 1 à 1000. Remplissez le tableau 2.

PRR \u003d S * O * D (1)

RRR - numéro de risque prioritaire ;

S est le degré de conséquences d'un défaut potentiel ;

O - Probabilité d'occurrence

Tableau 2. Défauts potentiels (incohérences) du produit (service) ___________________

Nbre p/p		S Degré des conséquences sur une échelle de 10 points (1-niveau minimum, 10-maximum)		O Probabilité d'occurrence sur une échelle de 10 points (1 = peu probable, 10 = inévitable)	D Difficulté de détection sur une échelle de 10 points (10 - défaut pratiquement indétectable, 1 - défaut détectable de manière fiable).	HCR
	1.1		1.1.1
1.1.2
…
1.2 …		1.2.1
1.2.2
…
…		..
..
…
	2.1		2.1.1
2.1.2
…
2.2		2.2.1
2.2.2
…
…		..
..
…
…

6.5 Faites une liste des défauts/raisons pour lesquels la valeur RFR dépasse 100 (le niveau RFR maximum autorisé).

6.6 Pour la liste que vous avez compilée, développez des actions préventives qui incluent :

Mesures pour réduire le degré de conséquences du défaut (incohérence) S ;

Mesures pour prévenir les causes de non-conformité potentielle O ;

Mesures pour augmenter le degré de fiabilité de la détection des défauts D ;

Compléter le tableau 3.

Tableau 3. Mesures de prévention des défauts potentiels dont le FFR dépasse 100 (valeur admissible).

Nbre p/p	Défauts potentiels (incohérences)	Liste des conséquences potentielles d'un défaut (non-conformité)	Causes potentielles du défaut (non-conformité)	HCR	Mesures préventives
Mesures pour réduire le degré de conséquences du défaut (non-conformité) S	Mesures pour prévenir les causes de non-conformité potentielle O	Mesures pour augmenter le degré de fiabilité de la détection des défauts D
	1.1		1.1.1
1.1.2
…
1.2 …		1.2.1
1.2.2
…
…		..
..
…
	2.1		2.1.1
2.1.2
…
2.2		2.2.1
2.2.2
…
…		..
..
…
…

7."Méthodes simples" de management de la qualité (schéma d'Ishikawa, diagramme de Pareto).

Schéma d'Ishikawa

Procéder à une analyse des raisons du mariage du produit/service sélectionné. Compléter le tableau 5.

Tableau 4. Raisons du produit/service défectueux ___________________

Catégories de causes	Causes du 1er ordre	Causes du 2ème ordre	raisons de 3ème ordre
1.	1.1	1.1.1	1.1.1.1
1.1.12
1.1.1.3
1.1.2	1.1.2.1
1.1.2.2
1.1.2.3
1.1.3	1.1.3.1
1.1.3.2
1.1.3.3
…	…
1.2	1.2.1	1.2.1.1
1.2.1.2
1.2.1.3
1.2.2	1.2.2.1
1.2.2.2
1.2.2.3
1.2.3	1.2.3.1
1.2.3.2
1.2.3.3
…	…
1.3	1.3.1	1.3.1.1
1.3.1.2
1.3.1.3
1.3.2	1.3.2.1
1.3.2.2
1.3.2.3
1.3.3	1.3.3.1
1.3.3.2
1.3.3.3
…	…
…

Construisez le diagramme d'Ishikawa en y affichant les données du tableau 4.

Tirer et décrire des conclusions basées sur les résultats de son analyse.

diagramme de Pareto

7.2.1 Effectuez une analyse du schéma d'Ishikawa à l'aide du diagramme de Pareto - sélectionnez les causes les plus importantes conduisant à 80 % du produit / service défectueux sur lequel vous devez vous concentrer. Pour ce faire, vous devez créer le tableau 5. La base de construction du tableau 5 est la dernière colonne du tableau 4 - les raisons du dernier (2e, 3e ... n-ième ordre, identifiées dans l'analyse des raisons de le produit/service défectueux)

Tableau 5. Raisons des produits/services défectueux ___________________

	Évaluation de chaque cause sur une échelle de 10 points en fonction de son degré d'influence sur le règlement du mariage (10 est le degré maximum, 1 est le degré minimum)
1.1.1.1
1.1.12
1.1.1.3
1.1.2.1
1.1.2.2
1.1.2.3
1.1.3.1
1.1.3.2
1.1.3.3
…
1.2.1.1
1.2.1.2
1.2.1.3
1.2.2.1
1.2.2.2
1.2.2.3
1.2.3.1
1.2.3.2
1.2.3.3
…
1.3.1.1
1.3.1.2
1.3.1.3
1.3.2.1
1.3.2.2
1.3.2.3
1.3.3.1
1.3.3.2
1.3.3.3
…

Tableau 6. Données pour la construction d'un diagramme de Pareto lors de l'analyse des défauts du produit / service ___________________

Causes de la nième (dernière) commande	Évaluation de chaque cause sur une échelle de 10 points (du tableau 4), classée par ordre décroissant d'importance	Poids (importance) de chaque raison, %	Poids cumulé (importance) de chaque cause, %
1.1.1.1
1.1.12
1.1.1.3
1.1.2.1
1.1.2.2
1.1.2.3
1.1.3.1
1.1.3.2
1.1.3.3
…
1.2.1.1
1.2.1.2
1.2.1.3
1.2.2.1
1.2.2.2
1.2.2.3
1.2.3.1
1.2.3.2
1.2.3.3
…
1.3.1.1
1.3.1.2
1.3.1.3
1.3.2.1
1.3.2.2
1.3.2.3
1.3.3.1
1.3.3.2
1.3.3.3
…
TOTAL		100%

7.2.3 Construisez un diagramme de Pareto selon le tableau 6, déterminez graphiquement les raisons qui causent 80% du mariage.

Analysez le diagramme de Pareto, tirez des conclusions. Développer des actions correctives/préventives pour éliminer/prévenir chacune des causes.

Application de la méthodologie Poka-Yoke (Lean Manufacturing Concept)

Pour remplir ce paragraphe, la liste des défauts/raisons formée à la clause 6.5 est utilisée, pour lesquels la valeur du RFR dépasse 100 (le niveau maximal autorisé du RFR), ainsi que partiellement - les données des tableaux 2 et 3.

8.1 Hiérarchiser les problèmes - les classer en fonction du niveau estimé de HFR

8.2 Remplir le tableau 7.

Tableau 7. Application de la méthodologie Poka-Yoke pour se prémunir contre une éventuelle non-conformité avec le niveau de HFR>100

Conclusion(0,5 - 1 page).

Dans la section Ressources, la présentation « L'ABC du Lean Manufacturing. Qu'est-ce que le poka-yoke. Les poka-yoke (ou poka-yoke) sont des dispositifs ou des procédures qui empêchent les défauts dans les processus de fabrication. La présentation donne une définition, énumère les types d'erreurs humaines et les sources de défauts, et donne plusieurs exemples.

Ci-dessous, dans le texte de la note se trouve le texte d'accompagnement.

De plus, cette présentation en format vidéo avec mes commentaires est publiée sur Youtube.com et Rutube.ru.

Je vous demande de faire part de vos commentaires et suggestions sur les sites youtube et rutube, directement sur la page vidéo, ou via le formulaire sur mon site, afin que je puisse les prendre en compte à l'avenir.

Transcription du texte d'accompagnement

Poka-yoke (qui signifie "protection contre les erreurs" en japonais) sont des dispositifs ou des procédures qui empêchent les défauts de se produire dans les processus de fabrication.

Regardons quelques exemples.

Exemple 1. La forme du produit est telle qu'il ne peut pas être installé pour le traitement ou utilisé dans la mauvaise position (à l'envers ou à l'envers). Vous voyez une disquette de trois pouces qui ne peut être insérée complètement dans le lecteur que dans une seule position.

Exemple #2. Une cellule photoélectrique qui se déclenche si une personne franchit (ou vice versa - ne franchit pas) une ligne de contrôle invisible. Par exemple, l'assembleur doit nécessairement prendre et utiliser une certaine pièce.

Les défauts sont dus à une erreur humaine.

Il existe 10 types d'erreurs humaines qui conduisent à des défauts. Ce:

l'oubli,
incompréhension des raisons (occurrence de quelque chose)
sous-estimation de toute situation (ou incapacité à identifier un objet)
inexpérience
réticence (à suivre les procédures et les règles)
négligence
lenteur (à prendre une décision)
manque de normes
surprendre
commettre intentionnellement une erreur (ou un sabotage)

Les sources de défauts sont les faits suivants :

opération manquée
erreurs de traitement
erreurs de position de pièce
détail manquant
élément erroné
manipuler la mauvaise pièce
opération incorrecte sur la bonne pièce
erreurs de configuration
mauvaise installation de l'équipement et
utiliser le mauvais outil ou outil

Prenons un exemple de résolution du problème.

Le problème réside dans les détails bruts. Solution qui a été appliquée : changer la goulotte pour identifier les pièces défectueuses.

Regardez le dessin.

Les pièces moulées sont traitées sur une machine automatique et transférées au processus suivant par une goulotte.

Avant l'amélioration, il se produisait ce qui suit : si une pièce non finie passe dans la goulotte, la machine suivante du processus s'arrête anormalement et peut être endommagée.

Pour arrêter une pièce brute, une méthode a été développée qui prend en compte la différence de sa forme géométrique par rapport à la pièce usinée. La goulotte a été modifiée pour que la pièce non finie s'arrête dans le bloc installé dans la goulotte et ne passe pas à la machine suivante. Cela a permis d'éviter les pannes de machines.

3. Le concept de la méthode bye-bye

La fabrication sans défaut est basée sur une méthode anti-erreur appelée Poka-Yoke. Le système « Poka-eka » peut être traduit en russe par « infaillible ».

L'idée de base est d'arrêter le processus dès qu'un défaut est trouvé, d'en déterminer la cause et d'empêcher que la source du défaut ne se reproduise. Par conséquent, aucun échantillonnage statistique n'est requis. Un élément clé de la procédure est que l'inspection de la source de l'erreur est effectuée en tant que partie active du processus de fabrication afin de détecter les erreurs avant qu'elles ne deviennent des défauts. La découverte d'une erreur arrête la production jusqu'à ce qu'elle soit corrigée ou le processus est corrigé pour empêcher que le défaut ne se produise. Cela se fait à chaque étape du processus en surveillant les sources d'erreurs potentielles. De cette façon, les défauts sont identifiés et corrigés à leur source même, et non à des stades ultérieurs. Naturellement, ce processus a été rendu possible par l'utilisation d'outils et de mécanismes à rétroaction immédiate (dans le processus, l'utilisation de personnel est évitée en raison de sa capacité à faire des erreurs). Cependant, l'utilisation de personnel est essentielle pour identifier les sources potentielles d'erreur. À l'âge de 40 ans, Shingo a appris et utilisé dans une large mesure Méthodes statistiques contrôle de qualité, mais après 20 ans, en 1977, il a dit qu'il s'était enfin libéré de leur charme de sorcellerie. Cela s'est produit lorsqu'il a observé de ses propres yeux comment la chaîne de montage tuyaux de vidangeà l'usine machines à laver Matsushita à Shizuoka, qui employait 23 travailleurs, a réussi à fonctionner en continu sans un seul défaut pendant un mois, grâce à l'installation de dispositifs Poka-Yeke qui ont empêché les défauts. Shingo affirme que l'absence de défauts peut être obtenue en utilisant le contrôle de la source des défauts et le système Poka-Yeke. Ensemble, ils constituent "Zero Quality Control".

Ce concept de "zéro défaut" est différent de ce qui est habituellement associé au nom du mentor américain Philip Crosby. Le concept de Shingo met l'accent sur l'atteinte de zéro défaut grâce à l'utilisation de bonnes formation d'ingénieur la recherche sur la production et les procédés, plutôt qu'à travers les slogans et les slogans associés aux campagnes de qualité des entreprises américaines et d'Europe occidentale. Shingo lui-même, comme Deming et Juran, s'inquiète de cette approche américaine, arguant que la publication de statistiques sur les défauts n'est que trompeuse et qu'il faut plutôt rechercher les éléments défectueux du processus de production qui causent la plupart des défauts du produit.

Le système poka-eka est la base d'une production sans défaut.

Les défauts de fabrication sont principalement dus à une variabilité accrue des caractéristiques du processus, qui, à son tour, peut être le résultat de :

¾ normes mal élaborées ou procédures documentées;

¾ utilisation d'équipements de mauvaise qualité ou obsolètes ;

¾ utilisation de matériaux inadaptés ;

Usure de l'outil aux ¾ ;

¾ erreurs d'opérateur.

Pour toutes ces causes de défauts, à l'exception de la dernière, des actions correctives et préventives peuvent être appliquées. Il est assez difficile d'éviter les erreurs de l'opérateur.

Au cœur de l'idéologie poke-eka se trouve le fait qu'il est naturel pour les gens de faire des erreurs dans le processus de travail. Et ce n'est pas un indicateur de manque de professionnalisme de l'opérateur. Le but du poke-ek est de trouver des moyens de se protéger contre les erreurs involontaires. La liste des actions typiques des opérateurs conduisant à l'apparition de défauts est présentée dans le tableau.

La méthode poke-eka repose sur sept principes :

1 utiliser une conception robuste pour créer des processus efficaces ;

2 travailler en équipe : c'est le seul moyen de valoriser le savoir-faire des collaborateurs ;

3 éliminer les erreurs, en utilisant également une conception robuste : cela rapprochera le nombre d'erreurs de zéro ;

4 éliminer les causes profondes des défauts en appliquant la méthode des 5 "Pourquoi" (Cinq "pourquoi");

5 agir immédiatement, utiliser toutes les ressources possibles ;

6 éliminer les activités qui n'ajoutent pas de valeur ;

7 mettre en œuvre des améliorations et penser immédiatement à d'autres améliorations.

Poké-eka ne compte pas sur les opérateurs eux-mêmes pour trouver l'erreur. Par conséquent, lorsqu'ils effectuent un travail, ils utilisent capteurs tactiles et autres appareils. Cela aide à identifier efficacement les défauts négligés par les opérateurs.

La méthode poke-eka doit être appliquée à la fois au contrôle d'entrée et pendant tout le processus. L'effet de sa mise en œuvre dépend de l'étape à laquelle du processus - contrôle des entrées ou contrôle en cours de processus - cette méthode a été utilisée. Dans le même temps, si des incohérences ont été identifiées, des signaux d'avertissement sont reçus ou même l'équipement peut être arrêté.

L'introduction de la méthode poke-eka au contrôle d'entrée est appelée l'approche proactive. La détection d'erreur dans ce cas se produira avant que certaines opérations aient été effectuées, que des signaux d'avertissement soient utilisés ou même que l'équipement puisse être arrêté au niveau de la commande de sortie.

L'approche dans laquelle la méthode poke-eka est appliquée à d'autres étapes du processus de production est appelée réactive. Dans ce cas, cette méthode est utilisée :

¾ dès la fin du processus ;

¾ pendant l'exécution des travaux par l'opérateur ;

¾ lors du transfert vers étape suivante traiter.

L'approche réactive est efficace car elle permet d'éviter le transfert de produits défectueux vers l'étape suivante du processus, mais, néanmoins, ne permet pas d'atteindre un tel haut degré protection contre les erreurs, comme dans le cas d'une approche proactive. L'utilisation de méthodes poke-eka dans le processus de recherche des causes des défauts ne donne pas de résultats élevés, mais en même temps, elle est beaucoup plus efficace que le contrôle sélectif.

Il existe d'autres approches pour utiliser la méthode poke-eka : le contrôle et l'avertissement. Avec une approche de contrôle, si un défaut est détecté, l'équipement s'arrête automatiquement. L'approche préventive repose sur l'utilisation de divers moyens de signalisation (signaux lumineux et sonores) qui informent l'opérateur d'une éventuelle erreur. L'arrêt de l'équipement ne fait souvent pas partie de l'option d'approche préventive.

Les appareils utilisés dans les poke-eka, selon la méthode qui sous-tend leur travail, sont divisés en :

contact ¾ ;

¾ de lecture ;

¾ de mouvement consécutif.

Les trois types de dispositifs peuvent être utilisés à la fois dans une approche de contrôle et dans une approche d'avertissement.

Le principe de fonctionnement des dispositifs à méthode de contact est basé sur la détermination si l'élément sensible est en contact avec l'objet testé. Les interrupteurs de fin de course sont un exemple de tels dispositifs. Si le contact est rompu, alors, par exemple, un signal sonore est déclenché.

En outre, les dispositifs fonctionnant par la méthode de contact comprennent les émetteurs et récepteurs, les commutateurs photoélectriques, les capteurs piézoélectriques, etc. Les dispositifs n'ont pas besoin d'être de haute technologie. Les appareils passifs simples sont parfois les meilleurs. Ils ne permettent pas aux pièces de prendre la mauvaise position pendant le processus.

Les lecteurs sont utilisés lorsqu'il y a un nombre fixe d'opérations dans un processus et un nombre fixe de pièces dans un produit. Le capteur compte les pièces plusieurs fois et ne passe la pièce au processus suivant que si le nombre de pièces est correct.

Le troisième type d'appareils sont des capteurs qui déterminent si une opération de traitement est terminée. Si l'opération n'est pas effectuée ou est effectuée de manière incorrecte, le capteur signale que l'équipement doit être arrêté. De nombreux dispositifs sensoriels et photoélectriques fonctionnent sur ce principe, qui sont associés à la minuterie de l'équipement. L'utilisation de tels dispositifs est plus efficace lorsque de nombreuses pièces de forme et de taille similaires sont utilisées dans le processus.

L'application cohérente de la méthode poke-eka peut réduire considérablement le nombre d'erreurs commises par les opérateurs, ce qui contribue à réduire les coûts et à accroître la satisfaction des clients.

4. Appliquer Poka-eka dans les organisations

Des techniques de prévention des erreurs, ou poke-yoka, sont appliquées pour empêcher les produits défectueux d'entrer dans l'étape suivante de la production. Pour éliminer les erreurs, il est nécessaire que le contrôle de la qualité du produit soit partie intégrante toute opération, et l'équipement était équipé de capteurs pour détecter les erreurs et arrêter le processus. La méthode de protection contre les erreurs, appliquée en combinaison avec d'autres outils de fabrication allégée, garantit que le produit est exempt de défauts et que le processus de production se déroule sans heurts.

Après l'introduction de l'approche bye-yeka, elle a été appliquée avec succès dans diverses usines, établissant un record de deux ans de fonctionnement sans défaut. En 1968, à la Saga Ironworks, Shingo a créé un système de pré-automatisation (système Pro-Automation), qui a ensuite été distribué dans tout le Japon.

Depuis 1975, Shigeo Shingo développe le concept du "zéro défaut" à l'usine de machines à laver Matsushita Electric à Shizuoka. A travaillé pour améliorer procédés technologiques basée sur des approches fondamentales, y compris la galvanoplastie à grande vitesse, le séchage instantané et l'absence de marquage. Ce concept est appliqué là et maintenant.

Figure - Utilisation des techniques de protection contre les erreurs

Si l'on regarde les résultats de l'enquête (Figure 2), on peut voir que 6% des répondants affirment que leurs entreprises ont atteint le niveau mondial dans le domaine de la protection contre les erreurs (l'enquête a été menée par PalmTree, Inc., une société de conseil société dédiée à la promotion et au déploiement du concept de lean manufacturing, début 2003 parmi les membres de l'Illinois Manufacturers Association (USA)). Parmi ces 6% se trouve Northrop Grumman Corp. - fabricant tubes à rayons cathodiques. Selon le représentant de l'entreprise, E. Schaudt, de tels succès ont été obtenus grâce à travail quotidien, au cours de laquelle l'activité de chaque ouvrier de l'atelier est évaluée selon de nombreux paramètres, à savoir : respect du planning, niveau de qualité, réduction des défauts et autres paramètres mesurables de la production au plus juste. Étant donné que le concept de fabrication au plus juste fait partie intégrante de la vie quotidienne activités de production, tous les employés sont conscients que plus ils sont performants sur l'une de ces dimensions, meilleure est leur situation financière et plus d'opportunités de carrière.

Le système poka-eka est également utilisé dans la société japonaise Omron. Cette société coopère avec succès avec des entreprises russes. Parmi ceux qui utilisent aujourd'hui l'automatisation Omron figurent KamAZ JSC et AvtoVAZ JSC, l'usine métallurgique Cherepovets Severstal et l'usine métallurgique de Sibérie occidentale, la centrale hydroélectrique de Krasnoïarsk et NPO Energia. Le processus de production chez Omron est automatisé à un point tel qu'il exclut pratiquement la participation d'une personne, dont les actions peuvent le plus souvent provoquer un mariage. C'est pourquoi l'entreprise parvient à travailler selon le principe : zéro défaut, 100 % contrôle et 100 % fiabilité. Les deux usines européennes de la société, situées en Allemagne et aux Pays-Bas, disposent d'un certificat de conformité de leurs systèmes qualité aux normes internationales de la série ISO 9000.

Liste de la littérature utilisée

1 Rampersad Hubert K. Gestion générale de la qualité : changements personnels et organisationnels / Per. de l'anglais. - M. : CJSC "Olimp-Business", 2005. - 256 p.

2 //Le Japon aujourd'hui. Management Guru (article sur Shigeo Shingo)

3 http://www.certicom.kiev.ua/index.html

4 // Méthodes de Management de la Qualité, n°9, 2005 "La Prévention des Erreurs, ou Poké Yoka", p.42

Traduction

Salut tout le monde! Je suis Aleksey Grezov, développeur de Server Team Badoo. Chez Badoo, nous essayons toujours de rendre notre code facile à maintenir, à développer et à réutiliser, car ces paramètres déterminent la rapidité et l'efficacité avec lesquelles nous pouvons implémenter n'importe quelle fonctionnalité. Une façon d'atteindre cet objectif est d'écrire du code qui ne vous laissera tout simplement pas faire d'erreur. L'interface la plus stricte ne vous permettra pas de vous tromper dans l'ordre de son appel. Montant minimal états internes garantit les résultats attendus. L'autre jour, j'ai vu un article qui décrit simplement comment l'application de ces méthodes facilite la vie des développeurs. Alors, je porte à votre attention la traduction de l'article sur le principe "poka-yoke".

À travail conjoint avec du code dans une équipe moyenne ou grande, il est parfois difficile de comprendre et d'utiliser le code de quelqu'un d'autre. Ce problème a diverses solutions. Par exemple, vous pouvez accepter de suivre certaines normes de codage ou d'utiliser un cadre connu de toute l'équipe. Cependant, cela ne suffit souvent pas, en particulier lorsque vous devez corriger un bogue ou ajouter une nouvelle fonctionnalité à un ancien code. Il est difficile de se rappeler pour quelles classes spécifiques ont été conçues et comment elles devraient fonctionner à la fois individuellement et ensemble. À de tels moments, vous pouvez accidentellement ajouter Effets secondaires ou des erreurs sans même s'en rendre compte.

Ces bogues peuvent être détectés lors des tests, mais il y a de fortes chances qu'ils se glissent dans la production. Et même s'ils sont trouvés, cela peut prendre beaucoup de temps pour annuler le code et le réparer.

Alors, comment pouvons-nous empêcher cela? Avec l'aide du principe "poka-yoke".

Qu'est-ce que le poka yoke ?

Poka-yoke est un terme japonais qui se traduit en anglais par « anti-erreur » (protection contre les erreurs), et en russe, il est mieux connu sous le nom de « protection contre les imbéciles ». Le concept trouve son origine dans la fabrication au plus juste, où il fait référence à tout mécanisme qui aide l'opérateur d'une machine à éviter de faire des erreurs.

En dehors de la fabrication, le poka-yoke est souvent utilisé dans l'électronique grand public. Prenons, par exemple, une carte SIM qui, en raison de sa forme asymétrique, ne peut être insérée dans l'adaptateur que par le côté droit.

L'exemple opposé (sans utiliser le principe poka-yoke) est le port PS / 2, qui a la même forme de connecteur pour le clavier et la souris. Ils ne se distinguent que par leur couleur et sont donc facilement confondus.

Un autre concept de poka-yoke peut être utilisé dans la programmation. L'idée est de rendre les interfaces publiques de notre code les plus simples et claires possibles et de générer des erreurs dès que le code est mal utilisé. Cela peut sembler évident, mais en fait, nous rencontrons souvent du code qui n'en a pas.

Veuillez noter que poka-yoke n'est pas destiné à prévenir les abus intentionnels. Le but est uniquement d'éviter les erreurs accidentelles, pas de protéger le code d'une utilisation malveillante. D'une manière ou d'une autre, tant que quelqu'un a accès à votre code, il peut toujours contourner les fusibles s'il le souhaite vraiment.

Avant de discuter des mesures spécifiques pour rendre le code plus résistant aux erreurs, il est important de savoir que les mécanismes poka-yoke peuvent être divisés en deux catégories :

prévention des erreurs
détection d'erreur.

Les mécanismes de prévention des erreurs sont utiles pour éliminer les erreurs à un stade précoce. En simplifiant au maximum les interfaces et les comportements, nous nous assurons que personne ne puisse accidentellement abuser de notre code (pensez à l'exemple de la carte SIM).

D'autre part, les mécanismes de détection d'erreurs sont en dehors de notre code. Ils contrôlent nos applications pour suivre erreurs possibles et prévenez-nous à leur sujet. Un exemple serait Logiciel, qui détermine si le périphérique connecté au port PS/2 est du type correct et, si ce n'est pas le cas, indique à l'utilisateur pourquoi il ne fonctionne pas. Un tel logiciel ne pourrait pas empêcher erreur parce que les connecteurs sont les mêmes, mais cela peut découvrir elle et signalez-le.

Dans ce qui suit, nous examinerons quelques techniques que nous pouvons utiliser pour prévenir et détecter les bogues dans nos applications. Mais gardez à l'esprit que cette liste n'est qu'un point de départ. Selon l'application spécifique, des mesures supplémentaires peuvent être prises pour rendre le code plus résistant aux erreurs. Il est également important de s'assurer que cela vaut la peine d'implémenter poka-yoke dans votre projet : selon la complexité et la taille de votre application, certaines mesures peuvent être trop coûteuses par rapport au coût potentiel des erreurs. Par conséquent, c'est à vous et à votre équipe de décider quelles mesures vous conviennent le mieux.

Exemples de prévention des erreurs

Déclaration de type

Anciennement connues sous le nom de Type Hinting en PHP 5, les déclarations de type sont un moyen simple de se protéger contre les erreurs lors de l'appel de fonctions et de méthodes en PHP 7. En attribuant des types spécifiques aux arguments de fonction, il devient plus difficile de modifier l'ordre des arguments lors de l'appel. fonction.

Par exemple, considérons une notification que nous pouvons envoyer à un utilisateur :

userId = $userId ; $this->sujet = $sujet ; $this->message = $message; ) public function getUserId() ( return $this->userId; ) public function getSubject() ( return $this->subject; ) public function getMessage() ( return $this->message; ) )

Sans déclaration de type, vous pouvez accidentellement transmettre des variables du mauvais type, ce qui peut casser votre application. Par exemple, nous pourrions supposer que $userId devrait être une chaîne alors qu'en fait il pourrait s'agir d'un int .

Si nous passons le mauvais type au constructeur, l'erreur passera probablement inaperçue jusqu'à ce que l'application essaie de faire quelque chose avec cette notification. Et à ce stade, très probablement, nous recevrons une sorte de message d'erreur crypté dans lequel rien ne pointera vers notre code, où nous transmettons string au lieu de int . Par conséquent, il est généralement préférable de faire en sorte que l'application s'arrête le plus tôt possible afin de détecter de telles erreurs le plus tôt possible lors du développement.

Dans ce cas particulier, nous pouvons simplement ajouter une déclaration de type - PHP s'arrêtera et nous avertira immédiatement avec une erreur fatale dès que nous essaierons de passer un paramètre du mauvais type :

userId = $userId ; $this->sujet = $sujet ; $this->message = $message; ) public function getUserId() : int ( return $this->userId; ) public function getSubject() : string ( return $this->subject; ) public function getMessage() : string ( return $this->message; ) )

Notez que par défaut, PHP tentera de convertir les arguments invalides en leurs types attendus. Pour éviter cela et générer une erreur fatale, il est important d'activer le typage strict (strict_types). Pour cette raison, déclarer des types scalaires n'est pas la forme idéale de poka-yoke, mais c'est un bon point de départ pour réduire les bogues. Même avec le typage fort désactivé, les déclarations de type peuvent toujours servir d'indication du type attendu pour un argument.

De plus, nous avons déclaré des types de retour pour nos méthodes. Cela permet de déterminer plus facilement les valeurs auxquelles nous pouvons nous attendre lors de l'appel d'une fonction particulière.

Des types de retour bien définis sont également utiles pour éviter plusieurs instructions switch lorsqu'il s'agit de valeurs de retour, car sans types de retour explicitement déclarés, nos méthodes peuvent retourner différents types. Par conséquent, une personne utilisant nos méthodes devra vérifier quel type a été renvoyé dans un cas particulier. Évidemment, vous pouvez oublier les instructions switch, qui entraîneront des erreurs difficiles à détecter. Mais ils deviennent beaucoup moins courants lors de la déclaration du type de retour d'une fonction.

Objets de valeur

Le problème que les déclarations de type ne peuvent pas résoudre est que le fait d'avoir plusieurs arguments pour une fonction leur permet de mélanger leur ordre lorsqu'elles sont appelées.

Lorsque les arguments sont de types différents, PHP peut nous avertir des arguments dans le désordre, mais cela ne fonctionnera pas si nous avons plusieurs arguments du même type.

Pour éviter les erreurs dans ce cas, nous pourrions envelopper nos arguments dans des objets de valeur :

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 ( /* ... */ ) fonction publique getSubject() : Objet ( /* ... */ ) fonction publique getMessage() : Message ( /* ... */ ) )

Parce que nos arguments sont maintenant d'un type très spécifique, il est presque impossible de les mélanger.

Un avantage supplémentaire de l'utilisation d'objets de valeur par rapport à la déclaration de types scalaires est que nous n'avons plus besoin d'inclure un typage fort dans chaque fichier. Et si nous n'avons pas besoin de nous en souvenir, alors nous ne pourrons pas l'oublier.

Validation

Lorsque vous travaillez avec des objets de valeur, nous pouvons encapsuler notre logique de validation des données dans les objets eux-mêmes. De cette façon, nous pouvons empêcher la création d'un objet de valeur avec un état invalide, ce qui peut entraîner des problèmes à l'avenir dans d'autres couches de notre application.

Par exemple, nous pourrions avoir une règle selon laquelle tout UserId doit toujours être positif. Nous pourrions évidemment le vérifier chaque fois que nous obtenons un UserId en entrée, mais d'un autre côté, il peut aussi être facilement oublié à un endroit ou à un autre. Et même si cet oubli conduit à une erreur réelle dans une autre couche de notre application, il peut être difficile de comprendre à partir du message d'erreur ce qui s'est réellement passé, et cela rendra le débogage plus difficile.

Pour éviter des erreurs comme celle-ci, nous pourrions ajouter une validation au constructeur 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 ; ) fonction publique getValue() : int ( return $this->userId; ) )

Ainsi, nous pouvons toujours être sûrs que lorsque nous travaillons avec l'objet UserId, il a le bon état. Cela nous évitera d'avoir à vérifier constamment les données à différents niveaux de l'application.

Notez que nous pourrions ajouter une déclaration de type scalaire ici au lieu d'utiliser is_int , mais cela nous obligerait à inclure un typage fort partout où UserId est utilisé. Si cela n'est pas fait, PHP essaiera de convertir d'autres types en int chaque fois qu'ils sont passés en tant que UserId . Cela peut devenir un problème, car nous pourrions, par exemple, passer un float , qui pourrait ne pas être la bonne variable puisque les identifiants d'utilisateur ne sont généralement pas des flottants. Dans d'autres cas où nous pourrions, par exemple, travailler avec un objet Price, la désactivation du typage fort peut entraîner des erreurs d'arrondi car PHP convertit automatiquement les variables flottantes en int .

immutabilité

Par défaut, les objets en PHP sont passés par référence. Cela signifie que lorsque nous apportons des modifications à un objet, il change instantanément dans toute l'application.

Bien que cette approche ait ses avantages, elle présente également certains inconvénients. Prenons un exemple de notification envoyée à un utilisateur par SMS et e-mail :

interface NotificationSenderInterface ( public function send(Notification $notification); ) class SMSNotificationSender implémente NotificationSenderInterface ( public function send(Notification $notification) ( $this->cutNotificationLength($notification); // Envoyer un SMS... ) /** * */ fonction privée cutNotificationLength(Notification $notification) ( $message = $notification->getMessage(); $messageString = substr($message->getValue(), 160) ; $notification->setMessage(new Message($messageString) ); ) ) class EmailNotificationSender implémente NotificationSenderInterface ( public function send(Notification $notification) ( // Envoyer un e-mail ...) ) $smsNotificationSender = new SMSNotificationSender() ; $emailNotificationSender = new EmailNotificationSender(); $notification = new Notification(new UserId(17466), new Subject("Demo notification"), new Message("Très long message... plus de 160 caractères.")); $smsNotificationSender->envoyer($notification); $emailNotificationSender->envoyer($notification);

Étant donné que l'objet Notification est passé par référence, cela a un effet secondaire inattendu. Lors du raccourcissement de la longueur du message dans SMSNotificationSender , l'objet Notification associé a été mis à jour dans toute l'application afin que le message soit également tronqué lors de son envoi ultérieur à EmailNotificationSender .

Pour résoudre ce problème, rendons l'objet Notification immuable. Au lieu de fournir des méthodes définies pour y apporter des modifications, ajoutons des méthodes qui font une copie de la notification d'origine avant d'apporter ces modifications :

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() : Sujet ( /* ... */ ) 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; ) )

Désormais, lorsque nous apportons des modifications à la classe Notification, telles que la réduction de la longueur du message, elles ne s'appliquent plus à l'ensemble de l'application, ce qui permet d'éviter divers effets secondaires.

Notez cependant qu'en PHP, il est très difficile (voire impossible) de rendre un objet véritablement immuable. Mais afin de rendre notre code plus résistant aux erreurs, il suffira d'ajouter "immuable" avec des méthodes au lieu de méthodes set, puisque les utilisateurs de la classe n'auront plus besoin de se rappeler de cloner l'objet avant d'apporter des modifications.

Retourner des objets nuls

Parfois, nous rencontrons des fonctions et des méthodes qui peuvent renvoyer une valeur ou null . Et ces valeurs de retour nulles peuvent poser problème, car nous aurons presque toujours besoin de vérifier les valeurs nulles avant de pouvoir faire quoi que ce soit avec elles. Encore une fois, c'est facile à oublier.

Pour éviter d'avoir à vérifier les valeurs de retour, nous pourrions renvoyer des objets nuls à la place. Par exemple, nous pouvons avoir un ShoppingCart avec ou sans réduction :

interface Discount ( fonction publique applyTo(int $total); ) interface ShoppingCart ( fonction publique calculateTotal() : int; fonction publique getDiscount() : ?Remise; )

Lors du calcul du prix final du ShoppingCart, avant d'appeler la méthode applyTo, nous devons maintenant toujours vérifier si la fonction getDiscount() a renvoyé null ou une remise :

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

Si nous ne faisons pas cette vérification, nous aurons un avertissement PHP et/ou d'autres effets secondaires lorsque getDiscount() retournera null .

En revanche, ces vérifications peuvent être évitées si l'on retourne un objet nul lorsqu'aucune remise n'est donnée :

class ShoppingCart ( public function getDiscount() : Discount ( return !is_null($this->discount) ? $this->discount: new NoDiscount(); ) ) class NoDiscount implémente Discount ( public function applyTo(int $total) ( return $ total ; ) )

Désormais, lorsque nous appelons getDiscount() , nous obtenons toujours un objet Discount, même s'il n'y a pas de remise. De cette façon, nous pouvons appliquer la remise au total même s'il n'y en a pas et nous n'avons plus besoin de l'instruction if :

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

Dépendances facultatives

Pour les mêmes raisons que nous voulons éviter les valeurs de retour nulles, nous voulons également nous débarrasser des dépendances facultatives en rendant simplement toutes les dépendances requises.

Prenons par exemple la classe suivante :

class SomeService implémente LoggerAwareInterface ( public function setLogger(LoggerInterface $logger) ( /* ... */ ) public function doSomething() ( if ($this->logger) ( $this->logger->debug("... "); ) // faire quelque chose si ($this->logger) ( $this->logger->warning("..."); ) // etc... ) )

Il y a deux problèmes :

Nous devons constamment vérifier la présence du logger dans notre méthode doSomething().
Lors de la configuration de la classe SomeService dans notre conteneur de services, quelqu'un peut oublier de configurer l'enregistreur, ou peut même ne pas savoir que la classe a la capacité de le faire.

Nous pouvons simplifier le code en faisant de LoggerInterface une dépendance obligatoire :

class SomeService ( public function __construct(LoggerInterface $logger) ( /* ... */ ) public function doSomething() ( $this->logger->debug("..."); // faire quelque chose $this-> logger->warning("..."); //etc... ) )

Maintenant, notre interface publique est moins encombrante, et chaque fois que quelqu'un crée une nouvelle instance de SomeService , il sait que la classe nécessite une instance de LoggerInterface , et il n'y a donc aucun moyen d'oublier de le spécifier.

Nous avons également supprimé la nécessité de vérifier en permanence l'existence de l'enregistreur, ce qui rend doSomething() plus facile à comprendre et moins sujet aux erreurs chaque fois que quelqu'un y apporte des modifications.

Si nous voulions utiliser SomeService sans logger, nous pourrions appliquer la même logique qu'avec le retour d'un objet null :

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

Au final, cette approche a le même effet que l'utilisation de la méthode optionnelle setLogger(), mais elle simplifie notre code et réduit la possibilité d'erreurs dans le conteneur d'injection de dépendance.

Méthodes publiques

Pour faciliter l'utilisation du code, il est préférable de limiter le nombre de méthodes publiques dans les classes. Ensuite, le code devient moins obscur et nous sommes moins susceptibles d'abandonner la rétrocompatibilité lors de la refactorisation.

Pour réduire au minimum le nombre de méthodes publiques, l'analogie avec les transactions sera utile. Considérons, par exemple, le transfert d'argent entre deux comptes bancaires :

$compte1->retirer(100); $compte2->dépôt(100);

Bien que la base de données, par le biais d'une transaction, puisse s'assurer que le retrait est annulé si le dépôt ne peut pas être effectué (ou vice versa), elle ne peut pas nous empêcher d'oublier d'appeler soit $account1->withdraw() soit $account2->deposit( ) , ce qui entraînerait un fonctionnement incorrect.

Heureusement, nous pouvons facilement résoudre ce problème en remplaçant les deux méthodes distinctes par une seule transactionnelle :

$compte1->transfert(100, $compte2);

De ce fait, notre code devient plus fiable, puisqu'il sera plus difficile de se tromper en réalisant partiellement une transaction.

Exemples de détection d'erreurs

Les mécanismes de détection des erreurs ne sont pas conçus pour les empêcher. Ils ne doivent nous alerter des problèmes que lorsqu'ils sont découverts. La plupart du temps, ils sont en dehors de notre application et vérifient le code à intervalles réguliers ou après des modifications spécifiques.

Tests unitaires

Les tests unitaires peuvent être un excellent moyen de s'assurer que le nouveau code fonctionne correctement. Ils aident également à s'assurer que le code fonctionne toujours correctement après que quelqu'un a refactorisé une partie du système.

Parce que quelqu'un pourrait oublier de faire des tests unitaires, c'est une bonne idée d'exécuter automatiquement des tests lorsque des modifications sont apportées à l'aide de services tels que Travis CI et GitLab CI. Grâce à eux, les développeurs sont avertis en cas de panne, ce qui permet également de s'assurer que les modifications apportées fonctionnent comme prévu.

En plus d'attraper des bogues, les tests unitaires sont d'excellents exemples d'utilisation de morceaux de code spécifiques, qui à leur tour empêchent les bogues lorsque quelqu'un d'autre utilise notre code.

Rapports de couverture de code et tests de mutation

Comme nous pouvons oublier d'écrire suffisamment de tests, il est utile lors des tests de générer automatiquement des rapports de couverture de code à l'aide de services tels que Coveralls . Chaque fois que notre couverture de code diminue, Coveralls nous envoie une notification afin que nous puissions ajouter les tests manquants. Grâce à Coveralls, nous pouvons également comprendre comment la couverture du code évolue dans le temps.

Une autre façon de s'assurer que nous avons suffisamment de tests unitaires consiste à utiliser des tests de mutation, comme avec Humbug . Comme leur nom l'indique, ils vérifient si notre code est suffisamment couvert par des tests en modifiant légèrement le code source puis en exécutant des tests unitaires, ce qui devrait générer des erreurs dues aux modifications apportées.

À l'aide de rapports de couverture de code et de tests de mutation, nous pouvons nous assurer que nos tests unitaires sont suffisants pour éviter les bogues.

Analyseurs de code statique

Les analyseurs de code peuvent détecter les bogues dans notre application au début du processus de développement. Par exemple, les IDE comme PhpStorm utilisent des analyseurs de code pour nous avertir des erreurs et nous donner des indices lorsque nous écrivons du code. Les erreurs peuvent aller de simples erreurs de syntaxe à du code répétitif.

En plus des analyseurs intégrés à la plupart des IDE, des analyseurs tiers et même personnalisés peuvent être inclus dans le processus de construction de nos applications pour identifier des problèmes spécifiques. Une liste partielle des analyseurs adaptés aux projets PHP est disponible sur GitHub.

Enregistrement

Contrairement à la plupart des autres mécanismes de détection d'erreurs, la journalisation peut aider à détecter les erreurs dans une application lorsqu'elle s'exécute en production.

Bien sûr, cela nécessite que le code écrive dans le journal chaque fois que quelque chose d'inattendu se produit. Même lorsque notre code prend en charge les enregistreurs, nous pouvons les oublier lors de la configuration de l'application. Par conséquent, les dépendances facultatives doivent être évitées (voir ci-dessus).

Bien que la plupart des applications conservent au moins une partie du journal, les informations qui y sont écrites deviennent vraiment intéressantes lorsqu'elles sont analysées et contrôlées à l'aide d'outils tels que Kibana ou Nagios. Ils peuvent donner une idée du type d'erreurs et d'avertissements que notre application reçoit lorsque les gens l'utilisent activement, et non lorsqu'elle est testée.

Ne pas supprimer les erreurs

Même lors de la journalisation des erreurs, il arrive que certaines d'entre elles soient supprimées. PHP a tendance à continuer à fonctionner lorsqu'une erreur "récupérable" se produit. Cependant, les bogues peuvent être utiles lors du développement ou du test de nouvelles fonctionnalités car ils peuvent indiquer des bogues dans votre code. C'est pourquoi la plupart des analyseurs de code vous avertissent lorsqu'ils détectent que vous utilisez @ pour la suppression des erreurs, car cela peut masquer des erreurs qui réapparaîtront inévitablement une fois l'application utilisée.

En règle générale, il est préférable de définir le niveau de notification d'erreurs de PHP sur E_ALL afin que le moindre avertissement soit signalé. Cependant, assurez-vous de consigner ces messages quelque part et de les masquer aux utilisateurs afin qu'aucune information sensible sur l'architecture de votre application ou sur les vulnérabilités potentielles ne soit disponible pour les utilisateurs finaux.

En plus de error_reporting , il est important de toujours inclure strict_types afin que PHP n'essaie pas de convertir automatiquement les arguments de la fonction en leur type attendu, car cela peut entraîner des erreurs difficiles à trouver (telles que des erreurs d'arrondi lors de la conversion de float en int) .

Utilisation en dehors de PHP

Comme le poka-yoke est plus un concept qu'une technique spécifique, il peut également être utilisé dans des domaines non PHP.

Infrastructure

Au niveau de l'infrastructure, de nombreux bogues peuvent être évités en créant un environnement de développement partagé identique à l'environnement de production à l'aide d'outils tels que Vagrant.

L'automatisation du déploiement d'applications à l'aide de serveurs de build tels que Jenkins et GoCD peut aider à éviter les erreurs lors du déploiement des modifications apportées à une application, car le processus peut impliquer de nombreuses étapes, dont certaines sont faciles à oublier.

API REST

Lors de la création d'une API REST, vous pouvez injecter poka-yoke pour faciliter l'utilisation de l'API. Par exemple, nous pouvons nous assurer de renvoyer une erreur chaque fois qu'un paramètre inconnu est passé dans l'URL ou le corps de la requête. Cela peut sembler étrange puisque nous voulons évidemment éviter de "casser" nos clients API, mais il est généralement préférable d'avertir les développeurs utilisant notre API d'une mauvaise utilisation dès que possible afin que les bogues puissent être corrigés tôt dans le processus de développement.

Par exemple, nous pourrions avoir un paramètre de couleur dans notre API, mais quelqu'un utilisant notre API pourrait accidentellement utiliser le paramètre de couleur. Sans aucun avertissement, ce bogue peut facilement entrer en production jusqu'à ce que les utilisateurs finaux le remarquent.

Pour apprendre à créer des API qui ne vous poseront aucun problème, lisez le livre Créer des API que vous ne détesterez pas.

Paramétrage des applications

Presque toutes les applications nécessitent une sorte de personnalisation. Le plus souvent, les développeurs fournissent autant de paramètres par défaut que possible, ce qui facilite la configuration. Cependant, comme dans l'exemple de couleur et de couleur, il est facile de mal saisir les paramètres de configuration, provoquant le retour inattendu de l'application aux valeurs par défaut.

De tels moments sont difficiles à retracer, car l'application ne déclenche pas d'erreur en tant que telle. Et la meilleure façon d'être averti lorsque la configuration est erronée est simplement de ne fournir aucune valeur par défaut et de générer une erreur dès que le paramètre de configuration est manquant.

Prévention des erreurs des utilisateurs

Le concept poka-yoke peut également être utilisé pour prévenir ou détecter les erreurs de l'utilisateur. Par exemple, dans un logiciel de comptabilité, le numéro de compte saisi par l'utilisateur peut être vérifié à l'aide d'un algorithme de chiffre de contrôle. Cela vous évitera d'entrer un numéro de compte mal orthographié.

Conclusion

Bien que poka-yoke ne soit qu'un concept et non un ensemble spécifique d'outils, il existe divers principes que nous pouvons appliquer à notre code et à notre processus de développement pour aider à prévenir les bugs ou à les détecter rapidement. Très souvent, ces mécanismes seront spécifiques à l'application elle-même et à sa logique métier, mais il existe quelques méthodes et outils simples qui peuvent être utilisés pour rendre n'importe quel code plus robuste.

La principale chose à retenir est que même si nous voulons éviter les bogues en production, ils peuvent être très utiles dans le processus de développement et nous ne devons pas avoir peur de les initier le plus tôt possible pour les rendre plus faciles à traquer. Ces erreurs peuvent être générées soit par le code lui-même, soit par des processus distincts qui s'exécutent séparément de l'application et la contrôlent de l'extérieur.

Pour réduire davantage le nombre d'erreurs, nous devons nous efforcer de garder les interfaces publiques de notre code aussi simples et claires que possible.

Mots clés:

PHP
indication de type
validation

Ajouter des balises