#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. 2.
  2. 12.
  3. 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
  4. 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 »
  5. 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
  6. 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.
  7. 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 ?
  8. 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 ?
  9. 31.

    la somme des fonctionnalités qui n'auraient jamais du voir le

    jour + la sédimentation naturelle du code… + les mauvaises volontés.
  10. 35.
  11. 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/
  12. 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
  13. 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
  14. 54.

    • Formation, conférence • veille technique • revue de code,

    mentoring • Paternité du code partagée (collective code ownership) • responsabiliser sans rendre dépendant
  15. 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
  16. 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
  17. 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.
  18. 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