Presentation faite à Agile France en 2011
La revue de code : c’est facile !
Cette présentation est la suite de la session « La revue de code : c’est agile, c’est lean, c’est indispensable ! » présentée à Agile France et Agile Tour en 2010.
Après avoir répondu aux idées reçues sur la revue de code et avoir montré combien une revue de code systématique soutient une démarche agile et lean, cette présentation se focalise sur la mise en place de la revue de code comme étape incontournable du processus de développement.
Nous évoquerons les bonnes pratiques, les difficultés à la mise en place, les pièges à éviter et aussi les outils qui facilitent la revue de code. Une grande partie de la présentation sera dédiée à plusieurs démonstrations, exemples et retours d’expérience.
Adopter une méthodologie pour développer un système est indéniable au risque de vous planter, cette présentation étale sur ses slides la méthodologie 2TUP, qui fait partie de la famille des Processus unifiés basés sur UML
Adopter une méthodologie pour développer un système est indéniable au risque de vous planter, cette présentation étale sur ses slides la méthodologie 2TUP, qui fait partie de la famille des Processus unifiés basés sur UML
A la recherche d'un stage de Projet de Fin d'études pour élève ingénieur en informatique
domaines souhaitées :
Développement FullStack (Java EE / Spring boot + Angular 5 )
DevOps (Docker, Jenkins, Maven, git ... )
Big Data
Développement : c# / .Net
Aujourd’hui, les tests sont devenu un élément crucial au cycle de développement logiciel, des sociétés ont investi dans la création d’un service interne de tests, rien ne peut être mis en production sans être validé par ce service.
Pour cela, cette présentation va mettre en évidence les fondamentaux de test logiciel à savoir: définitions, types, processus, méthodes, outils, principes, stratégies, jeux de test, etc.
Cette présentation, mise en scène les valeurs et les principes des méthodes agiles , ainsi qu'une présentation détaillée sur la méthode XP et la méthode Scrum.
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...Madjid Meddah
L’objectif du projet est de concevoir et implémenter un système, en ligne, qui automatise
la gestion et l’affectation des projets de fin d’étude. Le système permettra aux enseignants de
proposer des thèmes pour les projets de fin d’études aux étudiants, ces derniers pourront
choisir ou modifier leurs choix. Le système permettra en outre d’automatiser l’affectation des
PFE aux étudiants, cette tâche se fait actuellement d’une façon totalement manuelle.
Mots-clés: application web, base de données, gestion des PFE
The goal of the project is to design and implement an online system that automates the
management and the assignment of graduation projects. The system will allow teachers to
propose their themes for graduation projects to students, who will be able to choose or modify
their choices. The system will also automate the assignment of the graduation projects to
students; this task is done currently in a manual way.
Keywords : Web Application, Data base, Graduation Project
Objectif général : Prendre en main l’un des frameworks PHP les plus utilisés
Objectifs spécifiques
Faire correspondre une URL donnée à un traitement précis grâce au routage
Regrouper des traitements connexes grâce aux contrôleurs
Récupérer les données d’une requête http grâce à Request
Retourner des contenus aux formats texte, HTML, JSON, etc. grâce à Response
Intégrer des données dans des templates grâce à Blade
Interagir avec l’utilisateur grâce aux formulaires
Créer, mettre à jour et suivre les évolutions d’un schéma de base de données grâce aux migrations
Faciliter la communication avec une base de données grâce à Eloquent
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...tayebbousfiha1
Bonjour à tous, je souhaite partager avec vous mon rapport PFE qui se focalise sur ma participation au développement d'un projet ALTEN MAROC concernant le système d'information pour la gestion des compétences avec Spring Boot / React JS / JHipster / Eclipse / PostgreSQL.
Le rapport à été validé par l'équipe technique et ressource humaine d'ALTEN MAROC et par le directeur du master de L' Université Bretagne Sud (UBS) Franck POIRIER et la directrice de l'Institut Supérieur d’Ingénierie et des Affaires (ISGA).
Ce rapport est écrit pour principalement aider les personnes qui souhaite en savoir plus sur React / Jhipster / SpringBoot / Docker / La méthodologie agile Scrum / la structuration essentiel d'un PFE / PostgreSQL / Liquibase / Faker / Git / GitHub / Azure DevOps / Creately / ESLint / Axios / TypeScript / ECMAScript / JSON / Prime React / Swagger / REST API / SPA / OAuth / Système d’Information / Dossiers Techniques / Gestion des compétences / Analyse et Conception / Hibernate / JPA / JEE / JAVA / Postman / Bootstrap / JWT ...
Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1Addi Ait-Mlouk
Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1
•Prise en main complet d’odoo
•Configuration complète
•Caractéristiques techniques complète
•Savoir crée un module personnalisé
•Savoir développer un module spécifique
La revue de code : agile, lean, indispensable !Lucian Precup
Présentation faite à Agile France en 2010 :
La revue de code : agile, lean, indispensable !
Alors que l’intégration continue ou les tests unitaires commencent à rentrer dans les "standards", la revue de code est souvent considérée comme optionnelle. Pourtant, les avantages d’une revue de code systématique sont multiples : détection des anomalies très tôt dans le cycle de développement, formation des membres de l’équipe, partage de la connaissance, meilleures solutions techniques par la conjonction des perspectives développeur/examinateur.
Cette présentation mettra en évidence les avantages de la revue du code en répondant aux idées reçues comme "la revue du code augmente la durée des développements", ou "nos développeurs sont très bons, ils n’ont pas besoin de revue de code" ou encore "il n’y a personne dans l’équipe qui puisse examiner mon code car je suis le seul à connaître Bash et Ant". En évoquant la revue de code dans l’univers open source, les différents moyens de la mettre en œuvre, ses compléments, les différents outils ; et terminant par une démonstration concrète en utilisant Eclipse, Bugzilla et Mylyn, cette présentation vous convaincra de mettre en place la revue de code systématique dans votre équipe sans attendre.
Déroulement :
1/ Avantages
2/ Idées reçues
3/ La revue de code dans l’univers open-source : de la revue du patch par le committeur aux procédures très élaborées comme celles de Mozilla Developer Center.
4/ Moyens de mise en œuvre : à partir de quelle taille des projets, par qui, comment, avant l’intégration ou après, ...
5/ Les compléments de la revue du code : analyse de la qualité du code, scripts pour les normes internes, ...
6/ Comparaison avec d’autres techniques : pair programming, ...
7/ Outils et intégration avec les autres outils de développement ou de gestion du cycle de vie (intégration continue, gestion des anomalies, ...)
8/ Démonstration des avantages sur un exemple concret en utilisant Eclipse, Bugzilla et Mylyn comme outils.
9/ Conclusion : comment la revue de code supporte une démarche agile et lean
Ratez vos revue de code en 5 lecons devoxx fr 2016Michel Domenjoud
La revue de code, tout le monde connait, bien sûr. C'est d'ailleurs une des plus vieilles pratiques de développement, dont l'efficacité est prouvée depuis longtemps pour détecter des défauts au plus tôt. Alors pourquoi tant d'équipes n'utilisent elles pas la revue de code, ou n'en tirent pas les bénéfices qu'évoquent de nombreuses études ? Au cours de cette session, on explorera quelques uns des nombreux écueils à éviter, au travers de situations de revue de code qui se passent mal, et on proposera des pistes pour corriger le tir.
A la recherche d'un stage de Projet de Fin d'études pour élève ingénieur en informatique
domaines souhaitées :
Développement FullStack (Java EE / Spring boot + Angular 5 )
DevOps (Docker, Jenkins, Maven, git ... )
Big Data
Développement : c# / .Net
Aujourd’hui, les tests sont devenu un élément crucial au cycle de développement logiciel, des sociétés ont investi dans la création d’un service interne de tests, rien ne peut être mis en production sans être validé par ce service.
Pour cela, cette présentation va mettre en évidence les fondamentaux de test logiciel à savoir: définitions, types, processus, méthodes, outils, principes, stratégies, jeux de test, etc.
Cette présentation, mise en scène les valeurs et les principes des méthodes agiles , ainsi qu'une présentation détaillée sur la méthode XP et la méthode Scrum.
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...Madjid Meddah
L’objectif du projet est de concevoir et implémenter un système, en ligne, qui automatise
la gestion et l’affectation des projets de fin d’étude. Le système permettra aux enseignants de
proposer des thèmes pour les projets de fin d’études aux étudiants, ces derniers pourront
choisir ou modifier leurs choix. Le système permettra en outre d’automatiser l’affectation des
PFE aux étudiants, cette tâche se fait actuellement d’une façon totalement manuelle.
Mots-clés: application web, base de données, gestion des PFE
The goal of the project is to design and implement an online system that automates the
management and the assignment of graduation projects. The system will allow teachers to
propose their themes for graduation projects to students, who will be able to choose or modify
their choices. The system will also automate the assignment of the graduation projects to
students; this task is done currently in a manual way.
Keywords : Web Application, Data base, Graduation Project
Objectif général : Prendre en main l’un des frameworks PHP les plus utilisés
Objectifs spécifiques
Faire correspondre une URL donnée à un traitement précis grâce au routage
Regrouper des traitements connexes grâce aux contrôleurs
Récupérer les données d’une requête http grâce à Request
Retourner des contenus aux formats texte, HTML, JSON, etc. grâce à Response
Intégrer des données dans des templates grâce à Blade
Interagir avec l’utilisateur grâce aux formulaires
Créer, mettre à jour et suivre les évolutions d’un schéma de base de données grâce aux migrations
Faciliter la communication avec une base de données grâce à Eloquent
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...tayebbousfiha1
Bonjour à tous, je souhaite partager avec vous mon rapport PFE qui se focalise sur ma participation au développement d'un projet ALTEN MAROC concernant le système d'information pour la gestion des compétences avec Spring Boot / React JS / JHipster / Eclipse / PostgreSQL.
Le rapport à été validé par l'équipe technique et ressource humaine d'ALTEN MAROC et par le directeur du master de L' Université Bretagne Sud (UBS) Franck POIRIER et la directrice de l'Institut Supérieur d’Ingénierie et des Affaires (ISGA).
Ce rapport est écrit pour principalement aider les personnes qui souhaite en savoir plus sur React / Jhipster / SpringBoot / Docker / La méthodologie agile Scrum / la structuration essentiel d'un PFE / PostgreSQL / Liquibase / Faker / Git / GitHub / Azure DevOps / Creately / ESLint / Axios / TypeScript / ECMAScript / JSON / Prime React / Swagger / REST API / SPA / OAuth / Système d’Information / Dossiers Techniques / Gestion des compétences / Analyse et Conception / Hibernate / JPA / JEE / JAVA / Postman / Bootstrap / JWT ...
Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1Addi Ait-Mlouk
Paramétrage et développement spécifique des modules odoo(OpenERP) Partie 1
•Prise en main complet d’odoo
•Configuration complète
•Caractéristiques techniques complète
•Savoir crée un module personnalisé
•Savoir développer un module spécifique
La revue de code : agile, lean, indispensable !Lucian Precup
Présentation faite à Agile France en 2010 :
La revue de code : agile, lean, indispensable !
Alors que l’intégration continue ou les tests unitaires commencent à rentrer dans les "standards", la revue de code est souvent considérée comme optionnelle. Pourtant, les avantages d’une revue de code systématique sont multiples : détection des anomalies très tôt dans le cycle de développement, formation des membres de l’équipe, partage de la connaissance, meilleures solutions techniques par la conjonction des perspectives développeur/examinateur.
Cette présentation mettra en évidence les avantages de la revue du code en répondant aux idées reçues comme "la revue du code augmente la durée des développements", ou "nos développeurs sont très bons, ils n’ont pas besoin de revue de code" ou encore "il n’y a personne dans l’équipe qui puisse examiner mon code car je suis le seul à connaître Bash et Ant". En évoquant la revue de code dans l’univers open source, les différents moyens de la mettre en œuvre, ses compléments, les différents outils ; et terminant par une démonstration concrète en utilisant Eclipse, Bugzilla et Mylyn, cette présentation vous convaincra de mettre en place la revue de code systématique dans votre équipe sans attendre.
Déroulement :
1/ Avantages
2/ Idées reçues
3/ La revue de code dans l’univers open-source : de la revue du patch par le committeur aux procédures très élaborées comme celles de Mozilla Developer Center.
4/ Moyens de mise en œuvre : à partir de quelle taille des projets, par qui, comment, avant l’intégration ou après, ...
5/ Les compléments de la revue du code : analyse de la qualité du code, scripts pour les normes internes, ...
6/ Comparaison avec d’autres techniques : pair programming, ...
7/ Outils et intégration avec les autres outils de développement ou de gestion du cycle de vie (intégration continue, gestion des anomalies, ...)
8/ Démonstration des avantages sur un exemple concret en utilisant Eclipse, Bugzilla et Mylyn comme outils.
9/ Conclusion : comment la revue de code supporte une démarche agile et lean
Ratez vos revue de code en 5 lecons devoxx fr 2016Michel Domenjoud
La revue de code, tout le monde connait, bien sûr. C'est d'ailleurs une des plus vieilles pratiques de développement, dont l'efficacité est prouvée depuis longtemps pour détecter des défauts au plus tôt. Alors pourquoi tant d'équipes n'utilisent elles pas la revue de code, ou n'en tirent pas les bénéfices qu'évoquent de nombreuses études ? Au cours de cette session, on explorera quelques uns des nombreux écueils à éviter, au travers de situations de revue de code qui se passent mal, et on proposera des pistes pour corriger le tir.
Le groupe de travail mesure de l'immatériel (GTMI), dont Syntec Conseil en Relations Publics, coordonné par le Conseil Supérieur de l'Ordre des Experts-Comptables vient de faire paraitre 12 propositions au service de la compétitivité et de la valeur durable des entreprise
La relecture de code : avant tout des pratiquesEric SIBER
Quelle est l'utilité de la relecture de code ? Bonnes pratiques, mauvaises pratiques, comment s'y prendre pour mener cette tâche à bien malgré les obstacles organisationnels ?
Cette session vise à sensibiliser les participants à la problématique de relecture de code. Souvent ce sont les outils qui font le buzz, reléguant les pratiques et leur adoption au second plan. Loin des effets whaou de la démo d'un outil, je souhaite vous sensibiliser au pourquoi et comment, tout en illustrant par des pratiques : de la plus élémentaire à la plus tendance. Des pistes seront données à l'audience pour mettre en place ou renforcer la démarche qualité sur le terrain, ainsi que les références aux outils qui s'inscrirons dans ces pratiques.
A l'image du premier principe du manifeste agile (Les individus et leurs interactions plus que les processus et les outils), la présentation sera donc largement tournée sur l'humain, le relationnel, elle ne détaille ni ne fait la promotion d'un processus ou d'un outil donné de relecture de code (qui seront néanmoins mentionnés).
Pourquoi et comment nous relisons ensemble tout le code que nous produisons - retour d'expérience du WebCenter AXA sur la revue de code, accompagnés par Octo.
Dans nos accompagnements techniques, nous observons régulièrement des problèmes de Legacy Code aussi appelé Code Patrimonial. Notamment lorsque des équipes font un virage agile et on leur demande soudainement de faire des tests unitaires automatisés. Pas si facile que cela.
Dans cette présentation, nous verrons les points suivants:
- Description de quelques techniques pour nous aider à tester le Legacy Code
- Comment avoir le droit de travailler sur du code pour le rendre plus facile à travailler
- Quelques pratiques et outils afin de s'en prémunir autant que possible au jour le jour.
Cette présentation a été donnée aux dates suivantes:
- 10 Novembre 2016 - Beer And Learn (Québec)
- 16 Novembre 2016 - Agile Tour Montréal
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Xavier NOPRE
Diaporama de ma présentation "Agilistes : n'oubliez pas la technique" le 25/04/2013 à Mix-IT 2013. N'hésitez pas à me faire des retours et me contacter !
Mockito - Design + tests par Brice DuteilNormandy JUG
rice Dutheil est indépendant, membre du groupe des Zindeps. Comiteur sur Mockito.Son blog est le “TheCoffeeWorkshop“. Son Twitter est @BriceDutheil.
Le design par le test
Le TDD est aujourd’hui une pratique reconnue pour permettre la production de code avec peu d’anomalies. Mais ce n’est pas le seul interet du TDD ; le design du code peut en etre le grand gagnant. Ces quelques slides vont essayer de donner un apercu des opportunites à saisir et des pieges à eviter ; Mockito inside.
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
Comment s'assurer que tout le monde parle la même langue dans l'équipe ? Et ainsi éviter les retours de recette ?
Utiliser des spécifications exécutables, ou ses cousins le ATDD (Acceptance Test Driven Development) et le BDD (Behavior Driven Development), est un élément de réponse particulièrement pertinent. Cette méthode est également un point d'entrée puissant vers une stratégie d'automatisation des tests.
Dans cette présentation vous découvrirez les tenants et les aboutissants de cette méthode, et repartirez les poches remplies de conseils de mise en place.
Joins in a distributed world Distributed Matters Barcelona 2015Lucian Precup
A lot of database related algorithms are more difficult to implement in a distributed environment. Quite often, the "distributed" version is far from the "classical" version : constraints are dropped (see the CAP theorem), only specific cases are supported (for example : the involved data needs to be co-located within the distributed system), etc. This talk focuses on joins.
We start by presenting join implementations in "classical" relational databases than we lead the audience through the challenges and solutions to make these functions available in a distributed environment. While we start with a theoretical point of view, we finish by giving real life examples from implementations in ETL systems (known for joining heterogeneous databases and therefore quite advanced in this area, but often not real-time) and some modern NoSQL databases (where most systems choose to offer less features with respect to joins).
Search and nosql for information management @nosqlmatters CologneLucian Precup
In this talk we will present real life use cases of integrating search and nosql solutions into a classical information management application. We will focus on advantages of such a hybrid approach for an, otherwise, pure relational database use case. We will also present the technical challenges, propose patterns for the polyglot persistence, address issues with synchronization between the relation databases and the nosql eco-system. The presentation will give you a good comparison between relational databases / sql and Lucene / nosql on all the levels (functionality, semantics, performance, user experience).
Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014Lucian Precup
What if we would try to make Elasticsearch SQL 92 compliant (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt)? This wouldn't serve that much nowadays, you would say. Well, we actually tried to do the exercise and we have some interesting conclusions. While we take Elasticsearch as an example for this "side by side", the issues we are addressing also apply to nosql in general. With this unusual exercise, we take the occasion to compare relational databases / sql with Elasticsearch / nosql on all the levels : functionality, semantics, performance and user experience.
Back to the future : SQL 92 for Elasticsearch @nosqlmatters ParisLucian Precup
What if we would try to make Elasticsearch SQL 92 compliant (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt)? This wouldn't serve that much nowadays, you would say. Well, we actually tried to do the exercise and we have some interesting conclusions. While we take Elasticsearch as an example for this "side by side", the issues we are addressing also apply to nosql in general. With this unusual exercise, we take the occasion to compare relational databases / sql with Elasticsearch / nosql on all the levels : functionality, semantics, performance and user experience.
Présentation faite à ScrumDay Paris en 2011
Les développeurs, les responsables qualité, les ScrumMasters, les ProductOwners ou les responsables des développements ont de plus en plus besoin d’intégrer leurs outils. Ceci s’inscrit dans une démarche Lean visant à donner un accès facile et immédiat à toute l’information, à éliminer les gaspillages et à détecter les problèmes le plus tôt possible dans le cycle de développement.
Alors que certaines plateformes, comme celle de Microsoft, sont déjà intégrées, beaucoup de systèmes sont construits sur mesure par les équipes de développement. Nous pouvons imaginer, par exemple, une plateforme intégrant Eclipse, Code Collaborator, Perforce, Hudson, Sonar, Jira, Project Server et Crystal Reports, solution intégrant des outils Open Source et propriétaires.
Cette session présentera différentes solutions ALM et la façon dont elles supportent une démarche agile. Pour mettre l’accent sur l’intégration entre les différents outils nous détaillerons une solution basée sur Mylyn, l’ALM Open Source pour Eclipse, s’intégrant à Microsoft TFS. Quelques fonctionnalités sympathiques comme la gestion très facile du backlog, le calcul automatique du burndown chart ou la gestion des revues de code seront également présentées.
Moteurs de recherche et Lucene at LorraineJUGLucian Precup
Présentation tenue à Lorraine JUG (http://lorrainejug.blogspot.fr/2012/11/moteurs-de-recherche-lucene-en-action.html):
<< Apache Lucene, la fameuse technologie pour l’indexation, la recherche et l’analyse du texte est la base de plusieurs serveurs Open Source. La présentation détaillera Solr et ElasticSearch sous la forme "Tools in Action" - démonstrations en direct des différents outils.
Allant au-delà du tutorial, cette session vous permettra de découvrir comment mettre en place des serveurs de recherche pertinents, robustes, performants et évolutifs en utilisant des approches NoSQL, Apache Lucene et bibliothèques Java Open Source. Des subtilités sur l’analyse du texte, la recherche approximative, l’auto-complétion seront abordées afin de montrer les forces mais aussi les limites de la magie Lucene.
Lucian est développeur, architecte et responsable des développements ayant évolué, depuis douze ans, du projet de recherche au grand éditeur de logiciels en passant par la start-up.
Depuis 2010 Lucian a acquis, à travers ses missions, une expertise sur les architectures NoSQL et les moteurs de recherche pour l’entreprise (Enterprise Search), expertise qu’il partage dans différents barcamps et conférences. >>
Solr and Elasticsearch in Action (at Breizhcamp)Lucian Precup
Lucene @ Breizhcamp
Lucene, la fameuse technologie pour l’indexation, la recherche et l’analyse du texte a été présente à l'édition 2012 de Breizhcamp à travers deux sessions « Tools In Action » : ElasticSearch et Solr.
Allant au-delà du tutorial, ces deux sessions ont permis de découvrir des patterns d’architecture pour l'intégration d'un moteur de recherche et navigation dans un SI ainsi que de comprendre l’alternative qu’offrent les moteurs de recherche et les approches NoSQL aux bases de données relationnelles. Des subtilités sur l’analyse du texte ont été abordées afin de montrer les forces mais aussi les limites de la magie Lucene. Les démonstrations de chaque technologie et des outils dans leur écosystème ont rendu la présentation plus interactive.
La vidéo de la présentation se trouve sur Parleys (http://www.parleys.com/#st=5&id=3351).
3. Qu’est ce la revue de code?Qu est‐ce la revue de code?
I i é i d d• Inspection systématique du code source
• Mécanisme pour:
– Valider le design et l’implémentation des changements
– Assurer une cohérence entre modules et développeurs au
niveau du design et des pratiques de développementniveau du design et des pratiques de développement
– Partager, former et se former
• Types de revue de code• Types de revue de code
– Formelle ou informelle, pré ou post commit
– « Over‐the‐shoulder » par e‐mail« Over the shoulder », par e mail
– « Pair‐programming »
4. AvantagesAvantages
Di t• Directs:
– Meilleure qualité du code
Moins de bugs dans le code– Moins de bugs dans le code
– Meilleure communication dans l’équipe
– Formation des nouveaux arrivants et juniors– Formation des nouveaux arrivants et juniors
• Indirects:
– Cycle de développement/test plus courts– Cycle de développement/test plus courts
– Moins d’impact sur le support technique
– Clients plus satisfaitsClients plus satisfaits
– Code plus maintenable
– Meilleure architecture du code
5. Objectif de la présentationObjectif de la présentation
• Mise en place de la revue de code comme
étape incontournable du processus de p p
développement
– Les bonnes pratiques– Les bonnes pratiques
– Les pièges à éviter
– Exemples
– Retours d’expérience
8. Le monde Open SourceLe monde Open Source
Review
RefactoringRefactoring
Modifications
patch
patch
SCM
CI
patch
checkin
RM
Super Review
checkin
9. Implémentations et témoignagesImplémentations et témoignages
f di• INRIA Transfert et Medience
– Implémentation avec Aegis
– Très bonne qualité malgré le turn‐
over de l’équipe
• Business Objects
– « Les développements de l’équipe« Les développements de l équipe
Data Federator étaient plus longs. En
revanche, ils se stabilisaient
rapidement et les délais de livraisons
étaient très prévisibles »
10. Autres témoignagesAutres témoignages
G d édi d l i i l• Grand éditeur de logiciel
– Équipe de huit personnes (France et Etats Unis)
– Très productive grâce à la revue asynchrone pendant
la « nuit »
h l• Guido van Rossum, Python creator and Google
employee
– « As I've learned over the last two years at Google, … ,
proper code review habits can really improve the
quality of a code base and good tools for code reviewquality of a code base, and good tools for code review
will improve developers' life »
12. Difficultés à la mise en œuvreDifficultés à la mise en œuvre
L d dé l• Les egos des développeurs
• La difficulté d’intégrer la revue de
code dans le processus decode dans le processus de
développement
– Rassembler les fichiers– Rassembler les fichiers
– Programmer la réunion, interrompre
quelqu’un ou lire un long e‐mailq q g
– Gérer l’historique
– Un simple commit c’est tellement plus
i l )simple :‐)
• Manque de soutien de la hiérarchie
13. Piège numéro 1 : mauvaise méthodePiège numéro 1 : mauvaise méthode
F i l d d è l it• Faire la revue de code après le commit
• Prendre la revue à la légère, regarder le
d di lcode « en diagonale »
• Laisser traîner les revues
l ’ f i• Interrompre quelqu’un pour faire une
revue
S’ d t j à l ê• S’adresser toujours à la même personne
pour la revue
• Mettre trop de changements en revue• Mettre trop de changements en revue
dans le même patch
14. Piège numéro 2 : le Team LeaderPiège numéro 2 : le Team Leader
• Faire la revue de code uniquement
par les Tech Leadsp
• Ne plus faire d’analyse technique et
ne plus rédiger des spécificationsne plus rédiger des spécifications
pour les développeurs
• Oublier les autres moyens de
formation et transfert deformation et transfert de
connaissance
15. Piège numéro 3: le "Review Failed"Piège numéro 3: le Review Failed
A i d "R i F il d"• Avoir peur du "Review Failed"
– Pour le reviewer : faire lui‐même les
modifications dans le code d’un junior etmodifications dans le code d un junior et
archiver sans faire de retour au développeur
• Ne pas craindre le "Review Failed"p
– Pour le développeur : trop se baser sur le
reviewer et ne pas se soucier de la qualité de
dson code
• Trop aimer le "Review Failed"
P l i R t d l’i té ti d’– Pour le reviewer : Retarder l’intégration d’un
change à cause des bugs non bloquants pour
le change en revueg
16. Piège numéro 4 :
Le reviewer trop assidu
• Exiger que tous les points soient
corrigés dans le patch qui est en revuecorrigés dans le patch qui est en revue.
– Si le code peut être archivé avec un bug
connu ou un développement incomplet,connu ou un développement incomplet,
créez le bug ou la tâche, archiver le code
et passez à la suite
• Faire un "Review Failed" pour un bug
qui était déjà présent mais pas vu
auparavant ou qui n'a rien à voir avec
le code qui est en revue.
17. Piège numéro 5: les outilsPiège numéro 5: les outils
l d l• Ne pas utiliser des outils
– Traçabilité
– Planning
– Historique
• Utiliser uniquement l’email
• Trop compter sur les outilsop co pte su es out s
– Des outils comme Hudson, Sonar, FindBugs trouvent
des bugs et nous apprennent beaucoupg pp p
– Mais il ne faut pas oublier le partage de la
connaissance
18. Piège numéro 6 :
Miser tout sur le Pair Programming
i i• Le Pair Programming
– Revue de code en continu
– Très efficace pour trouver des bugs
et pour favoriser la connaissance
• Mais
– L’examinateur – très impliqué dansLexaminateur très impliqué dans
le code
– Trop coûteux à implémenterTrop coûteux à implémenter
– Présence physique au même endroit
19. Bonnes pratiques : le processusBonnes pratiques : le processus
d l’é d d• Inscrire et documenter l’étape de revue de
façon formelle dans le processus de
développementdéveloppement
– à côté des best‐practices de développement dans
le wiki de l’équipe, par exempleq p , p p
• Noter le nom du reviewer dans le message de
commit
– tout comme on note le numéro du bug ou de la
tâche
• Programmer les revues comme toute autre
tâche
d d l l d h– en stand‐up meeting, dans le plan de charge, etc.
20. Bonnes pratiques :
attention aux « effets de seuil »
• Double attention (donc double revue)
– Lorsque la recette (la qualification) est q ( q )
presque finie
– Lors des « quick fix » en prodLors des « quick fix » en prod
• La correction d’un bug mineur peut
d é bl !introduire une régression bloquante !
21. Bonnes pratiques : les outilsBonnes pratiques : les outils
• Utilisez un outil pour
– Packager les changementsg g
– L'historisation des patch
Les compte rendus de revue– Les compte‐rendus de revue.
• Utilisez, de préférence, un outil qui sait gérer
les patch successifs
22. Bonnes pratiques : la méthodeBonnes pratiques : la méthode
F i t d’ d• Faire sa propre revue avant d’envoyer un code en
revue
– Éviter un Review Failed pour des points évidents.p p
• Faire une revue rapide avant mise à jour de son
espace de travail (Update)
Au moins le titre du change la liste des fichiers l'auteur– Au moins le titre du change, la liste des fichiers l'auteur
et le reviewer
• Faire toujours une revue de code même si vous
’ èn’avez pas de collègue qui connaisse votre
technologie
– Prenez le PO, le MOA, un développeur Delphi etPrenez le PO, le MOA, un développeur Delphi et
montrez lui votre changement ou,
– Au pire, faites votre propre revue le lendemain matin.
23. Exemple : mozilla orgExemple : mozilla.org
• Revue obligatoire pour pouvoir commiter
• Intégration du processus dans Bugzilla• Intégration du processus dans Bugzilla
• Listes d’examinateurs « accrédités » par
area et sous‐modulearea et sous‐module
• « Super‐review » nécessaire dans certains
cas avec une « Super‐Review Policy » biencas avec une « Super Review Policy » bien
définie
• « Ui‐review » pour IHM et User« Ui review » pour IHM et User
Experience
25. OutilsOutils
• C d C ll b t d S tB• Code Collaborator de SmartBear
– Intégration avec les gestionnaires de code source et avec les
gestionnaires des anomalies
Atl i C ibl• Atlassian Crucible
– Intégration avec JIRA et les autres outils Atlassian
• Eclipse + Bugzilla + Splinter + Mylyn + patch (CVS, SVN)
– Intégration avec l’IDE, possibilité de faire plus que juste
regarder le code
• Gerrit Code Review
– Revue de code et gestion des projets Git en‐ligne
• Rietveld
– Code Review pour Subversion hébergé sur Google App Engine– Code Review pour Subversion, hébergé sur Google App Engine
• Review Board
– Interface web sous licence MIT