Comment dois-je planifier ma base de code? [fermé]

Je travaille actuellement sur un projet qui est sur le point d'atteindre plus de 5 000 lignes de code, mais je n'ai jamais vraiment pensé au design. Quelles méthodes dois-je utiliser pour structurer et organiser mon code? Du papier et un stylo? Diagrammes UML? Autre chose?

Vous obtenez probablement autant de vues différentes qu'il y aura de réponses. Mais voici mon point de vue.

Pour commencer, plus de 5000 lignes de code est un très très petit projet. Maintenant, comment allez-vous concevoir des projets qui grandissent. Premièrement, vous concevez votre système et non un code. Le code est en fait secondaire à l'architecture. Commencez par prendre en charge les exigences actuelles minimales. Mettez un dessin simpliste des composants impliqués. Personnellement, j'aime UML, mais tout ce qui est visuel sera bon. Idéalement, vous souhaitez adhérer aux bonnes pratiques de conception ici (interfaces, séparation des préoccupations, etc.).

Une fois que vous avez pris en charge des exigences minimales dans votre conception, codez-la. Encore une fois, essayez de respecter les bonnes pratiques de codage.

Après cela, ajoutez de manière itérative plus de fonctionnalités à mesure que de nouvelles exigences apparaissent. Idéalement, vous souhaitez également mettre à jour votre conception.

Ce qui est important, d'après mon expérience, n'est pas de concevoir votre système en prévision d'exigences non existantes. Sinon, votre projet grandira très rapidement et deviendra très complexe en peu de temps. Encore une fois - adhérer aux bonnes pratiques et commence par les exigences actuelles concrètes.

Diagramme de flux, diagramme de classe, diagramme de cas d'utilisation sont les diagrammes indispensables pour les grands projets. Recherchez et sélectionnez les bibliothèques externes dont vous avez besoin et recherchez les codes open source similaires que vous pouvez utiliser (pour apprendre et réduire le temps de développement).

Je vous suggère d'acheter un tableau blanc et des aimants colorés et Post-It. Il vous aidera à identifier vos tâches.

les lignes de codes ps 5000+ ne sont pas "grosses", cependant. Un logiciel CMS / Forum possède bien plus de 5000+ lignes de codes.

Je créerais des diagrammes de package et de classe. Dans le diagramme de package, je serais intéressé à regrouper les classes et les interfaces de manière logique. Je voudrais également créer des packages internes etc ...

Mais vous devez d'abord réfléchir à ce que le programme doit faire. Vous pouvez créer des diagrammes de cas d'utilisation ou le faire manuellement. Je le fais manuellement avec le diagramme de classe parce que je préfère obtenir le code immédiatement et il est plus facile de basculer vers des diagrammes de classe de package plus tard. L'utilisation du diagramme de classe me donne ma java. Si je ne l'aime pas, je le modifie manuellement. Le nouveau code est automatiquement mis à jour dans mes diagrammes. J'ai une représentation visuelle de haut niveau mise à jour de mon code. Très utile car même si je code, je peux toujours prendre quelques minutes pour voir comment mon projet se déroule de manière graphique. Je viens de glisser-déposer des entités dans le bon package manuellement afin de l'organiser. Je pense que mon code est meilleur en utilisant un niveau supérieur de package d'abstraction et de diagrammes de classe.

_{(source: ejb3.org )}

certains de mes collègues ont dit que ma façon de travailler est de la merde .... mais j'aime ça :-)

Absolument. J'ai un petit tableau effaçable à sec "tablette" à utiliser pour ce genre de chose, mais utilisez ce que vous êtes à l'aise. L'important est que vous puissiez facilement prendre vos pensées en main et voir la situation dans son ensemble.

Certaines personnes préfèrent des plans plus formels, comme les diagrammes UML, mais je pense qu'il est trop facile de se faire prendre en microgestion à quoi devrait ressembler chaque méthode. Encore une fois, cependant, utilisez tout ce qui vous convient.

EDIT: Vous pourriez également être intéressé par la programmation alphabétisée . L'idée est que vous pouvez tout planifier et devenir progressivement plus précis. Par exemple, vous pourriez dire que votre programme comprend:

1. Obtenir du texte de l'utilisateur
2. Conversion du texte en image
3. Enregistrement de l'image résultante sur le disque

Ensuite, vous pourriez affiner votre idée de convertir le texte en image. Cela pourrait donc ressembler à:

1. Déterminer le nombre de lignes que le texte doit occuper
2. Choisissez des couleurs aléatoires pour le texte et l'arrière-plan
3. Traitez-le dans un format approprié

Ensuite, vous pourriez affiner l'idée de choisir des couleurs aléatoires, et bientôt vous n'écrivez plus que du code normal.

Pour moi, l'activité de développement de logiciels est une série de conceptions progressivement plus fines pour résoudre un problème particulier. Lorsque vous avez juste une idée de haut niveau de ce que vous construisez, votre conception peut être quelque chose de très haut niveau, comme "il y aura une application Web qui parle à une base de données SQL et à plusieurs services Web" ou quelque chose comme ça. Ensuite, lorsque vous percez les détails de chaque pièce, vous obtenez un grain plus fin dans la conception. Selon la complexité de la solution, il y aura plus ou moins d'itérations de l'effort de conception. L'itération finale consiste à créer le code réel qui implémente les niveaux supérieurs de la conception.

Pour moi, la différence entre l'architecture et le design est minime, et ce ne sont que des itérations différentes du processus que je décris ci-dessus. La ligne entre les deux est floue et différente selon les personnes.

Il existe un art pour décider dans quel niveau de détail de conception entrer, pour quelles parties de l'application et à quels moments du cycle de vie du projet. Pour les projets à haut risque et à haute complexité, vous souhaiterez peut-être avoir une conception très détaillée avant d'écrire une ligne de code. Pour les petits projets, vous pouvez vous en sortir en faisant très peu de conception initiale et en frappant simplement du code, puis en voyant ce qui ne fonctionne pas et en repensant ces zones. Il n'y a pas qu'une seule réponse écrite ici. Habituellement, c'est quelque part entre ces deux extrêmes.

J'ai un article de blog qui parle de certains des principes que j'utilise lorsque j'aborde l'architecture. Cela pourrait vous être utile lorsque vous réfléchissez dans ce sens. Certains articles sont spécifiques à .NET mais la plupart ne le sont pas.

Je me posais la même question. Maintenant, je pratique juste le développement piloté par les tests, et ne m'en fais pas. Je ne "planifie" pas du tout le code, sauf pour suivre les standards de l'architecture choisie. Quand je démarre un projet, j'ai une idée de ce qui va être nécessaire, mais au fur et à mesure du développement, j'essaie de garder l'esprit ouvert. En suivant un développement piloté par les tests et en continuant de refactoriser le code, je n'ai pas à "planifier" le code. Je ne fais que satisfaire un cas de test après l'autre, et le design émerge du refactoring. C'est toujours une meilleure conception que tous les plans que j'aurais pu faire avant de coder.