Les fausses bonnes idées croisées dans ma carrière - BreizhCamp 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).

C'est ce recueil que je me propose de parcourir en votre compagnie, à la fois sur des décisions qui ont fait échouer des projets, mais aussi sur des sujets plus légers et parfois amusants.

Transcript

1. Une bonne idée ?
2. Les fausses bonnes idées croisées dans ma carrière ! Arnaud LEMAIRE @Lilobase Les erreurs que j’ai fait quand j’ai commencé ma carrière Ce que j’ai cru vrai Mais aussi …
3. Les fausses bonnes idées ça vient d’où en fait ?
4. -Merlin Mann « I’m a project manager, not a magician. 
 Magicians have way cooler hats. »
5. Un manque de vision sur le long terme Temps Fonctionnalités
6. Un manque de vision sur le long terme Temps Fonctionnalités exp(temps) log(temps) 6 mois
7. Que c’est l’humain qui coûte le plus cher ! Le hardware ne coûte « presque » rien On passe plus de temps à lire (et comprendre) le code qu’à l’écrire ! Et ajouter plus de développeur n’accélère pas un projet
8. -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. »
9. Oublier que notre métier est de résoudre les problèmes du client Est-ce que l’on résout le bon problème ? Nous ne sommes pas là pour résoudre des « défis » techniques ! La technique doit s’adapter au contexte métier et non l’inverse
10. Caractéristique vs Bénéfice (fonctions) Ce que c’est vs ce que ça fait Quelle est l’intention métier du logiciel ? Une application doit être pensée en fonction de ses fonctions métier et non de ses caractéristiques techniques Penser « comportements » (messages) et non « états » !
11. Croire que la magie existe ! Ce nouveau … est génial car … ! Vous allez pouvoir construire … en … heures ! « There is no silver bullet »
12. -Fred Brooks « This second [system] is the most dangerous system a man ever designs. »
13. Faire des choses « compliquées » Complexité Complexité essentielle Complexité accidentelle La complexité d’un projet est une somme :
14. Notre métier consiste à faire tendre la complexité d’un système logiciel vers sa complexité essentielle mais attention à ne pas confondre simplicité & facilité Faire des choses « compliquées »
15. Faire des choses « au cas où » Génère de la complexité accidentelle Risque de complexifier la maintenance future « You ain’t gonna need it »
16. Faire des choses « génériques » La généricité doit être construire à posteriori Ça peux verrouiller les mises à jours des apps si vous partagez des modules « Les métiers sont différents et les besoins aussi »
17. Les fausses bonnes idées En conception logicielle
18. « putain on le met où ce code ? » Vous, en train d’ajouter une fonctionnalité Utiliser MVC
19. Considérer MVC comme une architecture applicative MVC est un pattern de présentation V C M MVC n’est pas une architecture applicative V C M l’énorme modèle fourre tout !
20. Penser « CRUD » Model Driven Architecture Etats vs message Le CRUD vous amène à créer une application sous forme de datas as a service, ignorant toute la partie métier du logiciel
21. Utiliser un admin generator Vous, devant une administration générée automatiquement « Je comprend rien, bordel… »
22. Utiliser un admin generator Lorem ipsum Dolores sit Amen sinacti SAVE Le scaffolding est un peu moins pire, mais pas beaucoup Etats vs message Vous avez la même valeur ajoutée qu’une base MS Access (en plus joli, peut être) …
23. Le Framework Full Stack Ce n’est pas tant l’outil que les reflexes qu’il donne Un framework ne vous aidera jamais à construire le métier (qui est la partie qui apporte de la valeur au client) Un framework doit être cantonné à gérer les IO web
24. « La db est vraiment trop lente… » Hypothétique dialogue… Utiliser un ORM « Attend, il y a 600 requêtes pour générer la page » « … »
25. Utiliser (n’importe comment) un ORM Finalement il vous aura aidé à quoi l’ORM ? Et surtout à quel prix ? Vous savez encore faire du SQL ? Et l’eager loading on en parle, les transactions ? Ne faites pas confiance à un ORM
26. - Jean Baptiste Dusseaut « Ces outils rendent trivial ce qui est facile, impossible ce qui est difficile »
27. Les fausses bonnes idées Dans l’écriture du code
28. « Oui, il y avait la même entité dans un autre package, je les ai rassemblées » Un collègue, à propos d’une classe de 2500 loc Supprimer les duplications
29. Supprimer à tout prix toute les duplications Ça part d’un bon sentiment (DRY), mais peut aboutir à créer des classes dieu Mais le contexte d’exécution peu rendre nécessaire la présence d’une duplication Vouloir supprimer les duplications dans des contextes différents peut créer énormément de complexité et des problèmes pour faire cohabiter les deux métiers dans une même entité
30. « J’ai gagné 200ms sur 200 K itérations grâce à cette technique » Un collègue à propos d’un code particulièrement imbitable Optimiser prématurément
31. Se soucier des performance dès le début Qu’est ce qui coute le plus cher ? un collègue qui passe 3 heures à comprendre ce que vous avez essayé de faire ou qu’une machine passe quelques millisecondes de plus à faire ses calculs ? Les parties qui risquent de bloquer la performance de votre application sont rarement celles que l’on imaginait
32. « Bon on a pas désinfecté la pièce car c’était long et un peu chiant à faire » Un chirurgien avant de vous opérer Ne pas tester son code
33. Ne pas faire de tests On est un des rares métier ou c’est « normal » que ça ne marche pas dès le début Tester vous permettra de faire évoluer beaucoup plus simplement votre application pendant sa durée de vie
34. Mettre des conneries dans les données de test « … »
35. Faire du javascript coté serveur pour des applications métiers Node.js marche très bien pour les questions d’infrastructures Mais les limitations inhérentes à l’environnement peuvent complexifier la mise en place d’application métier
 (std lib, promise, scoping, … )
