Pro Yearly is on sale from $80 to $50! »

#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

87137598c23e3e90755e5d7476d21405?s=128

Bastien Jaillot

November 02, 2016
Tweet

Transcript

  1. « To patch or not to patch »

  2. None
  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/

  12. None
  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 ? »
  35. None
  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