Est-ce une bonne pratique d'éviter les avertissements et les avis?
J'ai généralement travaillé avec PHP avertissements et notifications désactivés, car je travaille sur de nombreux projets où il est déjà en production en direct. Maintenant, si j'active les avertissements et les avis sur ces live sites de production, ils en seront surchargés.
Les projets sur lesquels je travaille à la maison, sur le local, j'essaie généralement de contourner TOUS les avertissements et notifications. Parfois, il n'y a pas de solution pour ne pas avoir d'avis, alors je devrais simplement m'occuper de consulter l'avis jusqu'à ce que je décide de les désactiver complètement.
En fin de compte, je ne sais pas si je perds mon temps à essayer de me débarrasser de tous les avertissements et avis, ou si je fais cela pour le plus grand bien.
D'où ma question: est-ce une bonne pratique d'éviter complètement les avertissements et les avis, ou est-ce vraiment sans importance?
si j'active les avertissements et les avis sur ces sites de production en direct, ils en seront surchargés.
Les avertissements doivent toujours être activés au niveau le plus complet dans le développement, les tests et l'assurance qualité, mais pas en production. En fait, s'il s'agit d'une application de dogfooding, c'est-à-dire une application que vous utilisez vous-même, vous devez également les activer en production.
Fondamentalement: faites-les allumer dans les cas où la personne qui les voit est en mesure de faire quelque chose à leur sujet (le développeur en développement et en test peut les corriger lui-même, le testeur en QA peut déposer un bogue, et si le développeur est également l'utilisateur, il peut également le réparer en production), mais ne pas les activer lorsque la personne qui voit ne peut rien faire eux (un utilisateur en production, qui ne sait même pas programmer).
Idéalement, vous voudrez également activer le traitement des avertissements comme des erreurs, mais cela ne fonctionne que s'il n'y en a pas pour commencer ;-) Mais gardez cela à l'esprit comme objectif! S'il est possible d'activer/désactiver cette fonction par fichier, activez-la pour tous les nouveaux fichiers et activez-la pour tous les fichiers sans avertissement et ne la désactivez jamais à nouveau une fois allumé.
Alors, que faire de la surcharge?
Vous établissez une liste de tous les avertissements et notifications, puis vous respectez les règles suivantes:
- Jamais, jamais, en aucun cas, n'ajoutez un nouvel avertissement à la liste. Chaque nouveau morceau de code, chaque modification, chaque modification, chaque correctif, chaque validation ne doit pas introduire de nouveaux avertissements, il ne peut que corriger leur.
- Chaque fois que vous touchez un morceau de code, corrigez tous les avertissements de ce morceau de code. (La règle Boyscout: laissez toujours le camping en meilleur état que vous ne l'avez trouvé.) De cette façon, le code non important peut rester plein d'avertissements, mais le code important deviendra plus propre avec le temps. "Morceau de code" peut être une fonction, une classe, un fichier. Vous pouvez également assouplir cette règle pour dire de corriger au moins un avertissement. L'important est de les réparer au fur et à mesure que vous les trouvez.
Remarque: ces deux éléments nécessitent la mise en place d'une sorte de base de données de journaux et d'un mécanisme de filtrage des journaux. Notez également que la "base de données des journaux" et le "mécanisme de filtrage des journaux" pourraient simplement être un fichier texte et grep.
C'est le bit important. Sans la base de données, vous ne saurez pas quand vous ajoutez un nouvel avertissement, et sans le filtrage, vous avez toujours le problème de surcharge.
Remarque n ° 2: cela ne fonctionne pas uniquement pour les avertissements, il fonctionne également pour les vérificateurs de style, les mesures de complexité, la couverture de code, les outils d'analyse statique, etc. Fondamentalement:
- N'ajoutez pas de nouveaux problèmes.
- Résolvez les anciens problèmes lorsque vous les rencontrez.
Cela vous permet de prioriser facilement: le code qui est édité souvent et doit donc être facile à lire et à entretenir, s'améliorera avec le temps. Un code qui n'est pas souvent touché ne s'améliorera pas, mais ça va, car personne n'a besoin de le regarder de toute façon. Et , au moins ça ne va pas empirer.
Bien sûr, rien ne vous empêche d'allouer du temps spécifiquement pour ne faire que traquer et tuer les avertissements. C'est juste que souvent, ce n'est pas économiquement viable, et c'est votre travail en tant qu'ingénieur de garder cela à l'esprit. "Un ingénieur est celui qui peut construire avec un dollar, ce que n'importe quel imbécile peut construire avec deux."
Si des avertissements et des notifications proviennent de votre code, résolvez-le définitivement. D'après mon expérience, dans 95% des cas, cela peut être bénin, mais les 5% mettent en évidence un vrai problème qui peut conduire à d'innombrables heures passées à courir.
S'ils proviennent du code tiers que vous devez utiliser pour une raison ou une autre, vous n'avez généralement pas beaucoup de choix.
C'est une question différente si votre base de code héritée est vraiment grande, vous pouvez alors traiter le code hérité comme tiers, mais exiger que le nouveau code soit sans avertissement.
Cela compte. Un avertissement pourrait ne pas casser vos tests ou même apparaître dans la nature pendant un certain temps - mais cela pourrait être le symptôme d'un bug imminent. Je développe actuellement principalement en C #/C++ et j'ai une stratégie définie pour se débarrasser et garder les avertissements hors de notre base de code. Heureusement, ce n'est pas sorcier =).
Si la langue dans laquelle vous travaillez a la capacité de traiter les avertissements comme des erreurs et a des niveaux d'avertissement variables, je ferais ce qui suit:
- Baissez le niveau d'avertissement juste assez loin pour ne recevoir aucun avertissement. Si vous êtes au niveau d'avertissement le plus bas et que vous recevez toujours des avertissements, essayez de les corriger. Si vous ne pouvez pas les corriger, alors vous avez terminé pour le moment, mais j'espère que vous pouvez les corriger. Génial.
- Étant donné que vous n'avez plus aucun avertissement (à un niveau d'alerte faible très probablement), actionnez le commutateur et traitez tous les avertissements comme des erreurs.
- Essayez d'augmenter le niveau d'avertissement et de corriger tous les nouveaux avertissements. Si vous ne le pouvez pas, baissez le niveau d'avertissement, mais ne désactivez pas de traiter les avertissements comme des erreurs.
Je trouve que cela ne fonctionne pas seulement avec des avertissements de mon code - il les empêche.