/ SPEAKER
Architecte technique chez Equisign, je me concentre principalement sur l'optimisation des performances de notre application LetReco. Mon expérience dans l’électronique renforce mon intérêt pour la précision du code, sa sécurité et sa vitesse.
Les applications SaaS, sensibles lors des mises en production en raison de leur impact direct sur les utilisateurs, nécessitent une attention particulière. Cela nourrit mon engagement envers la qualité et la stabilité du code.
En dehors de mon travail chez Equisign, le cross-training occupe une place importante dans ma vie. Ce sport, tout comme l'informatique, met à l'épreuve ma capacité à me dépasser. Souvent, le véritable défi réside dans l’affrontement de ses propres limites, face à des charges lourdes qui sont parfois intimidantes.
La revue de code est considérée comme une bonne pratique à mettre en place lors du processus de développement d’un logiciel. Ses avantages sont son efficacité à détecter des bugs au plus tôt dans la chaîne de développement et son faible coût de mise en œuvre.
Pourtant, et bien que de nombreux outils permettent aujourd’hui d’aider la revue de code, certains bugs constatés en production auraient pu être détectés par une simple relecture. Se pose alors la question du pourquoi, mais aussi celle du comment améliorer ce processus pour le rendre efficace.
Parmi les diverses approches possibles, chaque méthode débute par la centralisation des retours issus de différents outils (analyseur statique, calcul de complexité). Cela permet de réaliser des analyses croisées et d’optimiser l’efficacité de la revue de code.
Une première étape serait d’intégrer les retours de ces outils dans l’interface « git diff » de GitHub. Le but de cette présentation est de montrer comment on peut récupérer les retours de SonarCloud et les pousser en tant que revue Github, en passant par une petite application minimaliste en Rust et invoquée par AWS lambda.
Searching for speaker images...
English 
Français