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 les allumez pas lorsque la personne qui voit ne peut rien faire à leur sujet (un utilisateur en production, qui ne sait même pas comment 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 au départ ;-) Mais gardez cela à l'esprit comme objectif! S'il est possible d'activer ou de désactiver cette fonction par fichier, activez-la pour tous les nouveaux fichiers, activez-la pour tous les fichiers sans avertissement et ne la désactivez plus une fois activée.
Alors, que faire de la surcharge?
Vous faites 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 patch, chaque commit ne doit pas introduire de nouveaux avertissements, il ne peut que les corriger .
- Chaque fois que vous touchez un morceau de code, corrigez tous les avertissements de ce morceau de code. (La règle du 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: les deux 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, cela 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."
@.