Comment diviser un problème en plus petites portions compréhensibles?

Question

Je ne sais pas s'il est possible de donner des conseils généraux sur ce sujet, mais s'il vous plaît essayer. Il est difficile d'expliquer mon cas, car il est trop complexe pour expliquer. Et c'est exactement le problème.

Il me semble buter constamment sur une situation où je tente de concevoir une partie de mon projet, mais il a tant de choses à prendre en considération le fait que je suis incapable d'obtenir une compréhension de celui-ci.

Y a-t-il des conseils généraux ou des conseils sur la façon de regarder mon système en petits morceaux à la fois? Comment trouver des portions plus petites qui pourraient être conçues séparément sur leur propre?

Answer 1

Vos principaux objectifs sont les suivants:

• forte cohésion : Code (méthodes, champs, classes) dans une seule pièce / module / partition doivent interagir de manière intensive; il devrait de sens pour ces éléments à connaître les uns les autres. Si vous trouvez que certains d'entre eux n'interagissent pas beaucoup avec le reste, ils appartiennent probablement autre ou devraient somwhere former leur propre partition. Si vous trouvez un code externe en forte interaction avec la partition et sachant trop sur son fonctionnement interne, il appartient probablement à l'intérieur. L'exemple typique se trouve dans le code OO écrit dans le style de la procédure, avec des objets de données « muets » et le code « manager » qui fonctionne sur eux, mais devrait vraiment faire partie des objets de données.
• couplage lâche : Interaction entre pièces / modules / partitions ne doivent passer par étroites, bien définies, des API bien documentées. Essayez d'identifier ces API et voir ce que le code est nécessaire pour les mettre en œuvre et quel code va les utiliser.

Answer 2

Créer un glossaire.

En d'autres termes, identifier les termes qui ont un sens au domaine du projet - et non du point de vue du programmeur, mais d'un utilisateur, qui connaît le sujet

.

Définissez ensuite les termes comme avec précision et discrètement que vous le pouvez. Une bonne définition sous cette forme peut servir comme une sorte de pseudo-code.

Puisque vous n'avez pas identifié même le domaine de votre problème, je vais choisir un exemple au hasard. Dans un système de personnel civil, vous pourriez avoir des termes tels que:

• billet : une durée de service (de la date de début à la date de fin) à une catégorie particulière et l'étape
• employé : une série de billets associés à un particulier SSN
• grade et échelon : ligne et colonne dans le calendrier général fédéral

Et ainsi de suite. Cela ne veut pas identifier les unités fonctionnelles, comme il semble que vous essayez de faire, mais il est une bonne étape préparatoire avant de le faire, afin que vous puissiez exprimer vos étapes fonctionnelles en termes bien définis.

Answer 3

Il est utile d'aborder la décomposition problème à la fois de haut en bas et de bas en haut.

Si vous éprouvez des difficultés à diviser un gros problème en deux ou plusieurs petits problèmes, essayez de penser aux plus petits problèmes possibles qui devront être résolus. Une fois que ceux-ci sont traitées, vous pouvez commencer à voir des façons de les combiner dans des problèmes plus importants que vous approchez de votre problème grand d'origine.

Answer 4

Quand je me trouve copier et coller des morceaux de code avec un minimum d'ajustements je me rends compte que c'est une « partition », puis créer une classe, la méthode, la fonction, ou autre.

En fait, toute l'approche orientée objet est ce qu'il est tout au sujet. Essayez de penser à votre demande que les choses tangibles qui font des choses. Écrire un code pseudo décrivaient ce que les choses sont et ce qu'ils font, je trouve beaucoup de « partitions » de cette façon.

Answer 5

Voici un essai, une sorte de conjecture sauvage.

Les gens sous-estiment généralement combien de temps il leur faudra pour faire le travail. Si le projet est grand, il est fort probable que vous aurez besoin de plusieurs personnes de travailler là-dessus, vous pouvez planifier avec cela à l'esprit. Maintenant, une personne peut être prévu de tenir un seul domaine dans la tête, de sorte que vous aurez besoin de lui expliquer exactement ce genre de tâche qu'il est censé faire.

Alors, je dirais que vous devriez essayer d'écrire une description de poste qui devrait englober autant que possible pour une personne de se concentrer sérieusement. Répétez jusqu'à ce que vous avez cassé votre projet en plusieurs parties que vous vouliez. L'avantage est que vous êtes prêt à assembler votre équipe. Mais si vous trouvez les pièces sont petites, peut-être vous serez toujours en mesure de le faire vous-même.