Réécrire une application, la meilleure des pires idées !

On l’a tous pensée au moins une fois: “Et si on refaisait tout de zéro ?”

Aujourd’hui, je vais vous montrer pourquoi c’est souvent… la pire des idées.

Et surtout, quoi faire à la place pour livrer plus vite, avec moins de risques, tout en gardant notre PO, l'équipe de support et les ventes… heureux.

Transcript

1. Réécrire une application, la meilleure des pires idées ! Comment éviter le Big Bang et garder tout le monde heureux
2. Dev, Ops, Cloud Architect, Mentor Chief Architect @ Paren Docker Captain jmaitrehenry.ca Julien Maitrehenry linkedin.com/in/jmaitrehenry github.com/jmaitrehenry 2
3. Introduction Qui a déjà vécu une réécriture complète ? Combien d'entre vous referaient la même chose ? 3
4. Pourquoi on veut réécrire ? Code spaghetti Techno obsolète Pression business Tentation de re-écrire Réécrire, c’est promettre d'aller sur la lune … avec le budget d’une ampoule neuve Bugs 4
5. Les dangers du Big Bang Risques Temps • • • • Coût énorme et imprévisible Perte de connaissance métier implicite Dérive du scope Gel de la valeur pendant des mois Définition : Migration complète et simultanée de tous les systèmes, données et utilisateurs vers le nouvel environnement, à une date précise. (SAAQclic?) 5
6. Quand la réécriture est justifiée ? OUI ✅ NON ❌ Changement de domaine Dette technique gérable Techno morte Fonctionnalités stable Exigence de sécurité/compliance inatteignable Time to Value critique / court 6
7. Alternatives à la réécriture • • • Refactoring incrémental Strangler pattern / Branch by Abstraction Modularisation progressive Legacy Nouveau Legacy Nouveau Routeur Strangler pattern Branch by Abstraction Legacy Client A Service A Solution hybride Client B Service B 7
8. Sécuriser le changement • • • • • Tests de caractérisation Pyramide inversé Feature toggles & dark launching Observabilité Progressive delivery En migration, votre vraie super-puissance, c’est le bouton “désactiver”. Qui connait mieux son fonctionnement que le code lui même ? 8
9. Plan d’action La victoire, ce n’est pas un nouveau repo; c’est un ancien module en moins 9
10. Conclusion Avant de tout jeter, voyons ce qu’on peut sauver • • • La réécriture séduit mais induit un risque important L’incrémental est plus sûr, plus vendable, et plus apprenant Si réécriture, alors sans Big Bang: par domaines, par modules, avec des filets de sécurité Règle d’or : éviter un SAAQclic Big Bang 10