Aller au contenu

Du sang neuf dans des vieux pots

Par Sunny Ripert

Mini-conf (30 mn) :
Langue :
Français

Liens connexes

Le sujet

Face à du code dépassé, quelle est la meilleure stratégie pour avancer ? Comment font les grandes bases de code pour évoluer ? À la place de l'idée séduisante de la grande refonte qui n'arrivera jamais, j'aimerais vous proposer la vision plus douce et plus pragmatique de l'amélioration continue. Je veux partager mon expérience ainsi que les méthodologies que l'on met en place chez KissKissBankBank pour modifier l'architecture et permettre à toute l'équipe d'augmenter la qualité de ce que l'on produit, malgré une base de code vieillissante. Revue de code, automatisation, désappropriation du code, tests de faisabilité, introduction de nouvelles technologies, responsabilité des développeurs… Nous verrons comment faire vivre l'ancien et le nouveau, main dans la main. Ça sera émouvant.

Présenté par

Transcription

Introduction

Slide : (Dessin d'aventuriers médiévaux dans une mine fâce à un démon)

Vous êtes des aventuriers dans une mine profonde, quand soudain vous croisez une créature démoniaque : du vieux code legacy.

Slide : Sunny

Bonjour ! Je m'appelle Sunny.

Slide : cults3d.com

Site autour de l'impression 3D.

Site de financement participatif.

Une fois par semaine on est un petit groupe à jouer à Donjons et Dragons, ce qui explique mon intro.

Slide : Du sang neuf dans des vieux pots

Mais le reste du temps quand on travaille on croise aussi des morceaux de nos applications qui font parfois très peur.

Je veux vous parler de quelques pistes pour arrêter d'en avoir peur.

Legacy

Slide : “Legacy code”

"Legacy" c'est la part des morts qui survit.

C'est un terme positif, sauf lorsqu'on l'applique à du code.

Slide : (liste de définitions)

“Le code écrit par d'autres” “Du vieux code” “Tout code dès qu'on l'écrit” “Du code qu'une seul personne connaît” “Du code sans tests” “Du code qu'on ne comprends pas” “Du code difficile à modifier”

“Du code sans tests” est de Michael Feathers, auteur du livre “Working Effectively with Legacy Code”. La dernière c'est ma définition. Celle que je préfère parce que je considère que c'est le défaut principal qui nous empêche d'avancer.

Slide : (citation)

Kipple is useless objects, like junk mail or match folders after you use the last match [...]

When nobody's around, kipple reproduces itself. For instance, if you go to bed leaving any kipple around your apartment, when you wake up the next morning there's twice as much of it. It always gets more and more.

Je sors momentanément du thème Donjons et Dragons, pour rentrer dans le monde futuriste de Blade Runner.

C'est une citation de Philip K Dick dans son livre “Do Androids Dream of Electric Sheep”.

Il utilise le terme de "kipple" pour décrire l'entropie des objets qui nous entourent.

Si on ne se bat pas contre le chaos autour de nous on se réveille le lendemain et le tout aura doublé.

Le code legacy est un genre de chaos.

Slide : (homepage de KissKissBankBank en 2014)

kisskissbankbank quand je suis arrivé c'était * 3 développeurs qui avaient à peine touché à la base de code, car ils travaillaient sur deux autres sites. * les devs qui connaissaient la plateforme, eux, étaient tous partis * je découvrais des trucs très étranges toutes les semaines (ça m'arrive encore)

Coûts

Slide : Bugs

C'est le coût principal de développement.

Slide : Broken Window Theory

Le mauvais code a cette propriété à se dupliquer. Spirale de dette technique.

Code qui ne vaut plus la peine d'être amélioré, ne mérite pas notre temps.

Copy-pasta.

Kepple.

Slide : Dette technique

Ralentissement de la vélocité

Complexité à estimer

Tout réécrire

Slide : Tout réécrire

C'est très très risqué : * Ça coûte cher * Les gros chantiers sont très durs à estimer * Toujours plus compliqué que prévu * On ne connait plus toutes les règles métiers * L'application actuelle fonctionne et apporte de la valeur * Risquez de casser des parties que vous ne connaissez pas * Pendant ce temps vous bloquez les développements * Besoin de maintenir deux versions

TODO: cas de réécritures.

Slide : Réappliquer les mêmes erreurs

Risque de se retrouver avec autant de dette

KissKiss était une v2, qu'est-ce que ça a dû être la v1 !

TODO: historique de bob, rush sur la v2

Avant d'envisager une refonte complète, il faut apprendre à éviter de se retrouver dans cette situation.

Réévaluer la façon de travailler.

Ce n'est pas le code qu'il faut refaire, c'est la manière de coder.

