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

Fausses bonnes idées & Culte du cargo - Riviera Dev 2016

Fausses bonnes idées & Culte du cargo - Riviera Dev 2016

On a tous déjà connu ce code qui parait résoudre parfaitement un problème donné, mais qui s’avère être la pire idée du monde quelques semaines ou mois plus tard.

Depuis le début de ma carrière, je note avec attention toutes ces “fausses bonnes idées”, que j’ai croisé dans les projets sur lesquels j’ai travaillé (et y compris celles dont j’ai été l’auteur).

Arnaud LEMAIRE

June 16, 2016
Tweet

More Decks by Arnaud LEMAIRE

Other Decks in Programming

Transcript

  1. FAUSSES BONNES IDÉES
    Arnaud LEMAIRE @lilobase

    View full-size slide

  2. LIVRER À TOUT PRIX

    View full-size slide

  3. NOUS SOMMES UN MÉTIER
    ANGOISSANT POUR LE CLIENT
    • Il ne comprend pas
    vraiment ce que l’on fait…
    • Et si en plus lors de la
    livraison ça ne marche pas
    correctement…

    View full-size slide

  4. UN PROBLÈME QUI
    S’AUTO-ENTRETIEN
    Stress
    du client
    Pression
    sur l’équipe
    Baisse de la
    qualité
    Bugs

    View full-size slide

  5. SOUVENT LIÉ À UN MANQUE
    DE VISION SUR LE LONG TERME
    Temps
    Fonctionnalités
    Temps
    Fonctionnalités
    6 mois

    View full-size slide

  6. -Albert Einstein
    If I were given one hour to save the planet, I would
    spend 59 minutes defining the problem and on minute
    resolving it.

    View full-size slide

  7. DATA-CENTRIC
    APPLICATIONS

    View full-size slide

  8. ON AIME BIEN LES FRAMEWORKS
    (FULL STACK)
    • Une architecture MVC
    • Des générateurs de CRUD
    • Un ORM

    View full-size slide

  9. UNE FRACTALE DE
    MAUVAISES HABITUDES
    • Une architecture MVC, qui n’est pas du tout fait pour
    architecturer des applications…
    • Des générateurs de CRUD, qui vous donnent la même
    valeur ajoutée qu’un MS Access
    • Un ORM, le truc qui déclenche 600 requêtes pours afficher
    une page et qui fait que l’on ne sait plus faire de SQL

    View full-size slide

  10. NOTRE METIER C’EST DE
    RÉSOUDRE UN PROBLÈME CLIENT
    • Et le problème d’un
    client c’est rarement
    qu’il manque de
    formulaires à remplir…

    View full-size slide

  11. - Jean Baptiste Dusseaut
    « Ces outils rendent trivial ce qui est facile, impossible
    ce qui est difficile »

    View full-size slide

  12. AU CAS OÙ…
    • Peut être que le client va
    avoir besoin de ça dans le
    futur ?
    • Peut être que je vais
    pouvoir réutiliser ce
    composant dans une autre
    application

    View full-size slide

  13. COMPLEXITÉ ACCIDENTELLE
    • La complexité accidentelle
    est très liée à la sur-
    ingénierie
    • La complexité accidentelle
    est le premier facteur de
    dette technique
    Complexité
    Le problème du client
    Tout le reste (le au cas ou)
    La complexité d’un
    projet
    est une somme :

    View full-size slide

  14. YOU AIN’T GONNA NEED IT
    • Nous sommes fiers de réaliser des choses complexes, mais
    il est important de vérifier que cette complexité n’est pas
    artificielle
    • Allez toujours à la simplicité, même si ce n’est pas toujours
    le plus facile

    View full-size slide

  15. -Fred Brooks
    « This second [system] is the most dangerous system a
    man ever designs. »

    View full-size slide

  16. EST-CE QUE ÇA SCALE ?
    • Souvent exprimé sous
    « est-ce que ça va être
    performant ? »
    • Enfin un terrain d’entente
    entre business et technique

    View full-size slide

  17. LE PROBLÈME C’EST QU’IL N’Y
    A PAS QU’UNE DIMENSION
    • Scaling en performance (ajouter des utilisateurs)
    • Scaling au niveau de l’équipe (ajouter des développeurs)
    • Scaling des fonctionnalités (ajouter des fonctionnalités)

    View full-size slide

  18. ET CE N’EST PAS CELUI QUE L’ON
    CROIT QUI POSE PROBLÈME
    • Etre capable de garder une bonne productivité est très
    difficile à optimiser à posteriori
    • C’est rarement le nombre d’utilisateurs qui a tué une boite,
    par contre ne plus pouvoir faire évoluer le logiciel…
    • Et en plus ça n’est pas linéaire…

    View full-size slide

  19. -Alan Key
    « Most software today is like an Egyptian pyramid with
    millions of bricks piled on top of each other, with no
    structural integrity, but just done by brute force and
    thousands of slaves. »

    View full-size slide

  20. CARRIÈRE
    • Croire que l’architecture est un métier à part
    • Penser que pour progresser il faut aller vers le
    management
    • Apprendre à utiliser les outils et non les notions
    sous jacentes

    View full-size slide

  21. - rasoir d'Hanlon
    « Ne jamais attribuer à la malveillance ce que
    l’incompétence suffit à expliquer. »

    View full-size slide

  22. Changer les perspectives

    View full-size slide

  23. MERCI
    @lilobase

    View full-size slide