Quels sont les avantages du design pour les programmeurs?

Question

Nous pouvons tous écrire du code de programme et simplement concevoir la solution dans nos têtes. De même, lorsque nous conservons du code existant, nous pouvons voir la conception du code s'il est bien écrit. Beaucoup de gens considèrent la documentation comme un fardeau inutile qui cause principalement du travail supplémentaire, car les documents doivent également être mis à jour.

L'autre option est que nous créons d'abord des documents de conception, puis que nous programmons la solution en fonction de la conception, puis que nous continuons à mettre à jour les documents. Nous pourrions utiliser le concepteur séparé pour créer les documents de conception ou nous pouvons concevoir par nous-mêmes.

Quels sont les avantages de la conception pour les programmeurs? Ou est-ce bien d'aller commencer la programmation sans documents de conception séparés? De quoi ont besoin les documents de conception du point de vue du programmeur?

Answer 1

Pour tout mais le logiciel le plus trivial, vous devez faire la conception dès le départ, sinon vous aurez soit

A.) tombent à plat sur le cul B.) Avoir un logiciel buggy C.) un problème de refactoring grave plus tard À mon avis, le cerveau humain passe à côté de faits sur lesquels il n'est pas disposé à composer à l'époque. Dans le cas de la conception de logiciels, je conçois toujours en amont pour m'assurer que j'ai quelque chose sur papier que je suis sûr de pouvoir travailler, et est concis, fonctionnel, extensible, etc. de manière optimale.

Answer 2

Si vous devez terminer un logiciel de qualité à temps, vous devez obtenir certaines exigences sur papier avant le début du codage. Pour les applications métier, écrire chaque détail et le confirmer avec les experts du domaine évite de perdre du temps car les programmeurs ont fait de fausses suppositions.

Answer 3

Les programmeurs ont besoin d'au moins quelques informations avant de pouvoir peut commencer un projet, que ce soit sous la forme de documents de conception ou par le contact direct avec les personnes qui ont besoin du logiciel est évidemment discutable. Pour ma part, je suis dans le camp agile, où les gens et les interactions sont favorisées par rapport au processus et aux documents. Cependant, je suis également pragmatique, ce qui signifie que si vous n'avez pas accès à l'entreprise ou aux propriétaires de produits, alors vous devez bien sûr travailler à un certain design. Mais je serai toujours en faveur d'avoir une interaction personnelle sur les documents. Du point de vue agile (en fonction de votre saveur), les documents seront sous une forme de cartes d'histoire qui représentent des éléments de fonctionnalité individuels à développer et lorsque cette fonctionnalité est considérée comme «terminée». Les détails spécifiques de ce qui est développé viennent cependant de l'interaction et de la communication avec l'entreprise, et seront dans la plupart des cas formés par un design «évolutif».

S'il est vrai que les documents peuvent être mis à jour, et oui parfois cela arrive même, je trouve que la plupart du temps ce n'est pas le cas. Vous rencontrez également des cauchemars de versionnement, les développeurs travaillant sur le document incorrect, ou QA testant la version incorrecte. C'est un fait simple, dans une situation d'affaires en évolution rapide, dès que vous l'écrivez, il devient obsolète. La plupart des problèmes sont inconnus au moment de la conception et sont découverts au cours du processus de développement. Il est donc logique de consacrer plus de temps et d'efforts à la phase de développement qu'à la phase de conception où les hypothèses peuvent et sera incorrect. Vous ne pouvez pas concevoir pour quelque chose que vous ne connaissez pas! Le plus tôt vous arrivez et «découvrez» ces inconnues, le plus tôt vous pouvez faire évoluer votre conception pour répondre aux nouvelles exigences.

Answer 4

Pour les (très) petits projets, les programmeurs peuvent être en mesure de s'en sortir sans trop d'anticipation.Cependant, plus le projet devient important, plus la conception initiale devient importante.

Vous pouvez construire une niche sans trop planifier, mais imaginez construire un gratte-ciel sans plans architecturaux.

Les grands projets construits sans conception initiale dégénèrent rapidement en masses de code inaccessible.

Answer 5

Une erreur des programmeurs inexpérimentés, c'est de négliger la partie conception. Ils pensent que c'est du temps perdu, mais ce n'est pas le cas. Au contraire!

Une bonne conception réduit par la suite le travail. Y compris la recherche de bugs. Ne confondez pas les "documents d'architecture" avec les "documents de conception".

Answer 6

Comme indiqué dans cette question, design est ce qu'il faut pour mettre en œuvre les décisions architecturales, qui peut être déclarée comme spécifications documents au niveau métier ou une application. En ce qui concerne le niveau technique, il est possible d'établir des documents «de conception» (diagrammes UML, par exemple), mais ils doivent être synchronisés avec le développement à tout moment, ce qui peut être difficile à faire.

Les "documents de conception" habituels que je vois sont des diagrammes de classe rétro-ajustés du code.

Answer 7

Outre les éléments mentionnés ci-dessus, une conception, par exemple un diagramme de classes, peut vous aider à obtenir une vue d'ensemble. Au fur et à mesure que votre projet gagne plus de classes ou de modules, leurs rôles peuvent commencer à devenir flous et il est tentant de simplement placer des choses partout. Si vous maintenez la conception à jour, cela peut aider à renforcer les rôles prévus et aider le programmeur à placer les choses de façon plus appropriée, et éviter les dépendances trop compliquées et éventuellement circulaires. De même, un organigramme peut nous aider à rester concentrés sur la façon dont les parties doivent interagir.

Answer 8

Je crois que les documents de conception sont nécessaires. Une raison à cela est que vous n'avez pas à perdre autant de temps pour présenter un nouveau membre au projet en le laissant lire le code. Au lieu de cela, le nouveau membre peut jeter un coup d'œil sur la conception pour avoir une vue d'ensemble. Une autre raison est que si vous faites votre conception à l'avance (n'oubliez pas de répéter) vous trouverez probablement beaucoup de bugs dans la phase de conception qui est moins cher à "réparer" que si vous le trouvez dans la phase de développement/code. Vous êtes plus susceptible de trouver de meilleures solutions à vos problèmes si vous concevez d'emblée (avec des itérations). Il est plus facile (à mon avis) d'amener un collègue ou un membre du projet à revoir votre travail s'ils n'ont pas à lire le code, juste un document de conception (diagrammes UML etc ...).