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

Transcript

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