Les fausses bonnes idées croisées dans ma carrière - BBL Société Générale 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 ? BBL Société Générale
2. Les fausses bonnes idées croisées dans ma carrière ! Arnaud LEMAIRE @Lilobase | www.arpinum.fr 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. Utiliser un admin generator Vous, devant une administration générée automatiquement « Je comprend rien, bordel… »
21. 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) …
22. « 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 » « … »
23. 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
24. 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
25. - Jean Baptiste Dusseaut « Ces outils rendent trivial ce qui est facile, impossible ce qui est difficile »
26. Les fausses bonnes idées Dans l’écriture du code
27. « 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
28. 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é
29. « 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
30. 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
31. « 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
32. 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
33. « On a commencé une réécriture, mais cette fois-ci on fait du micro- services » Quand vous demandez la stratégie pour corriger une application Les Micro-Services
34. Faire du Micro-Services pour corriger une architecture défaillante Les micro-services ajoutent de la complexité, et si vous n’arriviez déjà pas à gérer la complexité de votre métier… Les micro-services ne sont pas un objectif d’architecture logiciel, il s’agit d’une stratégie de déploiement Vous devriez commencer par un monolithe découplé, que progressivement vous venez décorer avec des services tiers si le besoin s’en fait sentir !
35. Mettre des conneries dans les données de test « … »
36. 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, … )
37. Les fausses bonnes idées Coté base de donnée
38. « Ç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
39. Faire de la MDA Une application se définit par ses fonctions (son comportement) Cela vous amène à penser « CRUD » en ignorant tout le métier de l’application La base de donnée n’est qu’un système de snapshots de l’état de votre application
40. Penser CRUD Le problème métier de votre client c’est rarement qu’il manque de formulaires à remplir…
41. « 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
42. 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…
43. « 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
44. 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
45. « 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
46. 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
47. « ça prend 7 minutes » Avant c’était 7 heures Utiliser des ID séquentiels
48. 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
49. Les fausses bonnes idées Les API en mode YOLO
50. « 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
51. Faire une API Stateful NE. FAITES. JAMAIS. ÇA. Une api doit être idempotent
52. « WTF » La première fois que vous avez ouvert un WSDL Utiliser SOAP
53. 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)
54. Utiliser SOAP, mais aussi… Mettre du SOAP dans du REST Mettre des chaînes de caractères XML (CDATA) dans du SOAP…
55. « 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
56. 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
57. Les fausses bonnes idées La carrière
58. Croire que l’architecture logicielle était un métier à part
59. Penser que je devais évoluer vers du management
60. Se concentrer sur une stack, un seul langage ou un framework en particulier
61. Penser que j’étais bon, soyez humble ! (surtout en début de carrière)
62. Merci ! @lilobase