Je leur ai demandé de classer par ordre de priorité les problèmes rencontrés par l'équipe d'assurance qualité et de mettre en œuvre des tests dans le processus de construction afin d'éviter que ces problèmes ne se reproduisent. Après trois semaines de travail d'un développeur, 130 tests ont été effectués dans le processus de construction. Le cycle de publication suivant a réduit l'assurance qualité à 2 semaines et les appels d'assistance sur le terrain ont diminué de 50%, ce qui a permis d'économiser des millions d'euros en temps de développement et de générer des millions d'euros d'augmentation des ventes. Je n'ai jamais rien vu qui fonctionne mieux que cela.
Google a développé une brillante stratégie automatisée appelée "Bug Prediction" qui fait essentiellement la même chose. Il semble que chaque équipe devrait faire quelque chose comme ça.
La prédiction des bogues chez Google
Cependant, les Googlers travaillent chaque jour sur des problèmes de plus en plus complexes, fournissant les fonctionnalités et la disponibilité dont dépendent nos utilisateurs. Certains de ces problèmes sont nécessairement difficiles à appréhender, ce qui conduit à un code inévitablement difficile. Parfois, ce code fonctionne très bien et est déployé sans incident. D'autres fois, le code crée des problèmes encore et encore, à mesure que les développeurs tentent de résoudre le problème. Pour les besoins de cet article, nous appellerons cette deuxième catégorie de code "points chauds". Il se peut qu'un point chaud résiste aux tests unitaires, ou qu'un ensemble de conditions très spécifiques conduise le code à l'échec. En général, nos réviseurs de code diligents, expérimentés et intrépides sont en mesure de repérer les problèmes et de les résoudre. Cela dit, nous sommes tous humains et des bogues sournois peuvent toujours se glisser dans le code. Nous avons constaté qu'il peut être difficile de savoir si quelqu'un modifie un point sensible ou un code généralement inoffensif. En outre, à mesure que la base de code et les équipes de Google augmentent en taille, il devient de plus en plus improbable que l'auteur et le réviseur soient conscients qu'ils modifient un point sensible.
Afin d'identifier ces points chauds et d'avertir les développeurs, nous avons étudié la prédiction des bogues. La prédiction de bogues utilise l'apprentissage automatique et l'analyse statistique pour essayer de deviner si un morceau de code est potentiellement bogué ou non, généralement dans un certain intervalle de confiance. Les mesures basées sur la source qui pourraient être utilisées pour la prédiction sont le nombre de lignes de code, le nombre de dépendances nécessaires et le caractère cyclique de ces dépendances. Ces mesures peuvent donner de bons résultats, mais elles vont signaler notre code nécessairement difficile, mais par ailleurs inoffensif, ainsi que nos points chauds. Nous ne nous préoccupons que de nos points chauds, alors comment les trouver ? En fait, nous disposons d'un excellent registre faisant autorité sur les endroits où le code a nécessité des corrections : notre système de suivi des bogues et notre journal de validation du contrôle du code source ! La recherche (par exemple, FixCache) indique que la prédiction des bogues à partir de l'historique des sources fonctionne très bien, nous avons donc décidé de le déployer chez Google.