La réutilisabilité est une caractéristique d'une bonne conception logicielle .
La réutilisabilité est-elle un gloss acceptable ("brève notation du sens") pour une bonne conception de logiciel? Pourquoi?
La réutilisabilité est une caractéristique d'une bonne conception logicielle .
La réutilisabilité est-elle un gloss acceptable ("brève notation du sens") pour une bonne conception de logiciel? Pourquoi?
Réponses:
La réutilisation est un indicateur d'une bonne conception. Cela indique que le couplage du système est suffisamment lâche et que la cohésion d'une unité particulière est suffisamment élevée pour faciliter la réutilisation sans rencontrer de problèmes de dépendance ou avoir à réécrire la plupart du code.
La réutilisation est largement une illusion. Il est manifestement impossible de mesurer la «réutilisabilité» d'une unité sans savoir à l'avance où ni comment elle va être utilisée. De nombreux développeurs essaieront de concevoir des composants "réutilisables" et découvriront souvent plus tard que les aspects spécifiques qu'ils ont essayé de rendre "flexibles" sont exactement ceux qui n'avaient pas besoin d'être.
J'utiliserais un autre "gloss": la testabilité.
Maintenant, je ne suis pas un partisan du TDD, et je ne ressens pas non plus le besoin de tester tout et n'importe quoi. Mais écrire des tests pour un composant vous donnera une très bonne idée de ses caractéristiques de couplage / cohésion, et très rapidement. Si cela dépend des abstractions, alors c'est un couplage lâche; vous trouverez facile de se moquer des dépendances et cela suggère une bonne conception. S'il a un objectif clair (voir aussi Principe de responsabilité unique ), son comportement sera relativement intuitif, vous trouverez facilement ce qu'il faut tester, ce qui suggère une bonne conception.
Bien entendu, cela ne garantit pas une bonne conception; la mise en œuvre réelle ou même l'ensemble de l'architecture peut être totalement inappropriée pour son objectif déclaré. Mais au moins, cela vous indique que vous ne travaillez pas avec du code spaghetti ou des objets divins.
S'il vous plaît, n'essayez pas de faire des suppositions sauvages quant à la "réutilisabilité" d'un composant, en particulier de ne pas l'utiliser comme preuve de "bonne conception". C'est quelque chose que vous ne pouvez établir qu'avec du recul, une fois qu'il est réellement réutilisé, et que la conception peut alors avoir considérablement changé.
Non.
La réutilisabilité est une bonne caractéristique, car elle peut accélérer le développement futur. (Bien que dans la pratique, très peu d'organisations voient le développement futur accélérer à peu près autant qu'elles l'espéraient.) Cependant, tout élément logiciel important comporte des parties spécifiques à cette application. De plus, lorsque des personnes sans expérience dans le domaine essaient d'écrire des logiciels réutilisables, elles masquent généralement cette pièce et réduisent les performances sans réussir à les rendre réutilisables.
Par conséquent, une bonne conception est modulaire et réutilisable uniquement là où vous pouvez voir que la pièce peut être réutilisée et là où vous avez l'expertise pour réellement atteindre la réutilisabilité. Ailleurs, vous devriez essayer de rendre les choses propres, mais ne vous inquiétez pas de la réutilisation. (Sauf à l'arrière de votre tête où vous prenez des notes de sorte que sur un futur système, vous aurez une idée de comment le rendre réutilisable.)
Je crois (et c'est ma conviction personnelle) que la relation entre la réutilisabilité et un bon design n'est pas réflexive, donc la réponse de base et simple est non . Si vous êtes intéressé par de bons guides de conception, consultez cet article wikipedia.
Une bonne conception de logiciel doit être réutilisable, au moins dans certaines parties centrales, je pense que très peu de gens réutilisent réellement le code source, car il est extrêmement complexe de concevoir le cœur d'un système pour être réutilisable dans de nombreux contextes différents (Et je dis cela par expérience)
Considérez une classe avec une énorme quantité de responsabilités (alias un Blob) effectuant toutes les tâches dont vous avez besoin mais sans aucune sorte de considérations de conception, vous avez peut-être vu le cas. La plupart des gens avec une classe comme celle-là l'utiliseraient encore et encore et je pense que nous devrons convenir que c'est une réutilisation, une réutilisation sans design.
J'espère que je n'ai pas trop gâché mes explications
Je pense qu'un meilleur indicateur d'une bonne conception est l'adhésion à des idées fondamentales telles que le principe de responsabilité unique et le maintien de la cohésion de chaque composant. En utilisant des abstractions avec une interface propre et concise et en maintenant la conformité avec le principal de substitution Liskov, nous encourageons la réutilisation sans essayer de prédire ce qui sera et ne sera pas réutilisé.
Le respect de ces principes de conception fondamentaux facilite le test et la réutilisation du code .
Bonne conception == bonne conception, la réutilisabilité est un sous-produit.
La réutilisabilité est souvent un objectif de conception implicite. Si vous pouvez créer un composant, ou une conception entière, de telle manière qu'il puisse être réutilisé plus tard, il semble évident que vous devriez le faire. Ce qui n'est pas toujours évident, c'est qu'il faut beaucoup de temps et d'efforts (et d'argent) pour rendre quelque chose de réutilisable, et l'avantage de la réutilisabilité doit donc être mis en balance avec son coût.
Une conception réutilisable qui coûte deux fois plus cher et / ou prend deux fois plus de temps à construire que ce dont le client a besoin n'est pas une bonne conception du point de vue du client, en particulier si le client n'a pas besoin de réutilisabilité.
Il existe un certain nombre d'attributs similaires qui sont souvent considérés comme des objectifs de conception implicites car ils semblent évidemment bons:
minimiser les coûts
minimiser le temps de développement
minimiser la complexité
maximiser la fiabilité
Ces éléments sont tous objectivement bons, mais peuvent ne pas toujours être importants pour un client particulier à un moment donné, il est donc important de bien comprendre ce dont votre client a besoin (même si ce client n'est que votre patron). Il y a un certain nombre d'aphorismes qui sont censés nous rappeler ce fait (par exemple "Fait mieux que parfait" et "Bon, bon marché, rapide: choisissez-en deux"), mais il est toujours facile de tomber dans le piège d'essayer de créer des logiciels qui sont excellents à tous égards, alors qu'en fait, ils ne sont pas toujours nécessaires à tous égards.
Pour arriver à la question du titre, alors: Non , la réutilisabilité n'est pas synonyme de bon design. La réutilisabilité peut être un élément utile d'une bonne conception particulière, mais uniquement lorsqu'elle est requise.
Pas nécessairement. Si vous faites quelque chose de réutilisable qui ne sera clairement jamais réutilisé, c'est une mauvaise conception.
Par exemple, si vous écrivez un fichier plein de données qui est unique à votre entreprise et que ces données doivent être importées une fois ailleurs, pourquoi se donner la peine de les rendre réutilisables?
Cela dit, si votre framework n'en a pas déjà un, le code à écrire dans un fichier peut être réutilisable. Ce serait une bonne conception.
Je dirais non, surtout parce qu'il ne décrit qu'un petit segment de code. J'ai trouvé que là où la convivialité est la plus importante se trouve au cœur même et aux bords extérieurs du territoire utilitaire, pas tant entre les deux. Je vais donner quelques exemples de choses où je pense que la réutilisabilité est une mesure utile de conception de qualité.
Élément essentiel
Trucs utilitaires
Pour les trucs CRUD qui occupent 70 à 80% de la plupart des applications, je ne pense tout simplement pas que la réutilisabilité soit une mesure précieuse.