Les fausses bonnes idées croisées dans ma carrière — Elsass JUG 2017

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. Fausses bonnes idées ElsassJUG
2. Une bonne idée ?
3. 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 pensé être vrai Mais aussi …
4. Les fausses bonnes idées En conception logicielle
5. « putain on le met où ce code ? » Vous, en train d’ajouter une fonctionnalité Utiliser MVC
6. Considérer MVC comme une architecture applicative MVC est un pattern de présentation V C M MVC n’est pas une architecture V C M l’énorme modèle fourre tout !
7. Utiliser un admin generator Vous, devant une administration générée automatiquement « Je comprend rien, bordel… »
8. 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) …
9. « 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 » « … »
10. 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
11. 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
12. « Alors on fait un diff de l’objet avec l’objet précédent en base de donnée puis à partir du diff on fait un évènement qui est envoyé dans le bus » Un client qui vous explique l’origine d’un problème Faire de l’Event Sourcing (sans expérience)
13. - Jean Baptiste Dusseaut « Ces outils rendent trivial ce qui est facile, impossible ce qui est difficile »
14. Les fausses bonnes idées Dans l’écriture du code
15. « 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
16. 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é
17. « 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
18. 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
19. « 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
20. 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
21. « 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
22. 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 !
23. « On peut pas monter de version » Un client qui vous explique que l’application est en PHP-GTK Utiliser la mauvaise techno
24. 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, async, types, namespaces… )
25. Mettre des conneries dans les données de test « … »
26. Les fausses bonnes idées Coté base de donnée
27. « Ç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
28. 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
29. Penser CRUD Le problème métier de votre client c’est rarement qu’il manque de formulaires à remplir…
30. « 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
31. 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…
32. « Non mais si on touche à ça il va falloir revoir les formats des codes pays » Quand vous voulez changer un échéancier de facturation Communication via la DB
33. 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
34. « 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
35. 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
36. « ça prend 7 minutes » Avant c’était 7 heures Utiliser des ID séquentiels
37. 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
38. Les fausses bonnes idées Les API en mode YOLO
39. « 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
40. Faire une API Stateful NE. FAITES. JAMAIS. ÇA. Une api doit être idempotent
41. « WTF » La première fois que vous avez ouvert un WSDL Utiliser SOAP
42. 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)
43. Utiliser SOAP, mais aussi… Mettre du SOAP dans du REST Mettre des chaînes de caractères XML (CDATA) dans du SOAP…
44. « 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
45. 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
46. Les fausses bonnes idées Mais alors, ça vient d’où ?
47. -Merlin Mann « I’m a project manager, not a magician. 
 Magicians have way cooler hats. »
48. Un manque de vision sur le long terme Temps Fonctionnalités
49. Un manque de vision sur le long terme Temps Fonctionnalités exp(temps) log(temps) 6 mois
50. 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
51. L’expertise en hors sol Architectes logiciel Coach agile / technique
52. -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. »
53. 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
54. 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 » !
55. Croire que la magie existe ! Ce nouveau … est génial car … ! Vous allez pouvoir construire … en … heures ! « There is no silver bullet »
56. Suivre un culte du Cargo
57. -Fred Brooks « This second [system] is the most dangerous system a man ever designs. »
58. Faire des choses « compliquées » Complexité Complexité essentielle Complexité accidentelle La complexité d’un projet est une somme :
59. 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 »
60. 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 »
61. 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 »
62. Les fausses bonnes idées La carrière
63. Croire que l’architecture logicielle était un métier à part
64. Penser que je devais évoluer vers du management
65. Se concentrer sur une stack, un seul langage ou un framework en particulier
66. Penser que j’étais bon, soyez humble ! (surtout en début de carrière)
67. Merci ! @lilobase | www.arpinum.fr