Que faut-il faire pour avoir de meilleurs logiciels ?

Dans son blog nommé Building Real Software, Jim Bird, directeur de technologie chez BIDS Trading, nous interpelle avec cette question : « Si vous ne pouviez faire qu'une seule chose pour avoir de meilleurs logiciels, que serait-elle ? »

Selon lui, on devrait commencer par l’intégration continue puisqu’il faut d’abord « construire le logiciel et le faire fonctionner avant de pouvoir faire quelque chose d'utile avec ». Pour cela, il conseille de « faire en sorte que les développeurs enregistrent et synchronisent leur travail plus souvent » en gardant en tête qu’il faut construire le système (Build) le plus fréquemment possible : « au moins une fois par jour pour commencer, puis lors de chaque Check-in » déclare-t-il. Ceci implique selon lui de simplifier et automatiser le Build du système, et faire en sorte que l’opération s’effectue de manière correcte.

Il ajoute ensuite qu’on ne peut pas être Agile sans l’intégration continue, et qu’on a « besoin de la mettre en place avant de pouvoir aller sur le chemin du DevOps pour assurer la livraison ou le déploiement continu ».

La deuxième chose la plus importante à faire pour avoir de meilleurs logiciels selon Jim Bird c’est de « charger les développeurs de tester leur propre travail, et automatiser cela autant que possible en s’appuyant sur l’intégration continue », ceci serait selon lui « la seule façon de fournir des logiciels plus rapidement et réduire les coûts ». Toutefois, il rappelle que ces tests ne sont pas exhaustifs et qu’il faudra quand même quelqu’un pour vérifier manuellement la sécurité, l’utilisabilité, l’intégration ainsi que le negative testing et le stress testing, « à moins que vous vous attendiez à ce que vos clients trouvent les bugs pour vous ».

La troisième chose à faire c’est les Code Reviews. Le but étant de relire le code pour repérer les erreurs à un stade précoce, ceci permettra de créer une forme de « protection défensive de codage » selon l’auteur du blog. Il a tenu à rappeler que les reviews coûtent quand même cher et qu’il ne faut pas faire perdre le temps des reviewers à chercher des problèmes futiles.
Une autre technique citée par Jim Bird pour assurer la qualité du code est le Pair Programming. « Le pairing n’est pas la même que le reviewing » assure-t-il, « un bon reviewer pourra trouver des problèmes même dans le code développé grâce à la programmation en pair » puisque « le but et les objectifs sont différents ».

La dernière chose à faire avec laquelle l’auteur conclut l’article est de ne pas oublier le ‘refactoring’ qu’il voit comme un investissement à long terme : « Il permet de conserver -et parfois de rétablir- la conception, et de sauvegarder la maintenabilité du code […] Vous payez un peu aujourd'hui pour gagner beaucoup plus dans l'avenir ».

Source : Building Real Software Blog