une arme secrète à portée de tous Web à Québec La revue de code : Québec, avril 2018 

Shannon Smith https://vip.wordpress.com Spécialiste plateforme-service, Automattic / WordPress.com VIP 

C’est quoi encore la revue de code? 

La revue de code S’appuie sur la vérification (manuelle ou automatisée) du respect d'un ensemble de règles de programmation https://fr.wikipedia.org/wiki/Revue_de_code 

Découvrir les possibilités… Une arme secrète à portée de tous - S’appuyer sur l’expérience VIP - Quels sont les enjeux? - Quels sont les avantages? - Comment démarrer une bonne revue de code? 

La revue de code WordPress VIP 

WordPress.com VIP - les vues de page par mois : 2.5 milliard - la durée de fonctionnent (uptime) : 99.9976% - le temps de réponse : 349 ms - https://vip.wordpress.com 

No content

Tout le code sur notre plateforme est sujet à une revue de code. 

Pourquoi la revue de code sur WordPress VIP? - une plateforme partagée - une achalandage importante - la sécurité et la performance 

–David Parsons, USA Today “Working with WordPress.com VIP 
 allows our team to focus on building awesome stuff” 

100 pour cent distribué 

Pourquoi la revue de code adapté à vos besoins? 1. la sécurité - le XSS, l'Open Web Application Security Project (OWASP) - lèéchappement, la nettoyage, la validation 2. le performance - les requêtes intélligents, la bonne utilisation du cache, le code DRY (don’t repeat yourself) - la modularité 3. la lisibilité - la collaboration - le respect des standards - la continuité 

…et pourquoi la revue de code? 

–Steve McConnell (Book: “Code Complete”) “the average [defect detection] effectiveness [rate] of design and code inspections 
 are 55 and 60 percent.” 

–Jeff Atwood “Development projects with code review have significantly fewer bugs, reduced development costs, increased productivity, and early ship dates.” http://blog.codinghorror.com/code-reviews-just-do-it 

Ces bogues qui coutent si cher… - la correction de défauts coûte moins cher plus qu’on y travail - les projets où l’on corrige < 85% des défauts seront en retard, hors budget, avec des clients insatisfaits - les projets où l’on corrige > 95% des défauts seront généralement livrés à temps, respectent le budget, et laissent les clients satisfaits http://www.ifpug.org/Documents/Jones-CostPerDefectMetricVersion4.pdf 

La revue de code : quels sont les enjeux? 

Les outils automatisés - PHP_CodeSniffer - les standards de code WordPress 
 (un projet communautaire de source libre) - les standards de code VIP - l’intégration continue (Travis CI ou Circle CI) dans Github 

La revue de code manuelle - par ses pairs - par la communauté (source libre) - par un tiers service 

On cherche quoi? - Le respect des standards de code - Une manque d’erreurs/d’avertissements - Une bonne logique - La facilitation de la performance - Le code sécuritaire 

Des exemples plus précis? - La validation, la nettoyage et l’échappement - les javascript avec XSS - du PHP avec ou le cache est sous-optimisé - une consommation logique par les API - des requêtes sur la base de données trop exigeants - le respect des standards et les bonnes pratiques - les coquilles 

… et si on pensait d’abord à l’équipe? - la programmation plus efficace - une collaboration facile et standardisée - le débogage accéléré - la participation de la communauté source libre 

… et si on pensait d’abord à soi? - on devient meilleur dévelopeur - on obtient de d’expérience par osmose - les standards de code deviennent internalisés 

Le pratico-pratique, SVP? 

Le méthode WordPress.com VIP - le client soumet du code - un diff est créé - nos développeurs font une revue de code - les commentaires sont partagées / une discussion a lieu - l’approbation ou la révision 

Un travail à la grande échelle - 9.5+ millions de lignes de code - 144 000 déploiements - le temps moyen ~ 2 h 

Github - le modèle Git Flow (Vincent Driessen) - les pull Request (PR) - la documentation, les commentaires dans le code source - les diffs (la comparaison de fichiers) - le travail en partenaires vs. en équipes transverses http://nvie.com/posts/a-successful-git-branching-model/ 

Time release branches master develop hotfixes feature branches Feature for future release Tag Major feature for next release From this point on, “next release” means the release after 1.0 Severe bug fixed for production: Bugfixes from rel. branch may be continuously merged back into develop Tag Tag Incorporate bugfix in develop Only bugfixes! Start of release branch for Author: Vincent Driessen Original blog post: http://nvie.com/archives/323 License: Creative Commons 

Autres outils - Phabricator - linters - tiers produits 

Comment faire en équipe? - personne fait un merge de son propre PR - diffs pour faciliter la tâche - offre des commentaires 

…et si j’étais seul? - les outils automatisés - créer des diffs - dormir et réviser / le matin et l'après-midi - faites des commentaires / de la documentation - créer une espace entre la programmation et le déploiement 

Combattre les excuses… - mais… on est sensé s’y connaître dans la domaine! - mais… ce n’est pas mon projet - mais… il n’y a pas de temps 

Euh, pourquoi on ne m’aime plus… - un travail sans ego - un travail difficile, la bonne communication est clé - l'empathie - l'accent sur le code et non pas la personne (aucun pronom personnel) - pas de “oui, mais…” - aucune assomption et beaucoup de questions 

–Jeff Atwood “[P]eer code reviews are the single biggest thing you can do to improve your code. If you’re not doing code reviews right now with another developer, you’re missing a lot of bugs in your code and cheating yourself out of some key professional development opportunities. As far as I’m concerned, my code isn’t done until I’ve gone over it with a fellow developer. http://codinghorror.com 

Web à Québec Québec, avril 2018 Questions? 

vip.wordpress.com/jobs