Du sang neuf dans des vieux pots
Par Sunny Ripert
- Mini-conf (30 mn) :
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.
- Slide: KissKissBankBank
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
- Source de bugs
- Ralentit la compréhension des bugs
- Ralentit la réparation des 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
- Le code est à destination des développeurs
- Le code est lu beaucoup plus qu'il n'est écrit
TODO: chiffres
- Du code expressif, bien nommé, qui révèle ses intentions
- Assez clair pour ne pas nécessiter de documentation
- Propre et uniforme
Slide : Du code de qualité
- Ne se répète pas grâce à des décisions centralisées (DRY)
- Qui suit les bonnes pratiques et les design patterns éprouvés
Slide : Du code testé
- Des spécifications claires
- Des filets de sécurité
- Permettent de changer le code
- Ça peut faire peur de se dire qu'il faut écrire deux fois plus de code, mais en réalité la vitesse de frappe au clavier n'est pas le facteur limitant de la vitesse des devs, c'est plutôt les réunions, les spécifications, la documentation, comprendre et réparer des bugs
Slide : Du code changeable
- Accepter qu'on a jamais les spécifications parfaites en amont
- Anticiper le futur est voué à l'échec
- La moitié du temps d'un dev est de s'adapter aux décisions prises précédemment (Capers Jones, Patters of Software System Failures)
- Simple à modifier, à mettre en ligne, à maintenir et à étendre
Comment on y va
Slide : Comment on y va ?
Slide : Décider que chaque nouvelle ligne de code adopte les bonnes pratiques
- Tirer un train dans le sable
- Expressif, suit les designs patterns, testé, etc.
- Y compris les anciennes lignes que l'on modifie
Slide : Tout changement doit être revu par au moins une autre personne de l'équipe
- Pull-Requests (PRs)
- Un vrai changement au sein de KissKissBankBank
- Peut être reçu avec difficulté au départ lorsqu'on a pas l'habitude
- Meilleure façon pour s'assurer collectivement de suivre ce qu'on s'est fixés
- Meilleure façon d'avoir un style commun, du code partagé
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.
- Code lu plus qu'il n'est écrit, donc prendre le temps d'écrire est vite rattrappé
- La vélocité 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
- La précipitation ralentit
- Ça n'empêche pas d'accepter de la dette parfois tant qu'on la repaye plus tard
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
- Se rappeller que tous les devs partent avec les meilleurs intentions
- Faire des choix ensemble sur le style commun
- Démarrer une discussion à chaque ligne de code n'est pas très claire
- Le code appartient à tous
- Dans les revues il n'y a pas de "mon code" ou "ton code"
- Faire du pair-programming
Slide : Refaire fonctionnalité par fonctionnalité
- Refaire une fonctionnalité à la fois
- Vous aurez l'aide du business, des gens qui vont réfléchir et tester vos modifications
- Beaucoup plus facile à vendre qu'une refactorisation qui n'apporte pas de valeur visible
Slide : Faire des petits changements
- Plus faciles à faire de la revue
- Plus facile à comprendre, à annuler
Slide : Célébrer
- Célébrer les petites réfactorisations de vieux code
- Célébrer les suppressions de code
TODO: Captures d'écran de cœurs sur des PRs de suppression de code sur GitHub.
Slide : Reconnaître les erreurs
- Reconnaître que les bugs viennent du process, pas des gens
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
- Feedback instantané, trouver les problèmes le plus tôt possible
- Plus petits bugs
- Moins de risque liés à l'incertitude de la production
- Réduire les étapes humaines en automatisant un maximum
Slide : Déploiement continu : Déployez les vendredis
- J'étais un fervent défenseur de ne pas déployer le vendredi
- Plutôt que d'accepter que déployer est un risque, on peut le combattre en le réduisant
- Plus petits déploiements, mieux testé, mieux automatisé
- À KissKiss on déploie souvent plus d'une quinzaine de fois dans la journée
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).
- Intégration continue
- Livraison continue
- Déploiement continu
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 :
- le goût du détail
- bonne communication
- une excellence technique
- l'envie de partager
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
- Parler de valeur et de risque avec le business
- Du code testé
- Pas à pas meilleur niveau business
- Plus agile
- Déploiements non-evenements
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
- Meilleur dialogue avec le business
Parce que :
- le code sera plus simple
- changements seront plus découpés
vous aurez déjà une partie en ligne
Pas besoin de demander 6 mois pour refaire toute l'architecture si vous le faites au fur et à mesure des fonctionnalités
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 ?