9/11 Projet informatique, passer du moyen âge à l'ère industrielle. Comment vérifier que les développeurs n'ont pas mijoté un plat de spaghetti ? (qualité du code, audit, style, ...)
La méthodologie de gestion d'un projet informatique doit inclure les aspects normes et stratégie de codage. Sinon l'arnarchie va régner, chaque développeur aura sa propre manière d'indenter son code, de nommer les classes, les attributs, les méthodes (anglais, français, ...), les paramétres, les variables locales, ...
Chacun aura ses patterns de code, utiliser une boucle "for"(C, C++, Java, C#, ...) infinie et tester une condition à l'intérieure pour en sortir plutôt qu'un "for" classIque. Les développeurs c'est comme les écrivains, chacun a son style propre et on peut reconnaître son auteur sans regarder la signature. L'erreur chronophage et quasi systématique c'est la duplication de code. Tout développeur qui se respecte sait qu'il ne doit pas faire du copier/coller pour des problèmes évidents de maintenance, de lisibilité, d'impacts en cas de modifications, ... Les conceptions génériques coûtent toujours un peu plus chéres au départ mais on y gagne énormément en évolutivité, réutilisabilité et maintenabilité. Vous aurez beau dire qu'il ne faut pas le faire, il se peut que dans une situation d'urgence, pris par le stress, le développeur le fasse quand même en se disant qu'il modifiera à l'itération suivante, ce qui ne sera bien sur jamais fait car dans un projet les "TODO" s'accumulent vite et les impondérables aussi. Des alertes sur du code complexe peuvent être mises en œuvre. Le paramétrage de métriques concernant la taille des classes et des méthodes permet de déceler les parties de codes qui doivent être refactorées. Les outils peuvent aussi détecter de manière statique les mauvaises pratiques de codage, le code "mort", les expressions sous optimisées. Le chef de projet doit demander à l'architecte technique de mettre en place des outils d'audit comme Checkstyle ou PMD facilement intégrables et configurables dans les IDE comme Eclipse. Un autre concept, est d'analyser le byte code généré par le compilateur. C'est la philosophie choisie par FindBugs. Ce puissant outil permet de trouver des bogues potentiels, des problèmes de performances, ou des mauvaises habitudes de codage. FindBugs est le résultat d’une recherche menée par Bill Pugh à l’université du Maryland, et qui étudie les modèles de byte code venant de bogues dans de réels grands projets, comme les JDKs, Eclipse, ou le code source d’applications Google. FindBugs peut détecter des problèmes assez importants tels que des exceptions de pointeurs nuls, des boucles infinies, et un accès non intentionnel de l’état interne d’un objet.
Pour la qualité, la lisibilté, l'évolutivité, la réutilisabilité, la maintenabilité et les performances du code source il est vivement conseillé d'activer ces outils sans attendre les premiers développements. Si on se base sur la méthode UP (Unified Process) l'installation des outils et leurs paramétrages relévent de la discipline Environnement au début de la phase Élaboration.
Mieux vaut donc anticiper l'audit de code à moins que les plats de spaghettis soient votre spécialité.
![urbanisation des SI, processus métier, règles métier, bonnes pratiques SI, MDA, génération d'applica](https://image.over-blog.com/40w69K53RNUYe-qoCKwaKofkTsY=/170x170/smart/filters:no_upscale()/http%3A%2F%2Fstatic.blog4ever.com%2F2014%2F08%2F780066%2Furbanisation-des-si.jpg)
urbanisation des SI, processus métier, règles métier, bonnes pratiques SI, MDA, génération d'applica
Urbanisation des SI, processus métier, moteur de processus, règles métier, moteur de règles, BPM, BRMS, SOA, génération d'application, MDA, méthode agile, Scrum, Kanban, bonnes pratiques SI
Le but de ce blog est d'expliquer de manière pédagogique les enjeux, concepts et innovations dans le domaine de l'urbanisation des SI.
Le super ordinateur Watson d'IBM champion du monde de Jeopardy! en 2011 capable de s"approprier des milliers de milliards de données afin de répondre à des questions en langage naturel. En 1997 ...
Commenter cet article