Upgrade to Pro — share decks privately, control downloads, hide ads and more …

#BlendWebMix2016 To patch or not to patch

#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

Bastien Jaillot

November 02, 2016
Tweet

More Decks by Bastien Jaillot

Other Decks in Programming

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 : [email protected]

    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