100 % de revue de code
Coucou c'est moi
 |
dev web <3 CSS <3 git #grammarNazi |
Keskédi ?
- Contexte
- Comment on fait nos revues de code
- Pourquoi ça nous plaît
- Vos devoirs à la maison
Contexte
The ebook alternative
« Nos ebooks sont chouettes ! »
À Lyon
15 personnes
Client final
Attention au bus factor
Nos anciennes
revues de code
Interruptions…
Pull request ?
git checkout -b myfeature
git commit
git push
Pendant ce temps,
dans Hipchat
Et sur github
Historique des commits
Lecture du diff
Technologiiie !
Mise à jour du code après les retours
Nettoyage de la vue « conversation »
Un an plus tard…
Comment arriver à
100 % de revue de code ?
Créer des pull request
pour tout !
Pour les nouvelles
fonctionnalités…
Pour les bugfix…
…et même pour les hotfix !
(= les bugs urgents en prod)
…et les cow-boys
(= les modifs en vim en prod)
PR « validée » ?
PR « validée » ?
PR « validée » ?
Les bénéfices
On apprend
On teste mieux
On écrit mieux !
On évite des bugs
En règle générale :
la qualité du code augmente
Les images bêtes
L'asynchronicici… nici…
C'est asynchrone, quoi
Historique exploitable
Les PR c'est chouette, mais…
Quelques points de
vigilance
Pas boulette-proof
Elle est où la boulette ?
Oh la voilà !
La revue de code
ne remplace pas
les tests
automatisés
…ni une bonne
conversation
Vos devoirs à la maison
(Oui, pour vous !)
On peut installer des outils à la maison !
Par exemple, Crew.
On peut faire de la CR sur SVN, mercurial, bazaar, CVS…
Par exemple, avec Phabricator, Review board, Crucible…
Si.
Mais si, voyons !
Expérimenter sur 1 mois ?
En résumé
- Les PR sont
- bonnes pour le code ;
- profitables aux développeurs ;
- pas chères.
- Vous devez aussi faire des PR chez vous !
Voilà. |
|
Allez-y ! Revoyez ! Et racontez-moi ce que ça donne : |
(On recrute, |