Save 37% off PRO during our Black Friday Sale! »

Les fausses bonnes idées croisées dans ma carrière - BBL Société Générale 2016

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.

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

December 12, 2016
Tweet

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