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).

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE

June 16, 2016
Tweet

Transcript

  1. None
  2. FAUSSES BONNES IDÉES Arnaud LEMAIRE @lilobase

  3. LIVRER À TOUT PRIX

  4. 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…
  5. UN PROBLÈME QUI S’AUTO-ENTRETIEN Stress du client Pression sur l’équipe

    Baisse de la qualité Bugs
  6. SOUVENT LIÉ À UN MANQUE DE VISION SUR LE LONG

    TERME Temps Fonctionnalités Temps Fonctionnalités 6 mois
  7. -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.
  8. DATA-CENTRIC APPLICATIONS

  9. ON AIME BIEN LES FRAMEWORKS (FULL STACK) • Une architecture

    MVC • Des générateurs de CRUD • Un ORM
  10. 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
  11. 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…
  12. - Jean Baptiste Dusseaut « Ces outils rendent trivial ce

    qui est facile, impossible ce qui est difficile »
  13. COMPLEXITÉ

  14. 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
  15. 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 :
  16. 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
  17. -Fred Brooks « This second [system] is the most dangerous

    system a man ever designs. »
  18. SCALING

  19. EST-CE QUE ÇA SCALE ? • Souvent exprimé sous «

    est-ce que ça va être performant ? » • Enfin un terrain d’entente entre business et technique
  20. 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)
  21. 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…
  22. -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. »
  23. 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
  24. - rasoir d'Hanlon « Ne jamais attribuer à la malveillance

    ce que l’incompétence suffit à expliquer. »
  25. Changer les perspectives

  26. MERCI @lilobase