Réflexions sur la complexité

Pistes de réflexion:

Ajouter de la complexité inutile basée sur des spéculations, en faire plus que ce qui est requis. Maintenir du code qui ne sert pas pour le moment et qui ne servira peut-être jamais, car il est probable que les spéculations s'avèrent fausses au moment venu.

Code that solves problems you don’t have.

source: https://hackernoon.com/how-to-accept-over-engineering-for-what-it-really-is-6fca9a919263#.da44lidym

Pistes de réflexion:

Une des raisons qui explique la présence de complexité inutile est que les développeurs veulent faire en sorte que le code réponde à tous les cas futurs possibles. Malheureusement, même en tentant de penser et prévoir ce qui peut arriver, on fait déjà des suppositions qui s'avéreront probablement fausses. On aura alors mis du temps à élaborer des solutions qui finalement ne serviront peut-être pas ou qui ne seront pas adaptées et qui auront complexifié le code de manière injustifiée.

Une architecture inutilement complexe peut possiblement faire en sorte qu'il est plus long pour comprendre le code et pour ajouter des fonctionnalités. En bout de ligne c'est le client qui sera pénalisé, car les délais et coûts seront ainsi plus élevés.

** Note: une architecture peut être évolutive sans être inutilement complexe.

Many programmers forget about their raison d'être - meeting the client's needs, automating complex operations and simplifying, not complicating the client’s life. We are not here to create the architecture and solutions of our dreams at every opportunity.

What if our excessive diligence and perfectionism when writing code outweighs the needs and requirements of the client, his budget and agreed deadline?

Sources: https://softwarebrothers.co/blog/how-to-avoid-over-engineering/ https://hackernoon.com/how-to-accept-over-engineering-for-what-it-really-is-6fca9a919263#.da44lidym

Pistes de réflexion:

• Lors d'un projet personnel pour apprendre et expérimenter.
• Dans le cadre d'un projet de recherche.

Pistes de réflexion:

Déterminer s'il y a de l'over-engineering est subjectif. Plusieurs développeurs peuvent être d'avis différents et rien n'est tout noir ou tout blanc.

Voici quelques indices qui peuvent laisser transparaître une complexité inutile (tirés de l'article suivant: https://softwarebrothers.co/blog/how-to-avoid-over-engineering/):

• Ajouter du code ou des fonctionnalités pour répondre à un problème inexistant (pour le moment).

• Délibérément vouloir être technologiquement à l'avant-garde et le faire paraître dans le code à tout prix et ce, même s'il n'est pas nécessaire.

• Vouloir relever un défi technique sans réel besoin (ex. pour des motifs personnels). Tentative de réinventer la roue, il existe déjà plusieurs librairies dont le code est testé et qui peuvent répondre aux besoins.

• Il y a un écart entre la complexité du problème à résoudre et les conséquences de la solution. Exemple un problème simple, mais dont la solution demande de maintenir beaucoup de code qui peut contenir des bugs.

Pistes de réflexion:

• Bien comprendre le problème réel.

• Se poser des questions avant de se lancer à développer une solution, prendre un pas de recul. Si la solution a déjà été mise en place, on peut analyser s'il existe des solutions plus simples, se demander pourquoi ces solutions plus simples n'ont pas été utilisées à la en place.

• Évaluer le coût d'instaurer une solution X maintenant vs plus tard. Si le coût d'ajouter la solution X dû à un possible changement Y est minime alors il peut être acceptable de l'ajouter même si le besoin présent ne le demande pas. Par contre si ajouter X maintenant vs plus tard représente le même coût, il est peut-être mieux d'attendre. Si finalement, instaurer X maintenant pour un possible changement Y prendra beaucoup de temps, il vaut encore mieux attendre puisque peut-être que le changement Y n'arrivera jamais et s'il arrive, il se pourrait que ce ne soit pas du tout comme nous l'avions prévu. Par contre, préparer le terrain afin de ne pas prendre la décision tout de suite peut être une bonne stratégie. Dans ce cas, il peut être bien de mettre une interface (coût minime) aujourd'hui afin de faciliter le changement futur. L'objectif n'est pas d'ignorer le futur, mais de s'y préparer sans prendre de décision aujourd'hui. Si on sait qu'un bout de code pourrait être amené à changer, on va dès aujourd'hui s'assurer qu'il puisse changer facilement, sans pour autant coder les changements avant le temps.

• Bien comprendre les différentes solutions proposées c'est-à-dire:

  • Ne pas aveuglément utiliser une technologie ou un pattern architectural. Ultimement, la raison d'être des principes de programmation et des patterns est (entre autres) de rendre le code plus maintenable, compréhensible, facile à ajouter des fonctionnalités, à modifier, facile à tester, etc. Si la solution appliquée n'aide aucun de ces points, alors il se peut qu'il y ait présence de complexité inutile.

  • Même chose pour les différents outils et technologies, ils sont présents pour répondre à un problème X et ultimement, faciliter le développement, si on ne fait pas face au problème X et si son utilisation ne nous simplifie pas la vie, alors c'est peut-être un signe qu'il ne faut pas l'utiliser.