36. Les fausses bonnes idées Coté base de donnée
37. « Ça va être compliqué, le modèle de données de la DB n’est pas prévu pour faire ça » Réponse au client après une demande d’évolution Faire de la MDA
38. Faire de la MDA Une application se définit par ses fonctions (son comportement) La base de donnée n’est qu’un système de snapshots de l’état de votre application
39. « Oui, alors en fait, c’était une ancienne procédure stockées qui est rentrée en conflit avec la nouvelle » Echanges après que le calcul de 600 factures se soit révélé faux Utiliser des procédures stockées
40. Les procédures stockées C’est le code métier caché par excellence Déjà que gérer les versions du modèle de DB est compliqué… Difficile à tester, à réutiliser et à faire évoluer, un vrai bonheur…
41. « Non mais si on touche à ça il va falloir revoir l’application de gestion des contrats obsèques » Quand vous voulez modifier le logiciel de gestion des cantines scolaire Communication via la DB
42. La communication inter-applicative via la DB Toujours utiliser des apis de haut niveau pour dialoguer avec une application En attaquant en direct la DB vous ignorez l’ensemble du métier de l’application Bloque les possibilités d’évolution d’une application par rapport à l’autre Souvent des applications différentes vont avoir des modèles très spécifiques, en les associant vous créez énormément de complexité inutile Attention à la version cachée : une base de donnée partagée par plusieurs micro-services
43. « Le système de vente est mort à cause du système de notifications » Tout le monde entrain de paniquer N’utiliser qu’une DB pour tout faire
44. Utiliser une DB pour tout faire Quand on a un marteau… tout ressemble à des clous Vérifiez que votre base de donnée est adaptée à l’usage Surtout pour du micro-service N’hésitez pas à utiliser plusieurs db de différent type dans votre application
45. « ça prend 7 minutes » Avant c’était 7 heures Utiliser des ID séquentiels
46. Utiliser des ID séquentiels Contrôlez la génération des ID Souvent votre métier à déjà des identifiants pour ses entités
 (n° siret, iban, isbn, …) Vous n’avez plus à attendre le retour d’une requête insert en cas d’import massif avec des relations entre les entités
47. Les fausses bonnes idées Les API en mode YOLO
48. « En fait le serveur se souvient de vos dernières requêtes et réapplique automatiquement les filtres » Explication suite à un bug incompréhensible API Stateful
49. Faire une API Stateful NE. FAITES. JAMAIS. ÇA. Une api doit être idempotent
50. « WTF » La première fois que vous avez ouvert un WSDL Utiliser SOAP
51. Utiliser SOAP Une bonne idée… Sur le papier Des implémentations souvent buggées et parfois incompatibles Trop compliqué pour plupart (la totalité ?) des usages Faire une architecture micro-service basée sur SOAP est une mauvaise idée (indice : ça s’appelle de la SOA en J2EE)
52. Utiliser SOAP, mais aussi… Mettre du SOAP dans du REST Mettre des chaînes de caractères XML (CDATA) dans du SOAP…
53. « C’est parce que ça s’appelle comme ça dans l’application distante » A propos d’un nommage incompréhensible La consommation d’API en direct
54. Ne pas avoir de couche d’isolation pour consommer une API Séparez clairement les applications pour éviter que l’application distante ne contamine la votre : prévoyez des couches de traduction Ça marche aussi quand vous êtes fournisseur : abstraire les versions de l’API permet d’être plus tranquille sur son évolution
55. Les fausses bonnes idées La carrière
56. Croire que l’architecture logicielle était un métier à part
57. Penser que je devais évoluer vers du management
58. Se concentrer sur une stack, un seul langage ou un framework en particulier
59. Penser que j’étais bon, soyez humble ! (surtout en début de carrière)
60. Merci ! @lilobase