Ze Technology

Cher lectorat, bonjour.

Alors que l’on parle plus que jamais de casino en ligne, de paris sportif, poker ou des fameux « bonus » de casino sans dépôt, l’été dernier a été pour moi l’occasion de retourner de l’autre côté de la barrière. L’occasion de collaborer à nouveau avec mon ancien (excellent) employeur en matière de gambling. La mission qui m’était confiée était la suivante : partager mes expériences en matière de QA pour les projets PHP, et sensibiliser/développer tout un lot de bonnes pratiques auprès de l’équipe technique en place.

Pour formaliser un peu le périmètre, ces 2 mois devaient permettre de dérouler un état de l’art des tests unitaires, fonctionnels, de performances, sur l’intégration continue et les bonnes pratiques de développement « modernes » appliquées au PHP.

Ma plus grosse crainte était résolument celle de voir ces pratiques rejetées, jugées « inutiles », ou « trop lourdes » à appliquer au quotidien. Je savais que j’avais alors 2 mois pour démontrer tout l’intérêt de ces pratiques, pour prouver que les métriques de phpcs, phpcpd ou phpunit étaient bien plus que des simples chiffres.

L’approche

Mon approche fût la suivante : adapter chaque point au cas précis des développeurs de l’entreprise, et les impliquer le plus tôt possible dans un processus « d’auto-formation », pour assurer une pérennité à la politique qualité, une fois ces 2 mois – à mi temps – terminés. Craignant des rejets du type : « les tests, c’est pas pour nous ! », je me suis efforcé de résoudre TOUS les problèmes qui pourraient m’être posé. L’exemple le plus concret concerne un refactoring de classes PHP. L’une d’entre elle mélangeait logique métier, logique d’accès aux données, logique utilisateur… L’argument avancé était que le code devait être comme cela, que ça avait été pensé et que finalement, ça marchait très bien.

Sans forcément rejeter cette idée (après tout, un code qui marche, c’est déjà beaucoup de nos jours !) j’ai accordé le temps qu’il fallait au problème en décortiquant chaque ligne. Après avoir expliqué ma méthodologie (qui en est une à peu près standard parmi tant d’autres), on obtenait un code iso-fonctionnel, mais :

• avec des portions beaucoup plus courtes
• beaucoup plus facilement testable
• plus ordonné par « logiques », au lieu d’emboîter des appels procéduraux
• et donc, plus facilement maintenable

Je pense que cet exemple concret a été le déclencheur sur la prise de conscience de la part de l’équipe. L’exemple qui a montré que le changement n’est pas impossible, et, mieux encore, peut être pas si coûteux que  ça en temps s’il est fait rigoureusement.

Des acteurs impliqués

Une fois la théorie abordée et l’exemple donné, j’avais dédié une partie à la « pratique » collaborative. Les mains dans le cambouis, comme on dit. Des micro-tâches étaient assignées entre les différents développeurs, afin qu’ils s’approprient les outils et différents outils, et intégrer les bons réflexes. Ajout d’une nouvelle métrique à Hudson, modification d’un test unitaire, relecture du code d’autrui, consultation de la documentation… Autant de minutes dépensées à bon escient.

La finalité

J’ai oublié de vous dire : c’était ma première vraie expérience en « formation ». Je ne peux me targuer d’avoir 10 ans d’expérience en QA ou en pédagogie, mon but était d’apporter mon regard et de partager ce que je savais. Le pari est apparemment réussi. Les 2 points clés (exemple concret autour des besoins réels et implication des acteurs) ont l’air d’avoir porté leurs fruits. La plate-forme d’intégration continue fonctionne… en continue. Voilà 2 mois bien rentabilisés !