Design & amp; Codage - de haut en bas ou de bas en haut? [fermé]

Question

Lorsque vous codez, quelle est votre meilleure approche selon votre expérience?

1. Décomposez le problème en petits morceaux, puis mettez-les en œuvre.
2. Décomposez le problème, puis implémentez-le en utilisant une approche descendante.
3. Un autre?

Answer 1

Voici ce que je fais:

Comprenez d'abord le domaine. Comprendre le problème à résoudre. Assurez-vous que vous et le client (même si ce client est vous!) Êtes sur la même page en ce qui concerne le problème à résoudre.

Ensuite, une solution de haut niveau est proposée au problème et à partir de là, la conception se transformera en bulles ou en puces sur une page ou autre, mais le fait est qu'elle se transformera en composants pouvant être conçus.

À ce stade, j’écris des tests pour les classes écrites qui restent à édifier, puis je précise les classes pour réussir ces tests.

J'utilise une approche d'abord test et crée des composants fonctionnels et testés. C'est ce qui fonctionne pour moi. Lorsque les interfaces des composants sont connues et que les "règles" sont connues pour la manière dont elles se parlent et se fournissent des services, il s’agit généralement d’un exercice simple consistant à "tout brancher".

C'est comme ça que je le fais et ça a bien fonctionné pour moi.

Answer 2

J'ai tendance à concevoir de haut en bas et à mettre en œuvre de bas en haut.

Pour la mise en œuvre, construire les plus petites pièces fonctionnelles et les assembler dans les structures de niveau supérieur semble être ce qui me convient le mieux. Mais, pour le design, je dois partir de l’ensemble du tableau et le décomposer pour déterminer la nature de ces éléments.

Answer 3

Vous pouvez consulter le Manifeste Agile . De haut en bas et de bas en haut sont fondés sur la conception et la construction de Built It All At Once.

Le "logiciel de travail sur la documentation complète" signifie que la première chose que vous construisez est la plus petite chose utile que vous puissiez faire fonctionner. Haut? Bas? Ni.

Quand j'étais plus jeune, je travaillais sur des projets strictement top-down. Ça ne marche pas. En effet, ça ne peut pas marcher. Vous obtenez des montagnes de conception et de code redondants en conséquence. Ce n’était pas une bonne approche quand elle était appliquée sans réfléchir.

Ce que j’ai remarqué, c’est que l’approche Agile - de petits éléments qui fonctionnent - a tendance à décomposer le problème en parties pouvant être appréhendées toutes en même temps. Le top-down / bottom-up ne compte plus autant. En effet, cela n’aura peut-être aucune importance.

Quels types de pistes font: "Comment vous décomposez-vous pour le développement Agile?" L'astuce consiste à éviter de créer une grosse chose que vous devez ensuite décomposer. Si vous analysez un problème, vous trouvez des acteurs qui essaient de réaliser des cas d'utilisation et échouent parce qu'ils ne disposent pas de toutes les informations, ou qu'ils ne l'ont pas à temps, ou qu'ils ne peuvent pas exécuter leurs décisions, ou quelque chose du genre.

Souvent, ce ne sont pas de grosses choses qui nécessitent une décomposition. Lorsqu'ils le sont, vous devez résoudre le problème dans le sens des objectifs en arrière . Des objectifs aux choses qui vous permettent d’atteindre cet objectif, aux choses qui permettent aux facilitateurs, etc. Comme les objectifs sont souvent énormes, il s’agit généralement d’une démarche descendante - d’un objectif commercial général à un processus et à une étape détaillés.

À un moment donné, nous décrivons ces différentes étapes menant aux objectifs. Nous avons fait la partie analyse (décomposer les choses). Vient maintenant la partie synthèse: nous réassemblons ce que nous avons en éléments que nous pouvons réellement construire. La synthèse est ascendante. Cependant, ne nous laissons pas emporter. Nous avons plusieurs points de vue, chacun étant différent.

Nous avons un modèle. Ceci est souvent construit à partir de détails dans un modèle conceptuel plus large. Ensuite, parfois décomposé à nouveau dans un modèle normalisé pour OLTP. Ou décomposé en un schéma en étoile normalisé pour OLAP. Nous travaillons ensuite en arrière pour créer un mappage ORM à partir du modèle normalisé. Haut - Bas - Haut.

Nous avons un traitement. Cela se construit souvent à partir de résumés des processus métier jusqu'aux détails des étapes de traitement. Ensuite, le logiciel est conçu autour des étapes. Ensuite, le logiciel est divisé en classes et méthodes. Bas - Haut - Bas.

[ Digression . Pour les utilisateurs éclairés, cette décomposition définit de nouveaux intitulés de poste et de nouvelles méthodes de travail. Avec des utilisateurs non éclairés, les anciens travaux restent en place et nous rédigeons des tonnes de documentation pour mapper les anciens travaux sur un nouveau logiciel.]

Nous avons des composants. Nous regardons souvent les pièces, regardons ce que nous savons des composants disponibles et faisons une sorte d’appariement. C'est le processus le plus aléatoire. cela ressemble à la façon dont les cristaux se forment - il y a des centres de nucléation et le type de conception se solidifie autour de ces centres. Services Web. Base de données. Gestion des transactions. Performance. Le volume. Différentes fonctionnalités qui nous aident d’une certaine manière à choisir les composants qui implémentent tout ou partie de notre solution. On se sent souvent de bas en haut (d’une fonctionnalité à l’autre), mais parfois de haut en bas ("Je tiens un marteau, appelez tout un clou" ==, utilisez le SGBDR pour tout.)

