Critères de mauvaise conception
La vie fonctionne tout simplement : souvent, pour être malin, il suffit de ne pas faire de bêtises. Cela s'applique également au développement de logiciels : dans la plupart des cas, pour bien faire quelque chose, il suffit de ne pas le faire mal.
La plupart des programmeurs ont eu de l'expérience avec des parties du système qui ont été mal conçues. Mais plus tristement encore, la plupart d'entre vous auront la triste expérience de réaliser que vous étiez les auteurs d'un tel système. Nous voulions le meilleur, mais cela s'est avéré comme toujours.
La plupart des développeurs n'aspirent pas à une mauvaise architecture, et pour de nombreux systèmes, il arrive un moment où ils commencent à dire que son architecture est terrible. Pourquoi cela arrive-t-il? La conception de l'architecture était-elle mauvaise dès le départ ou est-elle devenue mauvaise avec le temps ?
La racine de ce problème est l'absence d'une définition de la « mauvaise » conception.
Il me semble que c'est la compréhension de la qualité de la conception et des raisons de sa « décroissance » qui sont les qualités les plus importantes pour tout programmeur. Comme dans la plupart des autres cas, l'essentiel est d'identifier le problème, et ce sera une question de technologie pour le résoudre.
Définition de "mauvaise conception"
Si vous décidez de vous vanter de votre code devant un collègue programmeur, vous serez très probablement ridiculisé en réponse : "Qui fait ça ?", "Pourquoi est-ce comme ça ?" et "Je ferais les choses différemment." Cela arrive très souvent.
Toutes les personnes sont différentes, mais vous écrivez toujours le code pour vos collègues programmeurs, donc dans le processus de développement de chaque fonctionnalité, vous avez toujours besoin d'une phase de révision lorsque d'autres personnes regardent votre code.
Mais même si beaucoup de choses peuvent être faites de différentes manières, il existe un ensemble de critères sur lesquels tous les développeurs seraient d'accord. Tout morceau de code qui satisfait ses exigences mais qui présente encore une (ou plusieurs) caractéristique est une mauvaise conception.
Mauvaise conception :
- Difficile à changer car tout changement affecte trop d'autres parties du système. ( Rigidité , Rigidité).
- Lorsque des modifications sont apportées, d'autres parties du système se cassent de manière inattendue. ( Fragilité , Fragilité).
- Le code est difficile à réutiliser dans une autre application car il est trop difficile de l'extraire de l'application actuelle. ( Inamovibilité , Immobilité).
Et le plus drôle, c'est qu'il est presque impossible de trouver un élément du système qui ne contient aucune de ces caractéristiques (c'est-à-dire qui est flexible, fiable et réutilisable), répond à l'exigence, et en même temps sa conception est mauvaise .
Ainsi, nous pouvons utiliser ces trois caractéristiques pour déterminer sans ambiguïté si une conception est « mauvaise » ou « bonne ».
Causes de la "mauvaise conception"
Qu'est-ce qui rend une conception rigide, fragile et inamovible ? Interdépendance rigide des modules.
Une conception est rigide si elle ne peut pas être facilement modifiée. Cette rigidité est due au fait qu'un seul changement d'un morceau de code dans un système tissé entraîne des changements en cascade dans les modules dépendants. Cela se produit toujours lorsqu'une personne travaille sur le code.
Cela complique immédiatement tout le processus de développement commercial : lorsque le nombre de changements en cascade ne peut pas être prédit par le concepteur ou le développeur, il est impossible d'estimer l'impact d'un tel changement. Par conséquent, ils essaient de reporter ces changements indéfiniment.
Et cela rend le coût du changement imprévisible. Face à une telle incertitude, les gestionnaires hésitent à apporter des changements, de sorte que la conception devient officiellement rigide.
À un moment donné, votre projet dépasse «l'horizon des événements» et est voué à tomber dans le «trou noir» de l'architecture rigide.
La fragilité est la tendance d'un système à s'effondrer à plusieurs endroits après un seul changement. Habituellement, de nouveaux problèmes surviennent dans des endroits qui ne sont conceptuellement pas liés au lieu du changement. Une telle fragilité sape sérieusement la confiance dans la conception et la maintenance du système.
C'était généralement le cas lorsqu'il n'y avait pas de méthodes privées. Il suffit de rendre toutes les méthodes publiques, et vous serez voué à l'apparence d'une architecture fragile. L'encapsulation aide à gérer cela au niveau micro. Mais au niveau macro, vous avez besoin d'une architecture modulaire.
Lorsqu'un projet a une architecture fragile, les développeurs ne peuvent garantir la qualité du produit.
De simples changements dans une partie de l'application entraînent des bogues dans d'autres parties non liées. La correction de ces erreurs entraîne encore plus de problèmes, et le processus d'escorte se transforme en un chien célèbre poursuivant sa propre queue.
La conception est immobile lorsque les parties nécessaires du système sont fortement liées à d'autres détails indésirables. Trop de leur propre code, leurs propres approches et solutions uniques.
Vous souvenez-vous de l'enregistreur JUL, dont les développeurs ont proposé leurs propres niveaux de journalisation sans raison valable ? C'est juste le cas.
Pour donner à un designer une idée de la facilité avec laquelle il est possible de réutiliser un design existant, il suffit de penser à la facilité avec laquelle il sera utilisable dans une nouvelle application.
Si la conception est étroitement couplée, ce concepteur sera horrifié par la quantité de travail nécessaire pour séparer les parties requises du système des détails inutiles. Dans la plupart des cas, une telle conception n'est pas réutilisable, car le coût de sa séparation l'emporte sur son développement à partir de zéro.
Pertinence
Tout change, mais tout reste pareil. (Proverbe chinois)
De très bonnes questions ont été soulevées ci-dessus. Quels sont les dangers des systèmes fragiles et rigides ? Oui, car le processus de gestion d'un tel projet devient imprévisible et incontrôlable. Et le prix est exorbitant.
Comment un manager peut-il donner ou non le feu vert pour ajouter une fonctionnalité s'il ne sait pas combien de temps cela prendra réellement ? Comment hiérarchiser les tâches si vous ne pouvez pas estimer adéquatement le temps et la complexité de leur mise en œuvre ?
Et comment les développeurs peuvent-ils rembourser la même dette technique alors que nous allons encaisser en la payant, et nous ne pouvons pas comprendre combien nous allons encaisser avant d'avoir ratissé ?
Les problèmes de réutilisation ou de test de code sont également très pertinents. Les tests unitaires servent non seulement à tester certaines hypothèses sur l'unité testée, mais aussi à déterminer le degré de sa cohésion et peuvent servir d'indicateur de réutilisation.
Voici une citation de Bob Martin pour ce cas : « Afin de réutiliser votre code, vous devez faire l'effort de le réutiliser moins cher que le coût d'un développement à partir de zéro . » Sinon, personne ne se souciera même de cette affaire.
L'utilisation de principes et de modèles de conception sert un seul objectif - rendre la conception bonne. Si leur utilisation ne vous apporte aucun avantage (ou vice versa, viole les principes de «bonne conception»), alors quelque chose dans votre véranda ne va pas et, peut-être, l'outil a commencé à être utilisé à d'autres fins.