#BlendWebMix2016 To patch or not to patch

Face à un problème, on a toujours la solution de corriger « the right way » ou de patcher comme un cochon. Une tonne d’impératifs, de mauvaises habitudes nous poussent souvent à patcher.
À l’inverse, de nombreux développeurs manquent parfois de pragmatisme et partent sur une implémentation trop poussée qui porte à créer d’autres problèmes de surqualité…
C’est donc une histoire de compromis et cette conférence peut vous donner quelques pistes de solutions et des astuces.

—
De la théorie, des exemples, un véritable retour d’expérience d’horreurs et de trucs marrants ou pratiques constatés « dans la vraie vie™ ».

http://www.blendwebmix.com/programme/to-patch-or-not-to-patch.html

Transcript

1. « To patch or not to patch »
3. CREVAISON
4. un problème … plusieurs solutions
5. Des solutions pas 
 forcément adaptées
6. Ou vraiment 
 surdimensionnées
7. « To patch or not to patch »
8. http://xkcd.com/1495/
9. http://xkcd.com/844/
10. http://www.commitstrip.com/fr/ 2015/01/28/looks-can-be- deceiving/
11. http://xkcd.com/1425/
13. http://www.commitstrip.com/wp-content/uploads/2012/09/Strips-Hackaton-550-final.jpg
14. https://www.kickstarter.com/projects/commitstrip/commitstrip-rise-of-the-coders-a-book-about-the-fu
15. Bastien Jaillot – @bastnic Je suis fainéant pragmatique ಠ_ಠ
16. Conseil, réalisation, audit, expertise et formation ...Poney, Guinness et gif animé.
17. Profession : pompier du code
18. Pompier : 50% d’entraînement 40% prévention 10% extinction pour un vrai feu : composer le 18 pour du code pourri : coucou@jolicode.com
19. 1. Dette technique ?
20. Quand on code au plus vite et de manière non optimale, on contracte une dette technique que l'on rembourse tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents
 
 — Wikipedia, « Dette technique »
21. La dette technique est un emprunt sur la qualité. Elle est donc utile car elle permet de faire avancer le projet plus vite à court terme Elle devient problématique quand le coût de développement d'une fonctionnalité devient supérieur à ce qu'elle peut rapporter … et que ça gonfle tous les développeurs
22. http://slides.com/maximethoonsen/agile-technical-debt-forum-php#/10
23. La dette est inévitable
24. La dette est nécessaire
25. http://www.commitstrip.com/fr/2014/09/08/the-other-infinite-loop-that-all-coders-fear/
26. Ça vous rappelle quelque chose ? • Vous ne comprenez pas pourquoi des règles de gestions validées 10x reviennent sur le tapis ; • Pourquoi c'est impossible de recruter ? et de conserver vos équipes ; • Pourquoi alors qu'avant tout allait vite et bien et tout le monde était content, maintenant tout met des mois ; • On vous a convaincu que PHP c'est pour les losers, donc votre site est en ruby ou en python, et maintenant qu'il faut le maintenir, il n'y a plus personne ? • Pareil pour du magento ; • Vous n'avez jamais fait évoluer votre Drupal 6 et maintenant soit il fonctionne "tomber en marche », soit il ne fonctionne pas et personne ne sait pourquoi dans les deux cas.
27. Conséquences / Symptômes ? (court terme) • Fonctionnel qui peut sortir plus vite ? • Fonctionnel qui sort pour moins cher ; • Le sentiment de ne « pas se faire avoir par la technique » : pourquoi payer 20 jours ce que l’on peut avoir en 2 ?
28. Conséquences / Symptômes ? (long terme) • Bugs à tout va, perte de qualité ; • Perte de célérité ; • Démissions ; • Difficulté de recrutement ; • Tout jeter ? • Fermer la boîte ?
29. Impacts ? besoin fonctionnel > besoin technique … un problème humain plutôt que technique
30. Impacts ? les développeurs peuvent quitter le projet critique pour le client à long terme
31. la somme des fonctionnalités qui n'auraient jamais du voir le jour + la sédimentation naturelle du code… + les mauvaises volontés.
32. 2. Prévention
33. Trop de fonctionnalités
34. Moment « impact social et sociétal du web, comment il change le monde ? »
36. Éviter les effets tunnels !
37. qu’est qu’un projet « terminé » ? http://www.commitstrip.com/fr/2015/03/04/and-its-done/
38. Pas comme ça : Comme ça ! Itérations !
39. Comment vendre des prestations agiles à ses clients ? Thibault Jouannic – Sud Web 2012 https://www.miximum.fr/blog/comment-vendre-des-prestations-agiles-a-ses-clients/
40. Le meilleur code est celui qui n’a jamais besoin d’être écrit
41. Le pouvoir du non
42. Le pouvoir du non « pas maintenant »
43. Prise de décisions
44. Toute méthode de gestion de projet qui n'est pas basée sur un échange permanent entre un client et son prestataire est vouée à l'échec Thibault Jouannic
45. Une relation client sympa qui vire au cauchemar, ça arrive. Une relation client de merde qui vire à l’idylle, jamais. Fuyez, dès le début.. Christophe Andrieu – @STPO
46. Réduire le nombre d’intermédiaires
 entre le décisionnaire 
 et les techniciens
47. On ne peut pas se permettre de…
48. Tolérance aux échecs
49. On a vite fait de ne penser qu’à ses intérêts
50. #nobullshit
51. Stimuler les intervenants
52. Culture, empathie !
53. privilégier les valeurs partagées 
 à l’excellence technique
54. • Formation, conférence • veille technique • revue de code, mentoring • Paternité du code partagée (collective code ownership) • responsabiliser sans rendre dépendant
55. Frustration vs projet qui avance ?
56. Acceptation de l’échec
57. Gestion du code
58. There are only two types of code, code that delivers business value, and code that doesn’t. The cleanest code that doesn’t deliver value is still crap — Anthony Ferrara in Beyond Clean Code
59. Théorie de la fenêtre brisée
60. Théorie de la Joconde
61. Règle des boyscouts
62. Attention à l'égo
63. Surqualité
64. Caricature : intégration continue, sass, npm, webpack… pour une landing page
65. sur-coder vous rend indispensable (et ce n’est cool pour personne)
66. attention au pompier pyromane (http://www.geek-directeur-technique.com/2016/08/27/les-pompiers-pyromanes)
67. 3. Éteindre l’incendie
68. Attention au charme de la réécriture de zéro !
69. http://www.commitstrip.com/fr/2016/10/31/bohemian-coder/
70. Tout projet informatique sérieux doit commencer par un dénigrement systématique du travail effectué par les développeurs précédents -- Tous les développeurs, un jour, y compris envers soi-même
71. • Identifier les vrais points de blocage fonctionnels (règle des 80/20 : trouver ce qui apporte 80% de la valeur pour 20% du prix) ; • Construire des ponts ; • Surtout ne pas toucher à ce qui fonctionne ; • Déployer rapidement.
72. Chaque situation est différente, faites vous conseiller.
73. L'ennemi de la dette technique, c'est le pragmatisme.
74. https://fr.wikipedia.org/wiki/Gouvernement_ouvert#/media/File:D%C3%A9mocratie_Ouverte.png
75. Le succès
 
 n’est pas toujours ce que l’on voit
76. Crédits • Rustine • Vélo 1 / Vélo 2 / Chris Froome • Cedric Sacilotto – Pompier • ICS Students learn Fire Prevention • Tunnel • Couteau suisse géant • Légo • Sablier • Code Matrix • Tank • Pistolet • Échafaudage • Fenêtre brisée