Qu’est ce que l’under et l’over design ?

20160311_205921394_iOSimage de la cafeteria Amazon, tout est dessiné a la craie

Le design est un processus intellectuel que l’on utilise pour un algorithme, une data structure, une application, un site web, un system distribué… afin de définir une certaine structure.

Le but de cette structure est d’améliorer la maintenance, la performance et ou la réutilisabilité de ce que vous êtes entrain de concevoir.

L’over design, c’est quand on en fait trop. En faire « trop » c’est mauvais pour deux raisons : 1/ ça coûte de l’argent (== temps) et parfois 2/ cela augmente la dette technique (plus dur à maintenir).

L’under design, c’est la même chose sauf qu’on en fait pas assez, ce qui augmente aussi la dette technique.

 

Je vous propose dans cet article mon point de vue, car comme toujours l’ingénierie c’est plus de l’art que de la science. Chacun peut avoir sa propre définition de l’over/under design, libre a vous de laisser un commentaire.

D’ailleurs, dit-on « under » et « over » design par rapport à un référentiel ? Doit-on mettre la même qualité de design entre une petite app faite soit même et un logiciel pour Airbus ?

Il ne faut pas confondre les critères de sécurité, scalabilité, robustesse qui influencent le design et qui peuvent être différents entre une app maison et un grand logiciel avec les principes de base du design.

Combien d’entre nous avons une histoire à raconter sur un software qui a été écrit par Raymon en VBA pour automatiser deux trois bricoles et qui à la fin devient une usine à gaz qui fait tourner toute une unité de production.

Une fois que vous avez appris les principes de base du design, vous ne reviendrez pas en arrière. Il faudrait que je me force pour architecturer des composants « plus simple », car je pense que sans un effort minimum, la structure ne sera pas « logique ». J’aurai moi même du mal à me relire.

Doit-on nécessairement avoir un code complètement testable, avec des intentions claires et une séparation entre les besoins business et techniques pour une simple application maison ? Je pense que oui.

 

Les deux grandes étapes lors d’un design

Pour designer quoi que ce soit, deux étapes sont souvent nécessaires :

Séparer le business de la technique

Exemple #1 avec un système distribué : Jojo.com veut persister un caddy pour ses utilisateurs.

Stocker le caddy est l’objectif « business » et stocker des données de façon temporaire pour des centaines d’utilisateurs est l’objectif « technique ».

Donc on crée un service appelé CaddyStore qui lui même consommera un service de stockage scalable/available appelé StoreDB (dynamodb par exemple).

 

Exemple #2 avec de l’UI : La home page de Jojo.com ainsi que la page de « news » affiche un widget avec les dernières promotions.

Afficher les promotions c’est l’aspect business, donc on éditera les deux vues pour incorporer un contrôle. Ce contrôle sera capable d’afficher une liste d’éléments, ça c’est le besoin technique.

 

Exemple #3 avec un algorithme : Un algorithme a besoin de retourner une liste de client. GetClients sera votre besoin business et les méthodes pour se connecter à la base de données comme Connect() seront les besoins techniques.

 

Soyons clair, je n’ai pas encore trouvé dans mon expérience un cas de over-design quand il s’agissait de séparer le business de la technique. C’est la base minimum, c’est la partie du design qui n’est pas négociable. C’est la partie qui ne nécessite pas de discussion car elle indispensable à la maintenance et à la compréhension. Même s’il faut découper jusqu’à avoir des fonctions ayant une seule ligne de code, si ces fonctions permettent d’exprimer un besoin business précis, alors c’est tout bon.

Si ce découpage n’a pas lieu, c’est pour moi ce que j’appelle de l’under design.

 

Découper l’aspect technique en plusieurs responsabilités

Pour cela on utilise deux techniques : l’encapsulation et l’abstraction. L’encapsulation pour une meilleure maintenabilité, et l’abstraction pour une meilleure réusabilité.

 

C’est à ce moment du design que l’on peut tomber dans l’over design car il fait appel au bon jugement.

La première chose que l’on peut faire c’est regarder les standards qui ont été créés avec le temps : le 3-tiers.

3-tiers je n’ai pas besoin de vous l’expliquez, c’est un standard. Séparer la logique business, des data, de l’output. Peu importe que vous soyez entrain d’écrire un service, un driver, ou un site web en JavaScript, c’est une obligation. Si cela n’est pas fait, alors nous sommes dans de l’under-design (oui je te regarde, toi qui balance ton JS tout pourave dans un fichier .js et qui fait tes requêtes ajax et l’update de la vue dans le même prototype).

 

On peut ensuite descendre d’un autre niveau, en pensant design patterns comme utiliser une factory lors de la construction d’un objet, ou utiliser un mécanisme de PubSub pour faire communiquer plusieurs widgets ensemble, utiliser un systeme de feed pour faire transiter des donnees entre systemes etc…

 

Si le code source ne permet pas que la logique/les interfaces publiques puissent être totalement testées (mockup and co), alors nous sommes dans l’under-design.

L’over-design est plus compliqué à analyser. Chacun sa technique. La mienne est de ne pas prédire le futur, j’assume que tout ce qui n’est pas certain d’arriver, n’arrivera pas.

Par exemple, si quelqu’un me dit « Le business sera intéressé par faire XXXX sur le site dans quelques mois » et que cela doit complexifier le design aujourd’hui, je ne le ferai pas.

Si le business me dit « On a les données, on est sur qu’on aura besoin de faire XXXX dans Y mois, on a d’ailleurs le funding pour le projet et le CTO approuve », alors je pourrai le considérer.

 

 

Si vous complexifier un data-flow, un code, pour une éventuelle évolution qui pourra (ou pas) arriver dans une future version sans preuve tangible : vous êtes dans l’over design.

