Comment convaincre mes coéquipiers que nous ne devons pas ignorer les avertissements du compilateur?
Je travaille sur un énorme projet (plus comme une combinaison emmêlée de dizaines de mini-projets qui ne peuvent pas être facilement séparés en raison d'une mauvaise gestion des dépendances, mais c'est une discussion différente) dans Java utilisant Eclipse Nous avons déjà désactivé un certain nombre d'avertissements des paramètres du compilateur et le projet contient toujours plus de 10 000 avertissements.
Je suis un grand partisan d'essayer de répondre à tous les avertissements, de les corriger tous si possible, et pour ceux qui sont examinés et jugés sûrs, de les supprimer. (Il en va de même pour mon obsession religieuse de marquer toutes les méthodes implémentées/remplacées comme @Override). Mon plus grand argument est que généralement les avertissements vous aident à trouver des bogues potentiels lors de la compilation. Peut-être sur 99 fois sur 100, les avertissements sont insignifiants, mais je pense que la tête qui se gratte qu'elle sauve pour la seule fois où elle évite un bug majeur, ça vaut le coup. (Mon autre raison est mon TOC apparent avec la propreté du code).
Cependant, beaucoup de mes coéquipiers ne semblent pas s'en soucier. Je fixe parfois des avertissements lorsque je tombe dessus (mais vous savez que c'est délicat lorsque vous touchez du code écrit par un collègue). Maintenant, avec littéralement plus d'avertissements que de classes, les avantages des avertissements sont très minimisés, car lorsque les avertissements sont si courants, personne ne se souciera de les examiner tous.
Comment puis-je convaincre mes coéquipiers (ou les pouvoirs en place) que les avertissements doivent être adressés (ou supprimés lorsqu'ils font l'objet d'une enquête approfondie)? Ou devrais-je me convaincre que je suis fou?
Merci
(P.S. J'ai oublié de mentionner ce qui m'a finalement poussé à poser cette question, c'est que j'ai malheureusement remarqué que je corrige les avertissements plus lentement qu'ils ne sont produits)
Vous pouvez faire deux choses.
Faites remarquer que les avertissements sont là pour une raison. Les auteurs de compilateurs ne les mettent pas parce qu'ils sont mesquins. Les gens de notre industrie sont généralement utiles. De nombreux avertissements sont utiles.
Rassemblez une histoire d'échecs spectaculaires résultant d'avertissements ignorés. Une recherche sur le Web pour "Faites attention aux avertissements du compilateur" renvoie quelques anecdotes.
Votre obsession pour @Override n'est pas une "obsession". C'est une bonne chose. Avez-vous déjà mal orthographié un nom de méthode?
Lecture pertinente ici . C++, mais toujours d'actualité. J'aime particulièrement cet exemple (le commentaire du code est le mien):
int searchArray(int to_search[], int len, int to_find)
{
int i;
for( i = 0; i < len; ++i )
{
if ( to_search[i] == to_find )
{
return i;
}
}
// should be returning designated 'not found' value (0, -1, etc)
}
La plupart du temps, un avertissement signifiera la différence entre l'application qui plante avec une erreur qui vous aidera en fait à détecter un défaut de conception et à le corriger (comme sûr transtypage) ou l'application faire des hypothèses et ensuite se comporter de manière incorrecte ou erronée (ce qui serait le cas avec dangereux transtypage). De même, ils signalent également du code cru ou mort qui peut être supprimé (blocs de code inaccessibles, variables inutilisées), qui peuvent être considérés comme une optimisation de code, ou des cas non comptabilisés qui apparaîtront lors des tests, comme l'exemple ci-dessus pour C++. Notez que cet exemple entraîne une erreur de compilation en Java.
Ainsi, la fixation des avertissements présente (au moins) plusieurs avantages pour la gestion:
- Moins de chance que le code se comporte de manière incorrecte avec des données saisies par l'utilisateur qui, pour les plus hauts responsables concernés par l'image de l'entreprise et la façon dont il gère les données de ses clients, devrait être un Big Deal (tm). Plantage pour empêcher un utilisateur de faire quelque chose de stupide est mieux que de ne pas planter et de le laisser le faire.
- S'ils veulent remanier le personnel, les gens peuvent entrer dans une base de code sans avertissement (et ne pas paniquer ou se plaindre autant ..). Peut-être que cela réduira la quantité de grognements qui se poursuivent ou les opinions sur la maintenabilité ou la qualité de la contribution de l'équipe X au projet Y.
- L'optimisation du code en supprimant les avertissements du compilateur, sans apporter d'améliorations significatives au temps d'exécution, va améliorer de nombreux scores en matière de test:
- Les scores de couverture de code augmenteront probablement.
- Les tests de limites et de cas de test non valides réussiront probablement plus souvent (en raison de la transtypage précitée sûr, entre autres choses).
- Lorsqu'un scénario de test échoue, vous n'avez pas à vous demander s'il est dû à l'un des avertissements du compilateur dans ce fichier source.
- On peut facilement affirmer que zéro avertissement du compilateur vaut mieux que des milliers. Aucun avertissement ou erreur ne parle de la qualité du code, vous pouvez donc affirmer que la qualité du code améliore le moins d'avertissements.
- Si vous n'avez aucun avertissement du compilateur et qu'un ou plusieurs sont introduits, il est beaucoup plus facile de savoir qui a provoqué leur apparition dans la base de code. Si vous avez une politique "sans avertissements", cela pourrait les aider à identifier les personnes qui ne font pas leur travail correctement, peut-être? Écrire du code ne consiste pas seulement à faire fonctionner quelque chose, mais à bien le faire .
Notez que je ne suis encore qu'un développeur junior qui connaît peu la gestion de projet, donc si j'ai dit quelque chose de mal, corrigez ma pensée et donnez-moi une chance de le modifier avant de me vider de mon existence :)
J'ai travaillé sur un projet avec des caractéristiques similaires dans le passé. Celui-ci en particulier a été écrit à l'origine en Java 1.4. Une fois que Java 5 avec des génériques est sorti, on peut imaginer le nombre d'avertissements lancés par le compilateur pour chaque utilisation de l'API Collections.
Il aurait fallu un certain temps pour se débarrasser de tous les avertissements, en commençant à utiliser des génériques. C'est un facteur qui doit être pris en compte, mais lorsque vous devez convaincre quelqu'un (en particulier votre responsable) qu'il doit être corrigé, vous aurez besoin de données matérielles, comme
le temps passé sur les bogues dans le code hérité ou non conforme (la norme est la norme de codage de votre projet) qui aurait pu être évité.
Vous pourriez continuer à présenter un projet de loi qui montre comment vous perdez du temps et de l'argent en ignorant "certains" avertissements, et quelqu'un aura l'idée. L'élément clé est que tous les avertissements ne valent pas la peine d'être examinés, du moins pas tout de suite; en termes plus simples, vous devrez établir la priorité des avertissements qui doivent être traités immédiatement. Pour commencer, considérez ceux qui sont pertinents pour les bogues que vous voyez dans votre projet.
Vous pouvez également noter dans le suivi des bogues, lorsque vous corrigez des bogues, que ledit bogue aurait pu être évité en n'ignorant pas un avertissement (ou peut-être en exécutant PMD ou FindBugs si vous avez un CI ou un système de construction). Tant qu'il y a un nombre suffisant de bogues qui peuvent être corrigés en tenant compte des avertissements du compilateur, votre point sur la recherche des avertissements du compilateur serait valide. Sinon, c'est une décision commerciale et, en général, cela ne vaut pas le temps de passer cette bataille.
Si vous réussissez et que votre équipe décide d'observer les avertissements, vous devez adopter une approche par étapes. Personne ne peut et ne veut 10000 avertissements en une seule fois. Vous pouvez donc sélectionner les plus importants (ceux qui sont des bogues à forte probabilité) et désactiver les moins importants. S'ils sont corrigés, augmentez à nouveau le niveau d'avertissement. De plus, vous pouvez commencer avec FindBugs, qui met en garde contre le code qui est presque toujours un bogue.
Vous avez deux façons de vous débarrasser de tous les avertissements (et je conviens que cela peut cacher un bug subtil):
- Convainquez toute l'équipe que c'est la meilleure chose à faire et demandez-leur de la réparer.
- Convainquez votre patron que c'est la meilleure chose à faire et rendez-la obligatoire. Ensuite, ils doivent le réparer.
Je crois que 1 n'est plus faisable dans votre cas. De plus, cela prendra probablement si longtemps en raison du nombre d'avertissements que cela affichera dans la sortie de productivité, de sorte que la direction devra tout de même le savoir.
Donc, ma suggestion est la suivante: discutez-en avec le patron, convainquez-le qu'il s'agit d'une bombe à retardement et faites-le adopter une politique officielle.
Je suis totalement d'accord avec vous, c'est une meilleure pratique de nettoyer le plus possible les avertissements de compilation. Vous avez mentionné que votre équipe utilise Eclipse comme outil de développement. Eclipse est un très bon outil pour vous aider à nettoyer le code et à rendre la cohérence du style de code.
- définir 'Save action' pour chacun de vos projets Java projet, comme le formatage du code, les variables locales inutilisées, l'organisation des importations (je pense que personne n'a d'objection à ce type de nettoyage).
- définir des options de compilation spécifiques au projet pour chaque projet. Par exemple, compilez le niveau (si votre code doit être compatible avec 1.4 pour nettoyer les avertissements liés aux génériques), l'affectation n'a aucun effet (par exemple 'x = x') et ainsi de suite. Vous et votre coéquipier pouvez conclure un accord pour ces éléments, et Eclipse les signalera comme "Erreur" dans votre phase de développement après avoir accepté l'accord pour l'erreur de compilation.
Eclipse créera des fichiers de propriétés pour ces préférences sous le dossier .settings, vous pouvez les copier dans d'autres projets Java et les archiver dans SCM dans le cadre du code source.
Vous pouvez consulter le code d'Eclipse pour voir comment les développeurs Eclipse le font.
Je voudrais simplement leur dire que la plupart de ces avertissements sont insignifiants et qu'il est essentiel de les retirer de la liste. Afin que nous ne manquions pas le véritable avertissement significatif dans la foule, comme cela arrive!
Vous aurez besoin de beaucoup de patience pour essayer de les convaincre, la suppression des avertissements lors de la programmation par paires aidera les autres à reprendre l'habitude. Proposez-leur de lire Efficace Java 'Article 24: Éliminer les avertissements non vérifiés' (pour la collection générique). Et ignorer probablement de nombreux cas où les gens ne suivent pas vos conseils;)
Une approche efficace ici serait de configurer un serveur intégration continue qui construit automatiquement le projet et exécute les tests chaque fois que quelqu'un vérifie le code. Si vous ne l'utilisez pas déjà, vous devriez l'être, et il n'est pas très difficile de convaincre les autres des avantages de le faire.
Convaincre la direction/les chefs d'équipe des avantages de le faire (empêcher le déploiement de mauvaises versions, trouver les bogues tôt, en particulier ceux qui affectent accidentellement d'autres parties du logiciel, maintenir les tests de régression, tester tôt et souvent, etc.)
Installez le serveur CI avec tous les tests réussis (si vous n'avez pas de tests, écrivez un rapide qui réussit, pour que tout le monde voit qu'il est vert).
Configurez des e-mails ou d'autres notifications sur l'état de chaque version. Il est important d'inclure ici qui a archivé le code, quelle était la modification (ou un lien vers la validation), et le statut + la sortie de la build. Il s'agit d'une étape importante, car elle entraîne une visibilité à l'échelle de l'équipe à la fois pour les succès et pour les échecs.
Mettez à jour le serveur CI pour faire échouer les tests en cas d'avertissement. Cela sera vu par la direction et les chefs d'équipe comme augmentant la discipline de l'équipe de manière systématique, et personne ne veut être responsable de tous les e-mails d'échec sortants.
(facultatif) obtenez Nice et geek avec cela, en ajoutant des tableaux de bord visibles, des lampes à lave, des lumières clignotantes, etc. pour indiquer l'état de la construction et qui l'a cassée/réparée.