#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 »
   

   View Slide

2. View Slide

3. CREVAISON
   

   View Slide

4. un problème
   …
   plusieurs solutions
   

   View Slide

5. Des solutions pas 

   forcément adaptées
   

   View Slide

6. Ou vraiment 

   surdimensionnées
   

   View Slide

7. « To patch or not to patch »
   

   View Slide

8. http://xkcd.com/1495/
   

   View Slide

9. http://xkcd.com/844/
   

   View Slide

10. http://www.commitstrip.com/fr/
    2015/01/28/looks-can-be-
    deceiving/
    

    View Slide

11. http://xkcd.com/1425/
    

    View Slide

12. View Slide

13. http://www.commitstrip.com/wp-content/uploads/2012/09/Strips-Hackaton-550-final.jpg
    

    View Slide

14. https://www.kickstarter.com/projects/commitstrip/commitstrip-rise-of-the-coders-a-book-about-the-fu
    

    View Slide

15. Bastien Jaillot – @bastnic
    Je suis fainéant pragmatique ಠ_ಠ
    

    View Slide

16. Conseil, réalisation, audit,
    expertise et formation
    ...Poney, Guinness et gif animé.
    

    View Slide

17. Profession : pompier du code
    

    View Slide

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
    

    View Slide

19. 1. Dette technique ?
    

    View Slide

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 »
    

    View Slide

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
    

    View Slide

22. http://slides.com/maximethoonsen/agile-technical-debt-forum-php#/10
    

    View Slide

23. La dette est inévitable
    

    View Slide

24. La dette est nécessaire
    

    View Slide

25. http://www.commitstrip.com/fr/2014/09/08/the-other-infinite-loop-that-all-coders-fear/
    

    View Slide

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.
    

    View Slide

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 ?
    

    View Slide

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 ?
    

    View Slide

29. Impacts ?
    besoin fonctionnel > besoin technique
    … un problème humain plutôt que
    technique
    

    View Slide

30. Impacts ?
    les développeurs peuvent quitter le projet
    critique pour le client à long terme
    

    View Slide

31. la somme des fonctionnalités qui n'auraient
    jamais du voir le jour
    + la sédimentation naturelle du code…
    + les mauvaises volontés.
    

    View Slide

32. 2. Prévention
    

    View Slide

33. Trop de fonctionnalités
    

    View Slide

34. Moment
    « impact social et sociétal
    du web, comment il
    change le monde ? »
    

    View Slide

35. View Slide

36. Éviter les effets tunnels !
    

    View Slide

37. qu’est qu’un
    projet
    « terminé » ?
    http://www.commitstrip.com/fr/2015/03/04/and-its-done/
    

    View Slide

38. Pas comme ça :
    Comme ça !
    Itérations !
    

    View Slide

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/
    

    View Slide

40. Le meilleur code est
    celui qui n’a jamais
    besoin d’être écrit
    

    View Slide

41. Le pouvoir du non
    

    View Slide

42. Le pouvoir du non
    « pas maintenant »
    

    View Slide

43. Prise de décisions
    

    View Slide

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
    

    View Slide

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
    

    View Slide

46. Réduire le nombre d’intermédiaires

    entre le décisionnaire 

    et les techniciens
    

    View Slide

47. On ne peut pas se
    permettre de…
    

    View Slide

48. Tolérance aux échecs
    

    View Slide

49. On a vite fait de ne penser qu’à ses intérêts
    

    View Slide

50. #nobullshit
    

    View Slide

51. Stimuler les intervenants
    

    View Slide

52. Culture, empathie !
    

    View Slide

53. privilégier les valeurs partagées 

    à l’excellence technique
    

    View Slide

54. • Formation, conférence
    • veille technique
    • revue de code, mentoring
    • Paternité du code partagée (collective code ownership)
    • responsabiliser sans rendre dépendant
    

    View Slide

55. Frustration
    vs
    projet qui avance ?
    

    View Slide

56. Acceptation de l’échec
    

    View Slide

57. Gestion du code
    

    View Slide

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
    

    View Slide

59. Théorie de la fenêtre brisée
    

    View Slide

60. Théorie de la
    Joconde
    

    View Slide

61. Règle des boyscouts
    

    View Slide

62. Attention à l'égo
    

    View Slide

63. Surqualité
    

    View Slide

64. Caricature : intégration continue, sass,
    npm, webpack… pour une landing page
    

    View Slide

65. sur-coder vous rend indispensable
    (et ce n’est cool pour personne)
    

    View Slide

66. attention au pompier pyromane
    (http://www.geek-directeur-technique.com/2016/08/27/les-pompiers-pyromanes)
    

    View Slide

67. 3. Éteindre l’incendie
    

    View Slide

68. Attention au charme de la
    réécriture de zéro !
    

    View Slide

69. http://www.commitstrip.com/fr/2016/10/31/bohemian-coder/
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

72. Chaque situation
    est différente, faites
    vous conseiller.
    

    View Slide

73. L'ennemi de la dette
    technique, c'est le
    pragmatisme.
    

    View Slide

74. https://fr.wikipedia.org/wiki/Gouvernement_ouvert#/media/File:D%C3%A9mocratie_Ouverte.png
    

    View Slide

75. Le succès

    

    n’est pas toujours ce que l’on voit
    

    View Slide

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
    

    View Slide