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

Fausses bonnes idées & Culte du cargo - Riviera...

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. 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…
  2. SOUVENT LIÉ À UN MANQUE DE VISION SUR LE LONG

    TERME Temps Fonctionnalités Temps Fonctionnalités 6 mois
  3. -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.
  4. ON AIME BIEN LES FRAMEWORKS (FULL STACK) • Une architecture

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

    qui est facile, impossible ce qui est difficile »
  8. 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
  9. 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 :
  10. 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
  11. EST-CE QUE ÇA SCALE ? • Souvent exprimé sous «

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

    ce que l’incompétence suffit à expliquer. »