Inverser la spirale de la dette

L'inverse du legacy

Slide : Linverse du code legacy

Quelles sont les propriétés d'un code qui ne soit pas du code legacy ?

Slide : Du code lisible

TODO: chiffres

Slide : Du code de qualité

Slide : Du code testé

Slide : Du code changeable

Comment on y va

Slide : Comment on y va ?

Slide : Décider que chaque nouvelle ligne de code adopte les bonnes pratiques

Slide : Tout changement doit être revu par au moins une autre personne de l'équipe

TODO: Mentionner présentation sur la revue de code.

Slide : (citation)

Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase. — “Barry Bohem” University of Southern California

Prendre du temps en amont coûte moins de temps qu'on l'imagine.

Le code est lu plus qu'il n'est écrit.

Ça ne veut pas dire que tout doit être parfait : on peut accepter de la dette tant qu'on la repaye plus tard.

Slide : (dessin d'égouts)

La vélocité est importante mais ce n'est pas une fin en soi : on ne construit pas les égouts d'une ville en essayant de les installer le plus rapidement possible, on réfléchit également à comment faire en sorte qu'ils soient maintenables.

Slide : Un plan de travail propre

Les plus grands chefs de brigades le savent : en cuisine, nettoyer au fur et à mesure fera gagner un temps fou.

De mon expérience les développeurs les plus rapides sont les plus rigoureux, les plus disciplinés, les plus pointilleux.

Ils vont prendre le temps de refactoriser pour se faire gagner beaucoup de temps.

Slide : Main dans la main <3

Slide : Refaire fonctionnalité par fonctionnalité

Slide : Faire des petits changements

Slide : Célébrer

TODO: Captures d'écran de cœurs sur des PRs de suppression de code sur GitHub.

Slide : Reconnaître les erreurs

Outils

Slide : Automatisation

En JavaScript on utilise Prettier qui nous permet de reformatter le code à chaque commit, pour ne plus avoir à discuter du style de code, il est forcé.

Slide : (commentaires de Kissbot sur GitHub)

On utilise également ESLint pour JavaScript et RuboCop pour Ruby pour nous notifier de bonnes pratiques automatiquement.

On les as branché à nos PRs GitHub grâce à un outil qui s'appelle Pronto.

Slide : (commentaire avec suggestion)

J'ai également modifié Pronto pour qu'il puisse nous faire directement des suggestions sur GitHub, et qu'on puisse les accepter en un clic.

Slide : (commentaire avec couverture de code)

Enfin, Pronto lance également codecov qui nous prévient si le code soumis n'est pas couvert par la suite de tests.

Le résultat est que chaque changement, même sur du vieux code, est vertueux.

Slide : Déploiement continu

Slide : Déploiement continu : Déployez les vendredis

Slide : Atelier sur le déploiement continu

Pub pour dire qu'on fait un atelier sur l'intégration continue présenté par Fanny (et moi).

Slide : Feature switching

Permets de déployer souvent de grosses features, de tester avec des vraies données, de réduire le risque.

Slide : Choisir des technologies qui permettent de ne pas tout refaire d'un coup

À KissKissBankBank on a décide d'introduire React en ne le faisant que sur un seul composant : le header.

Comme React ne faisait qu'une seule chose ça nous as permis de l'intégrer doucement.

Slide : Partager les bonnes pratiques

Maintenir une culture de partage de liens, de bonnes pratiques, de nouveautés.

Ateliers du jeudi.

Encourager à aller à des conférences.

Slide : Mentors

Bien recruter. Qualités à rechercher pour avoir moins de code legacy :

Avantages

Slide : Avantages

Ça fait beaucoup de choses à changer, mais on peut y aller progressivement.

Slide : Design émergeant

Travailler par itérations permets de mettre à l'épreuve l'existant et de découvrir la bonne solution petit à petit.

Slide : Moins de risques

Slide : Mieux comprendre

Refactoriser une partie permets de baisser le coût de relire le code plus tard, d'ajouter des tests, d'ajouter des features, de refactoriser. Quand je lis du code, le réadapter pendant que je lis m'aide à le comprendre.

Slide : Meilleurs estimations

Parce que :

Conclusion

Slide : Vie et mort

Le code est un organisme.

Il vit et meurt, tout comme des docteurs on ne peut que repousser l'inévitable en le modifiant au fur et à mesure.

Cette décision de produire de la qualité c'est notre responsabilité en tant que devs.

Commencez dès aujourd'hui.

Allez-y pas à pas.

Slide : (donjons et dragons)

Vous avez tué le monstre de ce donjon, vous gagnez tous 10 pièces d'or et 50 points d'expérience.

Maintenant, qu'est-ce que vous faites ?