Finalement, nous devons coder. C'est de bas en haut. Genre de. Vous devez définir une structure de package. Vous devez définir les classes dans leur ensemble. Cette partie était en haut. Vous devez écrire des méthodes dans les classes. Je fais souvent cela de manière ascendante - ébauchez la méthode, écrivez un test unitaire, terminez la méthode. Préparez la méthode suivante, écrivez un test unitaire, terminez la méthode.

Le principe de base est Agile - construisez quelque chose qui fonctionne. Les détails sont omniprésents: haut, bas, avant, arrière, données, processus, acteur, domaine, valeur commerciale.

Answer 4

Oui. Faites toutes ces choses.

Cela peut sembler sarcastique (désolé, je reviens à la forme), mais c’est vraiment un cas où il n’ya pas de bonne réponse.

Answer 5

Également de manière agile, écrivez d'abord votre / vos test (s)!

Tous les logiciels sont alors un cycle continu de

• rouge - le code échoue au test
• Vert - le code réussit le test
• Refactor - améliorations de code préservant l'intention.

défauts, nouvelles fonctionnalités, modifications. Tout suit le même schéma.

Answer 6

Votre deuxième option est une solution raisonnable. Si vous divisez le problème en morceaux compréhensibles, l’approche descendante révélera tout défaut de conception majeur avant que vous ne mettiez en œuvre tous les petits détails. Vous pouvez écrire des stubs pour des fonctionnalités de niveau inférieur pour que tout reste en place.

Answer 7

Je pense qu'il y a plus à considérer que la conception descendante. Vous devez évidemment diviser la conception en unités de travail gérables, mais vous devez également tenir compte de la hiérarchisation, etc. .

Answer 8

Lors de la conception, j'aime faire du middle-out. J'aime modéliser le domaine, puis concevoir les classes, passer à la base de données et à l'interface utilisateur à partir de là. S'il existe des fonctionnalités spécifiques basées sur l'interface utilisateur ou sur la base de données, je peux également les concevoir en amont.

Lors du codage, j'aime généralement faire de bas en haut (base de données d'abord, ensuite entités commerciales, puis interface utilisateur) dans la mesure du possible. Je trouve qu'il est beaucoup plus facile de garder les choses droites avec cette méthode.

Answer 9

Je pense qu'avec de bons concepteurs de logiciels (et à mon avis, tous les développeurs de logiciels devraient également être des concepteurs de logiciels à un certain niveau), la magie est de pouvoir faire simultanément des tâches descendantes et ascendantes.

Ce que j'étais "scolarisé" faire par mes mentors, c’est commencer par une brève analyse descendante pour comprendre les entités impliquées, puis passer à la méthode ascendante pour comprendre les éléments de base que je veux créer, puis pour revenir en arrière et voir comment je peux descendre d’un niveau, sachant ce que je sais des résultats de mon ascension et ainsi de suite jusqu'à ce qu'ils se rencontrent au milieu.

L’espoir que cela aide.

Answer 10

Conception extérieure.

Vous commencez avec ce que vous essayez d’atteindre au plus haut niveau et vous savez avec quoi vous devez travailler au plus bas. Continuez à travailler des deux côtés jusqu'à ce qu'ils se rencontrent au milieu.

Answer 11

Je suis en quelque sorte d'accord avec toutes les personnes qui disent "ni", mais tout le monde tombe quelque part dans le spectre.

Je suis plus du genre à descendre. Je choisis une caractéristique / un point / peu importe de haut niveau et je l'implémente comme un programme complet. Cela me permet d’esquisser un plan et une structure de base dans les limites du domaine du problème.

Ensuite, je commence avec une autre fonctionnalité et refactorise tout ce qui, de l’original, peut être utilisé par la seconde en nouvelles entités partagées. Faire mousser, rincer et répéter jusqu'à la fin de l'application.

Cependant, je connais beaucoup de gens qui sont de la base, qui entendent un problème et commencent à penser à tous les sous-systèmes de support dont ils pourraient avoir besoin pour construire l'application au-dessus de celui-ci.

Je ne crois pas que l'une ou l'autre approche soit mauvaise ou incorrecte. Ils peuvent tous deux obtenir des résultats. J'essaie même de trouver des collaborateurs de la base, car nous pouvons nous attaquer au problème sous deux angles différents.

Answer 12

Ce sont deux approches valables. Parfois, on se contente de "sentir" plus naturel que l'autre. Cependant, il y a un gros problème: certains langages traditionnels, et en particulier leurs frameworks et leurs bibliothèques, fortement sur le support IDE, tels que la coloration syntaxique, la vérification du type d'arrière-plan, la compilation en arrière-plan, la complétion de code intelligente, IntelliSense, etc. .

Cependant, cela ne fonctionne pas avec le codage de haut en bas! Dans le codage de haut en bas, vous utilisez constamment des variables, des champs, des constantes, des fonctions, des procédures, des méthodes, des classes, des modules, des traits, des mixins, des aspects, des paquets et des types que vous n'avez pas encore implémentés! Ainsi, l'EDI ne cessera de vous gueuler à cause des erreurs de compilation, il y aura des lignes rouges ondulées partout, vous n'obtiendrez pas de code complet etc. Donc, l’EDI vous interdit à peu près de coder de haut en bas.

Answer 13

Je fais une variante de haut en bas. J'ai tendance à essayer d'abord l'interface - je l'utilise ensuite comme liste de fonctionnalités. Ce qui est bien dans cette version, c’est que cela fonctionne toujours avec IDE qui autrement se plaindrait. Mettez en commentaire l’appel d’une fonction à ce qui n’a pas encore été implémenté.