Par Sébastien Julliand
Sommaire
Je ne vous apprendrai rien en vous disant que la revue de code est une étape essentielle du développement. Il est fondamental pour un développeur de soumettre son code à l’appréciation de ses pairs, afin d’en garantir sa qualité, et donc, sa maintenabilité.
Car en effet, le code a une odeur. Il est fréquent de rencontrer la notion de “Code smell” dans le lexique anglophone de la revue de code. Et pour cause, un développeur expérimenté saura reconnaître un code qui « sent bon » d’un code plus suspect, et ce presque par automatisme. Ce sont ces heuristiques que se propose d’appliquer les outils de revue de code, via des ensembles de règles de qualité prédéfinies qui permettent de mettre en exergue les défauts les plus fréquents. Maintenir du code propre est beaucoup plus facile (voir agréable, dirons certains passionnés) que du code tombant dans les écueils les plus communs tel que le spaghetti code ou le god object.
1. À bâbord toute
Tout l’intérêt d’une revue de code est de détecter les problèmes le plus tôt possible dans le cycle de développement. C’est le principe du shift left testing: tester tôt. Plus un bug est détecté tôt, moins il sera coûteux à corriger. Mais ce principe ne répond qu’à la moitié de la maxime de Larry Page: “Tester tôt et souvent”.
L’automatisation de la revue de code répond à ce besoin fréquent de contrôle en permettant d’appliquer les règles de qualité directement dans l’environnement de développement ou encore à interval régulier via des traitements par lot.
2. Temps de cerveau développeur disponible
Une revue de code prend du temps, notamment du temps de développement. En automatisant ce qui peut l’être dans la revue de code, on évite aux équipes de passer trop de temps sur les aspects les plus rébarbatifs de l’exercice. Le respect et l’application d’une norme de codage (ie. l’indentation, le nommage des objets, champs, méthodes, …) peuvent tout à fait être contrôlés par un outil, tout comme d’autres règles mettant en lumière le code jugé inefficient voir mort, laissant ainsi plus de temps aux développeurs pour se concentrer sur des problèmes plus complexes, que seule une revue de code manuelle saura détecter. L’automatisation permet donc d’augmenter la disponibilité des développeurs (ou du moins de ne pas la diminuer) et ainsi limiter les goulots d’étranglement.
Néanmoins, il va de soi qu’un outil, aussi performant soit-il, ne remplacera jamais l’oeil perçant et la pédagogie d’un développeur expérimenté sur les cas les plus complexes.
3. Rien ne se perd, tout se partage
Le partage de la connaissance est un point crucial et souvent problématique au sein des équipes de développement. Au mieux, les bonnes pratiques techniques et les normes de codage seront consignées dans un outil de type GED et au pire elles seront…dans l’inconscient collectif! On pourra alors difficilement reprocher à un nouveau venu de ne pas avoir respecté les normes, celles-ci n’étant finalement appliquées que par les membres chevronnés de l’équipe.
Un contrôleur de qualité des sources sera de facto la référence documentaire en ce qui concerne les normes et bonne pratiques, s’enrichissant au fil du temps, permettant ainsi un partage efficace de la connaissance sur un projet et facilitant l’application des standards. Idéalement, le contrôleur de source est directement intégré dans l’environnement de développement, permettant un contrôle du code en continu et une application au fil de l’eau des règles de qualité, évitant au développeur de faire des aller-retours entre son éditeur et une source de connaissance externe.
4. Pendant ce temps, sur IBM i
“C’est dans les vieux pots qu’on fait la meilleure soupe”, voilà une expression toute trouvée en ce qui concerne la plateforme IBM i. Boudée au départ par la scène DevOps, l’OS historique d’IBM fait un retour en force sur le devant de la scène, grâce à la mobilisation d’acteurs majeurs de l’édition logicielle et du monde Open Source.
Le développement sur la plateforme IBM i se fait via le langage RPG, sur lequel IBM a fortement investi sur les vingt dernières années en lui donnant un nouveau souffle grâce à sa forme RPG-Free et surtout RPG-FullyFree, le faisant ainsi entrer dans la cour des langages modernes. Prendre en charge les spécificités du RPG dans une revue de code automatique nécessite des outils adaptés, et c’est précisément ce que se propose de faire ARCAD CodeChecker, le contrôleur de qualité de code source de la gamme ARCAD for Devops d’ARCAD Software.
Toutes les formes et évolutions du langage sont prises en charge par le produit, du RPG III au RPG-FullyFree, et même les cas de mixité Colonné/Free. Les développeurs RPG chevronnés se faisant de plus en plus rare, CodeChecker capitalise sur plus de 25 ans d’expérience dans ce domaine en apportant une centaine de règles de qualités applicables non seulement au RPG, mais aussi au langage CL et très prochainement au COBOL.
5. Et la sécurité?
Il est un sujet qui revient de plus en plus, surtout depuis l’avènement de la méthodologie DevOps: la sécurité au sein du code. On parlera alors de DevSecOps. Sur le principe, il s’agit de penser à la sécurité d’une application dès le départ, dans son design même. Par exemple, en appliquant des règles de contrôle de qualité basées sur les préconisations de la communauté OWASP, de graves failles de sécurité pourront être évitées, tel que les risques d’injection SQL, les risques de dépassement de mémoire tampon, etc.
Les systèmes Legacy ne sont pas non plus épargnés par ces problématiques de sécurité. Dans le cas de la plateforme IBM i, la tendance est à la modernisation, et les programmes historiques se retrouvent exposés en tant que service Web, par exemple. Il devient alors critique de pouvoir détecter au plus tôt les failles de sécurité dans le code RPG, et c’est précisément ce que se propose de faire ARCAD CodeChecker via son ensemble de règles dédiée à DevSecOps, qui pourra détecter et mettre en évidence les risques d’injection SQL en RPG.
6. Le mot de la fin
En conclusion, il convient d’aborder le cas des systèmes legacy. Souvent laissés pour compte au demeurant dans la chaîne CI/CD, ces systèmes finissent par tirer leur épingle du jeu grâce à bon nombre d’outils modernes compatibles avec ces systèmes. On pourra prendre comme exemple Git qui a pris place sur IBM i et z/OS ou Ansible qui n’est plus très loin de se faire une place sur le legacy.
Et il en va donc de même pour les contrôleurs de qualité du code source: il suffit de regarder du côté de SonarQube, offrant une prise en charge partielle du langage RPG ou encore d’ARCAD CodeChecker, totalement intégré à l’écosystème IBM i pour trouver des solutions permettant d’assurer la pérennité du code.
Le contrôle automatique de la qualité du code source vient donc avantageusement compléter la chaîne d’intégration continue, et désormais même sur IBM i, notamment grâce aux outils de la gamme ARCAD for DevOps d’ARCAD Software qui assure un support complet du cycle DevOps, et ce de bout en bout.
Sébastien Julliand
Product Line Manager
Sébastien Julliand est chef de produit chez ARCAD Software et travaille depuis plus de dix ans au rapprochement des mondes IBM i et des systèmes ouverts. Animé par son enthousiasme pour les défis techniques et une forte expertise du développement dans de nombreux langages, de RPGLE à Java, Sébastien a rejoint le département R&D d’ARCAD en tant que consultant fonctionnel et technique, devenant ainsi un spécialiste sur une large gamme de produits. Sébastien est également impliqué dans le développement de plusieurs produits ARCAD, particulièrement ceux orientés DevOps, et est notamment le chef de produit d’ARCAD CodeChecker, un contrôleur de qualité du code source pour IBM i pour lequel Sébastien apporte son expérience de développeur au quotidien.
