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

Les fausses bonnes idées croisées dans ma carrière - BreizhCamp 2016

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.

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

March 23, 2016
Tweet

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