La revue de code: une arme secrète à portée de tous

Avez-vous déjà passé des heures sans pouvoir déchiffrer le code d’un tiers? Votre application ne fonctionne pas et vous ne savez pas pourquoi. Le temps presse et vous ne pouvez manquer la date limite prévue, votre arme secrète: la revue de code. Quels sont les avantages? Comment démarrer une bonne revue de code? Quels sont les meilleurs outils? WordPress.com propulse des millions de sites web. Leur service VIP, pour les grandes entreprises, reçoit à lui seul reçoit 2,5 milliards de pages vues par mois. En misant sur WordPress.com, on ne peut pas se tromper. Venez assister à une introduction sur les bonnes techniques qu’on peut mettre en place, et ce, peu importe l’échelle.

******
Shannon Smith est spécialiste plateforme-service au sein des services VIP de WordPress.com. Elle livre des solutions de contenu aux plus grands noms en média, marketing, et affaires. Shannon détient plus de 15 ans d’expérience dans le domaine des intégrations de source libre. Longuement partisane de la diversité, de l’accessibilité, et de l’internationalisation, elle a été organisatrice de la communauté WordPress Montréal durant sept ans. Shannon est également adepte de plein air, poétesse et mère de quatre enfants.

Transcript

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

   View Slide

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

   View Slide

3. C’est quoi encore
   la revue de code?
   

   View Slide

4. 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
   

   View Slide

5. 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?
   

   View Slide

6. La revue de code
   WordPress VIP
   

   View Slide

7. 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
   

   View Slide

8. View Slide

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

   View Slide

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

    View Slide

11. –David Parsons, USA Today
    “Working with WordPress.com VIP 

    allows our team to focus on building
    awesome stuff”
    

    View Slide

12. 100 pour cent distribué
    

    View Slide

13. 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é
    

    View Slide

14. …et pourquoi
    la revue de code?
    

    View Slide

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

    are 55 and 60 percent.”
    

    View Slide

16. –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
    

    View Slide

17. 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
    

    View Slide

18. La revue de code :
    quels sont les enjeux?
    

    View Slide

19. 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
    

    View Slide

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

    View Slide

21. 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
    

    View Slide

22. 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
    

    View Slide

23. … 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
    

    View Slide

24. … 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
    

    View Slide

25. Le pratico-pratique, SVP?
    

    View Slide

26. 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
    

    View Slide

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

    View Slide

28. 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/
    

    View Slide

29. 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
    

    View Slide

30. Autres outils
    - Phabricator
    - linters
    - tiers produits
    

    View Slide

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

    View Slide

32. …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
    

    View Slide

33. 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
    

    View Slide

34. 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
    

    View Slide

35. –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
    

    View Slide

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

    View Slide

37. vip.wordpress.com/jobs
    

    View Slide