Les modèles de conception sont-ils mal vus?
J'ai eu une discussion avec l'un de nos développeurs seniors qui est dans l'entreprise depuis 20 ans. Il est assez bien connu en Ontario pour un blog qu'il écrit.
Ce qui est étrange, c'est ce qu'il m'a dit: il a dit qu'il y avait un morceau de code avec lequel travailler était un cauchemar parce qu'il était écrit à partir d'un manuel et ne rend pas compte du monde réel. Ajouter un nouveau champ à la couche UI/base de données/données prend 2-3 heures, alors que dans son code, cela prend 30 minutes.
L'autre chose est aussi qu'il évite les modèles de conception car la plupart des programmeurs ne les comprennent pas et ils ne sont pas bons du point de vue de la maintenance.
Ensuite, il y a aussi l'idée que la plupart des développeurs Web au Canada préfèrent que leur modèle de données hérite des classes Data Layer, plutôt que de le garder isolé. Je lui ai demandé: "N'est-ce pas la norme de l'industrie pour que le modèle soit séparé de la couche de données?" Il a dit parfois, mais la plupart des gens ici préfèrent ne pas le faire parce que c'est trop de travail.
Il semble que son raisonnement pour ne pas coder en utilisant les meilleures pratiques est parce que c'est un cauchemar de maintenance, peu de nos employés le comprennent (à part moi-même), et il est lent à travailler si vous avez besoin de pousser de nouvelles fonctionnalités ou de nouveaux champs en quelques jours '' temps.
C'est tellement étrange d'entendre une opinion comme celle-ci, étant donné que Stack Overflow encourage principalement les gens à suivre les normes de l'industrie. Le problème est-il que nous sommes constamment obligés de produire de nouveaux champs et fonctionnalités en quelques jours, qu'il n'est pas possible d'en déduire un modèle solide suffisamment flexible? Cela semble être l'essentiel de ce que je comprends de cela.
Que pensez-vous de ces déclarations?
Ce sont les mots de quelqu'un qui a réussi et qui ignore les gens qui essaient de lui dire quoi faire dans un jargon à motifs qu'il ne comprend pas.
Les modèles de conception et les meilleures pratiques ne sont pas la même chose. Certaines personnes le pensent et poussent les gens qui savent ce qu'ils font des noix. Même s'ils ne connaissent pas le nom correct de ce qu'ils font.
Les modèles de conception existaient avant d'avoir des noms. Nous leur avons donné des noms pour en parler plus facilement. Un motif ayant un nom n'en fait pas une bonne chose. Cela en fait une chose reconnaissable .
Ce gars utilise probablement des modèles dont aucun de vous n'a jamais entendu parler. C'est bien, jusqu'à ce que vous ayez besoin de lui parler de la façon dont quelque chose est fait. Soit il va devoir apprendre à vous parler, soit vous allez devoir apprendre à lui parler. N'a rien à voir avec qui a "raison".
De nombreux modèles de conception, du type de ceux que vous et votre ami décrivez, ne sont vraiment que solutions de contournement pour les déficiences des langages de programmation. Utilisez un langage de programmation plus expressif et la plupart des besoins de ces modèles de conception disparaissent.
Parce que de bons modèles de conception sont nécessaires pour répondre à de nombreux scénarios d'utilisation possibles, ils ont tendance à être trop conçus. Un code sur-conçu a un coût: vous devez le lire, comprendre ce qu'il fait et comprendre comment il fonctionne dans le contexte de l'ensemble du système logiciel. Par conséquent, comme pour toute autre technique de développement logiciel, vous devez évaluer la technique par rapport au coût d'utilisation de la technique et décider si les avantages dépassent le coût.
Toutes choses étant égales par ailleurs, moins de code est toujours meilleur. J'ai parcouru des architectures en couches où vous devez littéralement faire trois à six sauts à travers plusieurs projets pour trouver le code qui est intéressant, c'est-à-dire un code qui accomplit réellement quelque chose autre que l'ajout de surcharge.
Les modèles de logiciels bien connus sont censés vous donner un vocabulaire commun par lequel vous pouvez communiquer des stratégies de conception. Malheureusement, de nombreux développeurs de logiciels ne comprennent pas assez bien le vocabulaire du modèle logiciel pour l'appliquer correctement à leurs problèmes de programmation. Les développeurs inexpérimentés considèrent ces modèles comme relevant du domaine des experts; ils veulent être considérés comme des experts, et ils essaient donc d'apprendre et d'appliquer les modèles trop tôt, avant d'être prêts. Ce qu'ils devraient vraiment faire à la place, c'est se concentrer d'abord sur l'apprentissage des principes fondamentaux de la programmation, puis essayer de résoudre le problème que chaque modèle résout lui-même. S'ils le font, ils seront bien mieux placés pour comprendre et appliquer correctement les modèles.
Stackoverflow.SE et Programmers.SE encouragent principalement les gens à suivre les meilleures pratiques comme SOLID, pas les normes de l'industrie . Et croyez-le ou non, la norme de facto de l'industrie est souvent l'architecture "grosse boule de boue" - sérieusement.
Mais pour répondre directement à votre question: le problème avec les modèles de conception est similaire à celui de l'héritage - beaucoup de développeurs médiocres les surutilisent, ce qui présente un certain risque de créer un code trop ingénieux et difficile à maintenir. Mais la réponse à cela n'est sûrement pas d'éviter ou d'interdire complètement l'utilisation de modèles de conception (ou d'héritage), la réponse consiste à apprendre à utiliser ces outils dans des situations où ils ont un sens, et seulement là. Et cela est totalement indépendant du travail "agile" ou non.
Les modèles de conception ne sont que des noms utilisés pour communiquer des idées. Je me suis souvent retrouvé à faire des choses qui plus tard, j'ai trouvé qui ont un nom. Ainsi, il n'y a pas de "méthode de conception" contrairement à une "méthode de conception non".
Les modèles de conception sont des lignes directrices. Comme tout, chacun a ses avantages et ses inconvénients. La clé n'est pas d'apprendre le modèle et de l'appliquer là où il convient, mais plutôt de comprendre l'idée du modèle, ses avantages et ses inconvénients et de l'utiliser pour trouver l'inspiration pour la solution à votre problème.
Toutes les meilleures pratiques et directives peuvent être ignorées s'il existe une raison suffisante. Les raisons valables incluent le temps de développement et les attentes de l'application. Par exemple, je suis conscient qu'il est mauvais de coder en dur (exemple stupide) mais pour une preuve de concept, les avantages pourraient l'emporter sur les coûts (dans ce cas, principalement le temps de développement). Cependant, si une telle décision est prise, elle pourrait se retourner contre vous et à un moment donné, une refactorisation pourrait être nécessaire.
Pour ajouter une autre métaphore à la soupe, les modèles de conception sont Clippy l'assistant Microsoft Office. "Vous semblez faire la même chose pour tout un tas de choses. Puis-je vous aider avec cela en vous offrant un itérateur ou un visiteur?"
Une bonne rédaction de ces modèles indiquera quand il est utile de faire quelque chose de la même manière que cela a été fait plusieurs fois auparavant, quelles erreurs vous commettrez la première fois que vous l'essayerez et quelles façons communes ont été trouvées pour éviter ces erreurs . Vous lisez donc le modèle de conception (ou l'examinez de mémoire), puis vous poursuivez votre travail. Ce que vous ne pouvez pas faire, c'est vous débrouiller seulement en utilisant Clippy et des assistants.
Lorsque des personnes inexpérimentées peuvent se tromper et écrire du code qui ne tient pas compte de la réalité, c'est quand elles pensent que leur liste de modèles de conception est une liste complète de toutes les approches possibles pour résoudre les problèmes de logiciels et essaient de concevoir du code en reliant la conception modèles jusqu'à ce qu'il soit terminé. Une autre tactique médiocre observée dans la nature consiste à enfiler un motif de conception dans une situation pour laquelle il n'est pas vraiment adapté, sur la base que le modèle de conception "est la meilleure pratique". Non, il peut ou non être la meilleure pratique pour la classe de problème qu'il résout réellement, mais ce n'est certainement pas la meilleure pratique pour les problèmes qu'il ne parvient pas à résoudre, ou pour les problèmes qu'il ne résout qu'en introduisant complexité inutile quand il existe une solution plus simple.
Bien sûr, il est également possible pour quelqu'un d'éviter un modèle sur la base de YAGNI, puis de réaliser qu'il en a besoin et de tâtonner vers la solution normale. C'est généralement (mais pas toujours) pire que de réaliser l'exigence depuis le début, et c'est pourquoi même en développement agile, c'est frustrant lorsque des exigences totalement prévisibles ne sont pas découvertes tôt. Je ne peux pas avoir été le seul programmeur C++ à avoir été très amusé par le fait que Java a initialement rejeté les conteneurs génériques comme inutilement complexes, puis les a verrouillés plus tard.
C'est donc certainement une erreur d'éviter d'écrire un Iterator en principe parce que vous préférez éviter les modèles de conception.
L'ajout d'un nouveau champ à la couche UI/base de données/données prend 2-3 heures, alors que, comme dans son code, cela prend 30 minutes.
Vous ne pouvez pas vraiment contester cela: par cette métrique, son design est bien meilleur que l'autre. Que ce soit parce qu'il a évité les modèles de conception est cependant douteux, je pense que c'est plus probable parce qu'il a considéré les bons problèmes "du monde réel" lors de sa conception, et avec le bénéfice de l'expérience, il est meilleur dans son travail que quelqu'un armé seulement avec un manuel et des idéaux élevés.
Il a donc reconnu que tout modèle qui vous oblige à toucher de nombreux points différents dans le code pour ajouter un champ est un mauvais modèle pour le travail, "facilite l'ajout de champs", et il n'a pas utilisé ces modèles. Les architectures en couches peuvent en effet souffrir à cet égard, et il est faux d'utiliser des modèles de conception sans en apprécier les inconvénients.
Par contre, combien de temps faut-il pour écrire une nouvelle interface utilisateur dans sa conception, et combien de temps faut-il pour une architecture en couches? Si le projet lui demandait de constamment créer et déployer de nouvelles interfaces utilisateur sur un modèle de données fixe, au lieu d'ajouter constamment des champs, j'espère qu'il l'aurait plutôt conçu pour cela. Ou aussi. Mais pour tous ses avantages, dire "nous faisons de l'agile" ne signifie malheureusement pas que vous n'aurez plus jamais à faire de compromis!
La sélection dans un menu de modèles de conception peut certainement vous empêcher de penser aux préoccupations les plus importantes. Mais reconnaître quand vous écrivez un Visiteur, et le documenter ou le nommer "Visiteur" pour aider les lecteurs à l'obtenir rapidement, ne gêne pas grand-chose. Écrire "c'est un visiteur" à la place de le documenter correctement est une terrible erreur pour la raison que votre développeur senior donne - les programmeurs ne le comprendront pas. Même les programmeurs qui savent ce qu'est un visiteur ont besoin de plus d'informations que "c'est un visiteur".
Votre collègue semble souffrir du syndrome NIH ("Pas inventé ici").
Il est parfaitement plausible que son code facilite l'ajout de nouveaux champs: je suis également beaucoup plus rapide pour mettre à jour mon propre code que le code écrit par d'autres gars. Mais cette vitesse à court terme ne dit rien sur la maintenabilité et la portabilité du code. Je vais lui donner le bénéfice du doute: le code existant pourrait en effet être mal structuré s'il a mal suivi un manuel ou suivi une bonne recette dans le mauvais contexte.
Éviter les modèles de conception est vraiment surprenant. Au cours de mes 30 dernières années de codage et de gestion de codeurs, les modèles de conception ont aidé à mettre des mots sur des choses qui se faisaient instinctivement, aidant ainsi à comprendre plus rapidement l'intention, les avantages, les inconvénients, les risques, les opportunités et les modèles associés. Les modèles de conception se sont révélés être de véritables accélérateurs pour maîtriser la complexité!
Peut-être que votre collègue est vraiment beaucoup plus intelligent que la plupart d'entre nous et qu'il peut se permettre les frais généraux de réinventer des modèles sans diminution notable de la productivité?
L'argument selon lequel "les programmeurs ne comprennent pas les modèles de conception" ressemble à "je ne peux pas vraiment expliquer ce que je fais". Ou "je ne veux pas discuter de mon propre design". Je pense vraiment que la structuration pourrait tirer parti de la compréhension globale et permettre à des collègues moins expérimentés de partager des opinions précieuses. Mais peut-être que votre collègue aîné veut éviter cela.
Les approches en couches se sont avérées supérieures aux autres architectures dans la plupart des applications d'entreprise. Des packages de premier plan de classe mondiale sont structurés autour de cette idée et surpassent les architectures artisanales par ordre de grandeur. Martin Fowler présente cette approche dans son excellent livre sur "Patterns of enterprise architecture". Oh! Désolé encore: il s'agit de modèles éprouvés; aucune chance dans la vision NIH de votre collègue ;-)
Un aperçu clé que beaucoup de gens ignorent est que la conception de logiciels est contextuelle. Il existe pour atteindre des objectifs commerciaux, et différents objectifs peuvent nécessiter des approches différentes. Autrement dit, il n'y a pas de design qui soit toujours le meilleur, même s'il y a toujours un meilleur design.
Les modèles de conception sont des solutions standard aux problèmes standard. Cependant, si vous n'avez pas le problème, le résoudre est une perte d'effort.
La principale différence entre une conception logicielle en cascade et agile est quand les décisions de conception sont prises. En cascade, nous rassemblons toutes les exigences, identifions les modèles de conception dont nous avons besoin, puis commençons à coder. En architecture agile, nous suivons le principe de YAGNI pour reporter les décisions de conception jusqu'au dernier moment responsable, lorsque nous en savons autant que possible sur le choix.
Autrement dit, dans la cascade, les modèles de conception ont tendance à être appliqués si leur besoin est prév, en agile, quand ils sont réellement nécessaires. Par conséquent, les projets agiles ont tendance à appliquer moins souvent des modèles de conception, car tous les besoins anticipés ne sont pas réels.
Les modèles de conception ne sont pas vraiment appelés modèles de conception, car ils prescrivent quoi faire. Les modèles de conception sont des modèles de conception car ils décrivent ce qui a été fait auparavant. Certains développeurs ou développeurs ont conçu une méthode qui a bien accompli une tâche particulière et ont pu l'appliquer à des situations similaires avec des résultats similaires. C'est tout. De nombreux modèles ont des forces et des faiblesses inhérentes, et il appartient au développeur instruit d'évaluer les besoins technologiques et commerciaux afin de déterminer un modèle approprié à appliquer.
Dans cette optique, à moins que vous ne vous engagiez vraiment à écrire du code 100% unique, où aucun concept ou implémentation n'est utilisable d'un cas d'utilisation à l'autre, vous utilisez presque certainement au moins certains modèles de conception. Ils peuvent ne pas avoir de noms communs flashy comme "Repository" ou "Unit of Work" ou même "MVC", mais cela ne fait pas d'eux "pas un modèle de conception".
J'aime généralement y penser de la manière - disons - "navigation" en utilisant le GPS. Lorsque vous apprenez les "meilleures pratiques" et les "modèles de conception" - vous apprenez à suivre l'itinéraire de navigation GPS. Mais lorsque vous connaissez la région, vous apprendrez souvent que conduire sur une route secondaire vous mènera au-delà des zones problématiques, vous y conduira plus rapidement et/ou mieux. C'est à peu près la même chose quand il s'agit de ces choses - l'expérience vous permet de déconstruire votre boîte à outils et de prendre des raccourcis.
Apprendre les modèles de conception et apprendre les "meilleures pratiques" signifie que vous comprenez l'idée sous-jacente afin de pouvoir choisir dans une situation donnée. Parce que les situations réelles sont souvent plus complexes que les situations théoriques - vous aurez souvent des contraintes et des problèmes qui ne se trouvent pas dans les manuels. Les clients/clients veulent que leur produit soit rapide et généralement bon marché; Vous devez travailler avec du code hérité; Vous devez interagir avec des outils tiers qui peuvent très bien être des boîtes noires et inefficaces; et toutes sortes de choses. Votre situation est spécifique - les meilleures pratiques et modèles sont plus généraux.
L'une des principales raisons pour lesquelles de nombreuses personnes sur des sites comme SE vous donneront des réponses de "meilleure pratique" et des réponses de "modèle de conception" est que, parce qu'elles répondent de manière générale et abstraite, cela aide à fournir un langage commun pour résoudre un type de problèmes. Et pour vous faire apprendre.
Ainsi, les modèles de non-conception ne sont pas désapprouvés dans les environnements de développement Agile; Cependant, le développement est rarement assez général et abstrait pour s'adapter parfaitement à un modèle et le développeur (expérimenté) le sait.
L'ajout d'un nouveau champ à la couche UI/base de données/données prend 2-3 heures, alors que, comme dans son code, cela prend 30 minutes.
Si vous voulez "optimiser" un design, vous devez dire ce que vous essayez d'optimiser.
Par exemple, un vélo de course est un véhicule optimisé ... et un Boeing 747 est également un véhicule optimisé ... mais ils sont optimisés pour un ensemble d'exigences différent.
L'idée du modèle "MVC", par exemple, optimise pour des choses comme:
- Différentes vues du même modèle (la vue est indépendante du modèle)
- Chaque couche peut être développée séparément (par exemple par différentes équipes) et testée séparément (tests unitaires) avant l'intégration
- etc.
Alors que son code peut être optimisé pour autre chose, par exemple:
- Lignes de code minimales
- Facile pour une seule personne d'effectuer un changement qui affecte toutes les couches (en n'ayant pas de couches vraiment distinctes du tout)
- etc.
Les descriptions de modèle commencent par une description du problème que le modèle est censé résoudre. S'il pense que c'est "la meilleure pratique" de ne pas utiliser un modèle spécifique, alors (en supposant que ce n'est pas un modèle stupide, en supposant que c'est un modèle qui est utile parfois) je suppose qu'il n'a pas/n'a pas l'expérience du problème spécifique que ce modèle prétend à résoudre, et/ou il a un problème différent (plus grand ou plus urgent, concurrent) qu'il essaie d'optimiser à la place.
Les modèles de conception sont des outils. Comme les outils, il y a deux façons de les utiliser: la bonne et la mauvaise. Par exemple, si je vous donne un tournevis et un clou, et que je vous demande de joindre deux morceaux de bois ensemble, vous devriez demandez-moi un marteau. Les marteaux sont utilisés pour les clous, tandis que les tournevis sont utilisés pour les vis.
Trop souvent, un modèle de conception est annoncé comme le One True Way, qui n'est souvent vrai que lorsque des problèmes particuliers surviennent. Les développeurs juniors sont souvent comme des enfants quand ils trouvent quelque chose de nouveau pour jouer avec; ils veulent appliquer ce modèle de conception à tout. Et il n'y a rien de mal à cela, tant qu'ils apprennent finalement que le motif A s'applique au problème B et que le motif C s'applique au problème D. Tout comme vous n'utilisez pas de tournevis pour enfoncer les clous, vous n'utilisez pas un particulier modèle juste parce qu'il existe; vous utilisez le modèle parce que c'est le meilleur outil (connu) pour le travail.
Le revers des motifs est anti-motifs. Des choses qui se sont révélées mauvaises à maintes reprises, généralement en termes de temps d'exécution ou de mémoire. Cependant, les modèles et les anti-modèles ne servent à rien au développeur qui ne comprend pas pourquoi ils existent. Les développeurs aiment penser que ce qu'ils font est nouveau et inventif, mais la plupart du temps, ils ne le sont pas. Cela a probablement été pensé auparavant. Les gens avant eux ont créé les modèles à cause de l'expérience.
Bien sûr, les développeurs juniors semblent souvent trouver de nouvelles façons de faire de vieilles choses, et parfois ces méthodes sont meilleures. Cependant, trop souvent, cela finit par être un cas de l'effet Dunning-Kruger; le développeur en sait juste assez pour créer un programme fonctionnel, mais ne comprend pas ses propres limites. La seule façon de surmonter cela semble être l'expérience, à la fois positive et négative. Ils ignorent les modèles parce qu'ils se croient supérieurs, mais ne savent pas qu'en réalité, 10 000 développeurs ont déjà utilisé une conception spécifique, puis l'ont rejetée car elle était en fait mauvaise.
Agile favorise "faire avancer les choses de manière réactive" en ce qui concerne l'adaptation rapide à l'évolution des besoins des clients. Il ne favorise ni les motifs de conception ni les méprise. Si un modèle est la méthode la plus rapide et la plus fiable, le développeur doit l'utiliser. Si un modèle particulier coûtait plus de temps que simplement "le faire", utiliser quelque chose qui n'est pas un modèle est probablement correct (en supposant, bien sûr, que les performances ne sont pas gravement dégradées, etc.). Si aucun modèle connu ne peut être trouvé, il est préférable de concevoir le leur plutôt que de dire "non" à un client. Les clients, en particulier les clients payants, ont généralement raison.
Quiconque prétend que les modèles sont The Way, ou prétend que les modèles sont The Bane Of Existence, a tort. Les modèles sont des outils, destinés à être appliqués à des situations spécifiques, et ont différents degrés de succès en fonction des circonstances. C'est une vérité, qui ne dépend pas de si vous avez choisi MVC ou non, si vous utilisez des objets de transfert de données, ou non, etc. et est raisonnablement exempt de bogues logiques.
Habituellement, les modèles permettront une forme cohérente de conception et fonctionneront mieux que d'ignorer tous les modèles en faveur de l'écriture d'idées 100% originales, mais vous ne pouvez pas éviter tous les modèles. Par exemple, si y = x + 5, allez-vous vraiment écrire y = x + (5 * 3 + 15/3)/4, juste pour éviter le modèle d'écriture x + 5? Non, tu ne l'es pas. Vous allez écrire y = x + 5 et passer au problème suivant.
Les gens utilisent des modèles tous les jours, et ça va. Ce qui importe le plus, c'est d'avoir un code qui est logiquement fonctionnel, se bloque rarement et est convivial. Rien d'autre n'a plus d'importance que cela.
Vous ne pouvez pas "éviter les modèles de conception", sauf je suppose en évitant de concevoir deux parties de votre système de la même manière (ce que je ne recommande pas et je doute que votre développeur principal le fasse). Ce qu'il veut probablement dire, c'est "éviter aveuglément d'utiliser un dessin simplement parce qu'il adhère à un motif de dessin". Penser à ce que vous faites est définitivement une "meilleure pratique", et une université devrait exister pour enseigner; malheureusement, cela ne semble pas se produire.
Les modèles de conception ne sont pas antithétiques aux pratiques agiles. Ce qui est antithétique aux pratiques agiles, c'est d'utiliser des modèles de conception dans le but d'utiliser des modèles de conception, la pratique courante chez les nouveaux diplômés et les étudiants de réfléchir à la manière de "comment allons-nous résoudre ce problème en utilisant un modèle d'usine".
Agile signifie choisir le meilleur outil pour le travail, PAS essayer de façonner le travail pour l'adapter à l'outil que vous avez sélectionné.
Et c'est à cela que TOUTES les pratiques de développement de bon sens se résument (bien que souvent vous devez bien sûr faire des compromis parce que la sélection d'outils parmi lesquels vous pouvez choisir est généralement limitée par les normes d'entreprise, les restrictions de licence (comme la GPL et parfois d'autres outils open source ne peuvent souvent pas être utilisés, en particulier lors de la création de logiciels pour la revente), et des choses comme ça.
Votre collègue/ami s'est probablement opposé à votre code non pas parce qu'il utilise des modèles de conception en soi, mais parce que c'est une construction artificielle conçue pour montrer l'utilisation d'un modèle spécifique alors qu'une autre conception aurait été meilleure (bien que souvent subjective, J'ai (et beaucoup avec moi sans doute) vu de nombreux exemples où l'utilisation forcée d'un modèle de conception spécifique a conduit à un code laid, difficile à maintenir et très inefficace).