Certes, vous pourrez toujours argumenter que cela ne « coûte rien », juste « 2 minutes » de plus pour réaliser ça et que ça nous évitera de tout réécrire plus tard.

Sauf que par expérience : ça ne coûte pas rien, ça ne prend pas que 2 minutes si on inclut tout (debug, temps de ramp up…) et en plus vous complexifier la structure, ça ne vaux pas le coup.

 

Exemple 1 d ‘over design: vous concevez 2 composants devant s’intégrer et communiquer ensemble. Vous découvrez que le couplage entre ces composants est fort. Vous pensez que plus tard il pourrait y avoir beaucoup plus de composants, vous décidez donc d’utiliser un bus de communication (PubSub pattern).

 

Tant que vous n’êtes pas certain que le nombre de composants va drastiquement augmenter, ne créez pas le channel de communication. Certes le refactoring nécessaire sera compliqué, mais le debug et l’investissement de départ aura un cout conséquent. Si on se permet de prédire le future sur tout ce qu’on entreprend, le prix d’un logiciel devient astronomique.

 

Exemple 2 : Vous concevez un site web, vous vous dites qu’un jour vous aurez certainement des milliers de milliards d’utilisateurs donc vous décidez d’utiliser le mot a la mode NOSQL. Vous décidez de laisser tomber le choix d’une BDD qui a fait ses preuves ses 15 dernières années pour utiliser une technologie expérimentale : une architecture lambda, car « on sait jamais ».

 

Comme tous les fan boys de technologies, qui préfèrent utiliser .NET 2000 au lieu de .NET 2 car l’innovation s’est forcement égal à utiliser une technologie toute fraiche (kikoolol), la plupart des technologies de ces 15 dernières années qui ont survécus aujourd’hui sont robustes, répondent très bien à vos besoins. Si twitter et Amazon tourne sur des BDD relationnelles jusqu’à il y a encore peu, ça m’étonnerai que votre nouveau site révolutionnaire ait besoin de plus d’attention.

 

Exemple 3 : Vous découpez votre app en plusieurs DLL, au cas ou ont ai un jour besoin d’utiliser le composant DAO dans une autre application.

 

Réfléchissez bien à ça, combien de fois dans votre carrière vous avez créer des DLL ? Souvent. Ok. Combien de fois les avez vous réutilisées ? 1% ? Même Microsoft ne sépare pas en DLL ses applications natives comme XBOX Music, SoundRecorder etc.., ils ne le font que quand le besoin se présente.

Conclusion

 

Les signes de l’under-design Pas de séparation entre les besoins business et technique

 

Les best-practices devenu des standards (3-tiers, testabilité…) ne sont pas respectées.

Les signes de l’over-design On répond à un besoin qui n’est pas immédiat ou qui n’est pas certain d’arriver.

 

FacebookLinkedIn
  • Fabien

    Super article. J’aime vraiment comment tu expose les deux problématiques. Il semble relativement simple de travailler et progresser pour ne pas tomber dans l’under design, l’over design semble beaucoup plus tricky.

    L’open close principle (SOLID) semble correspondre/répondre a la technique pour eviter l’over design mais sans predir l’avenir ca reste complique!

  • Mickaël Gandecki

    “Comme tous les fan boys de technologies […]” Haha super ! J’ai déjà prononcé ce paragraphe quasiment mot pour mot (en ciblant explicitement les kikoolol bien entendu).

  • leche_QQ

    tu ne parles jamais de sécurité dans ton blog ou SDLC ? tu considères que ce n’est pas important ? ou que ton archi / code est forcement Secure ? ca serait intéressant d’avoir ton avis sur ce sujet 😀
    que penses tu de https://www.owasp.org/images/5/5c/ProportionTest.png ou de https://www.owasp.org/images/3/31/ProportionSDLC.png par exemple ?

    • Environ 10% de notre temps de travail est reserve a la securite.
      Que ce soit au niveau du design, de l’ecriture du code, du deploiement….
      je fais regulierement des pentests et security review (au moins une fois chaque deux mois).
      Je pourrai ecrire un article la dessus, c’est un sujet que je maitrise bien.

      • Innocent.

        Makes sense.

      • leche_QQ

        oue un sujet sur la secu pentests and co ca changerai et ca serait intéressant 😉

  • Innocent.

    J’aime bien la façon avec laquelle les deux notions sont fédérées. Il me semble que les composants “projets” notamment le temps et le cout peuvent aider à ne pas aller dans l’over design (prédire le futur pourrais augmenter la scope du projet). Néanmoins, j’aimerais bien avoir ton avis sur la situation hypothétique ou on suppose qu’on a un budget illimite. Comment définir la lisière entre l’under et l’over design?

    • Budget illimite, certes, mais la question c’est WHY?
      Ecrit tu du software pour un client ou pour l’art d’ecrire du software.

      Le budget illimite c’est juste un element de l’equation, ce que tu souhaites accomplir est bien plus important.

      Si ton but c’est de satisfaire un marche/des clients, les clients seront plus content d’avoir un software rapidemment.

      • Innocent.

        It makes sense.

  • Bassama thePaulo

    Tres bon article. Under design on en fait constamment quand est un newbie mais aussi quand on développe un produit jetable (qui ne compte pas être maintenu ou réutilisé). De l’over-design on en fait quand on prend de l’expérience mais aussi quand on est expérimenté. Super article surtout avec les exemples on arrive vitre a cerner les nuances. 🙂

  • Fabrice Hauhouot

    Merci Julien pour ce partage !

  • Jeff974

    Super article. Tu peux traduire pour que je partage a mes collegues locaux 😀 ?

    Comme tous les fan boys de technologies = Comme julien il y a quelques annees 😀