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 full-size slide

  2. un problème

    plusieurs solutions

    View full-size slide

  3. Des solutions pas 

    forcément adaptées

    View full-size slide

  4. Ou vraiment 

    surdimensionnées

    View full-size slide

  5. « To patch or not to patch »

    View full-size slide

  6. http://xkcd.com/1495/

    View full-size slide

  7. http://xkcd.com/844/

    View full-size slide

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

    View full-size slide

  9. http://xkcd.com/1425/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. Profession : pompier du code

    View full-size slide

  15. Pompier :
    50% d’entraînement
    40% prévention
    10% extinction
    pour un vrai feu : composer le 18
    pour du code pourri : [email protected]

    View full-size slide

  16. 1. Dette technique ?

    View full-size slide

  17. 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 full-size slide

  18. 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 full-size slide

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

    View full-size slide

  20. La dette est inévitable

    View full-size slide

  21. La dette est nécessaire

    View full-size slide

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

    View full-size slide

  23. Ç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 full-size slide

  24. 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 full-size slide

  25. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. 2. Prévention

    View full-size slide

  30. Trop de fonctionnalités

    View full-size slide

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

    View full-size slide

  32. Éviter les effets tunnels !

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  35. 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 full-size slide

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

    View full-size slide

  37. Le pouvoir du non

    View full-size slide

  38. Le pouvoir du non
    « pas maintenant »

    View full-size slide

  39. Prise de décisions

    View full-size slide

  40. 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 full-size slide

  41. 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 full-size slide

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

    entre le décisionnaire 

    et les techniciens

    View full-size slide

  43. On ne peut pas se
    permettre de…

    View full-size slide

  44. Tolérance aux échecs

    View full-size slide

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

    View full-size slide

  46. Stimuler les intervenants

    View full-size slide

  47. Culture, empathie !

    View full-size slide

  48. privilégier les valeurs partagées 

    à l’excellence technique

    View full-size slide

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

    View full-size slide

  50. Frustration
    vs
    projet qui avance ?

    View full-size slide

  51. Acceptation de l’échec

    View full-size slide

  52. Gestion du code

    View full-size slide

  53. 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 full-size slide

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

    View full-size slide

  55. Théorie de la
    Joconde

    View full-size slide

  56. Règle des boyscouts

    View full-size slide

  57. Attention à l'égo

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  61. 3. Éteindre l’incendie

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  64. 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 full-size slide

  65. • 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  69. Le succès


    n’est pas toujours ce que l’on voit

    View full-size slide

  70. 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 full-size slide