Est-ce un mauvais signe que je suis souvent en train de refaire la conception lorsque je développe un projet?

Lorsque j'ai commencé à programmer, je pensais qu'un jour, je commencerais un projet en dessinant un diagramme UML de toutes les classes, puis je m'en tiendrai à cela. Je programme depuis quelques années et cela ne se passe pas ainsi. En passant par un projet, je dis souvent

• "Hé, j'ai besoin d'un cours à faire _ _. Je n'y avais pas pensé avant."
• "Attends, cette fonction devrait vraiment être dans cette classe à la place de celle-ci. Je vais la déplacer."
• "Cela devrait en fait être deux classes au lieu d'une. Je vais la séparer."
• "Je devrais faire en sorte que ces trois classes autonomes héritent toutes d'une classe abstraite."
• Etcetera, etc.

Est-ce un mauvais signe que je suis souvent en train de refaire ce projet au fur et à mesure? Est-ce que cela signifie que je suis un mauvais programmeur ou est-ce normal?

C'est une partie normale du développement. Deux des principes fondamentaux de la conception continue sont les suivants:

1. Vous n'êtes pas omniscient, vous ne pouvez pas connaître tout le système du début à la fin avant de commencer.
2. Le design n'est pas statique. Ceci est plus courant lorsqu'un projet est utilisé depuis longtemps et que les problèmes qu'il résout maintenant ne sont pas les problèmes qu'il était en train de résoudre lors de sa première rédaction.

Mon point de vue personnel sur le sujet est que vous devriez avoir une bonne idée de la conception macro , tout en permettant à la conception micro d'évoluer. Une autre façon de l'exprimer est que la conception de haut niveau (qui est aussi loin que je peux avec UML / outils de modélisation) restera très probablement statique pendant toute la durée d'un projet. La conception détaillée des méthodes qui font quoi et la hiérarchie de classes doivent être libres pour être malléables.

Lorsque vous ne savez vraiment pas grand-chose du problème que vous résolvez, vous ferez beaucoup plus d'erreurs initiales. Cependant, une fois que vous aurez suffisamment travaillé avec ce dernier, la conception globale commencera à s’installer et les refactorisations dont vous parlez sont tout ce qui est nécessaire pour maintenir le code en ordre.

Ce que vous faites est communément appelé "refactoring". Si vous arrêtez de le faire, vous avez des problèmes.

Le fait est que la plupart du code est complexe et que les humains, même les plus intelligents, ne peuvent pas tout comprendre en même temps.

Non, vous semblez suivre YAGNI et refactoriser à partir des exemples donnés. Ne pensez-vous pas qu'il est préférable d'avoir cette meilleure solution et de pouvoir le faire plutôt que de ne plus jamais penser à quelque chose?

Le développement logiciel agile a généralement des pratiques adaptées à cette situation, qui sont assez différentes du modèle en cascade.

C'est parfaitement correct (à moins que ces modifications ne soient toujours des révisions majeures ou des reconstructions à partir de zéro). Ne t'inquiète pas. Il peut être bon de commencer par un diagramme UML au début du projet, mais ne le gravez pas dans le marbre, car vous découvrirez presque toujours que les choses changent en cours de travail. Vous apprendrez peut-être de nouvelles techniques que vous ne connaissiez pas au début, vous voudrez peut-être améliorer certaines fonctionnalités comme vous ne l’aviez pas déjà fait lors de la conception initiale, les exigences de l’entreprise changent, il arrive parfois que des inconnues lors de la conception initiale ne être pris en compte plus tard, etc ...

Ce qui est important, c’est de mettre à jour ces documents UML initiaux de manière à ce qu’ils reflètent toute modification importante apportée à la conception, sans quoi les futurs développeurs (y compris vous-même) risqueraient d’être très confus. Cela peut être difficile et nécessite souvent une bonne dicipline (et du temps).

C'est très très très rare de commencer avec un design et de le respecter à 100% jusqu'à sa mise en œuvre. Personnellement, je n'ai jamais vu une telle chose se produire, à l'exception de programmes très petits et triviaux.

Ce que vous faites est parfaitement normal (à condition de ne pas recommencer à zéro à chaque fois). J'y travaille depuis plus de vingt ans et le processus est toujours itératif.

Si vous résolvez exactement le même problème que vous avez résolu la dernière fois, vous ne pourrez tout concevoir et tout rester à l’avant, et même dans ce cas, vous pourrez probablement trouver une marge d’amélioration.

Je ne suis en aucun cas un développeur très expérimenté, mais je le fais aussi. Au cours des dernières années, ma capacité à construire mentalement l'architecture nécessaire s'est considérablement améliorée. Cependant, au moment d’écrire un logiciel, quelle que soit ma planification, il y a toujours des endroits qui ont besoin d’un peu de refonte. Des taches que je ne réalisais pas que je me répèterais jusqu'à ce que le code soit réellement écrit.

Mon propos de cet article est de dire que je fais tout dans votre liste et je ne pense pas que ces choses-là soient nécessairement mauvaises si elles ne se produisent pas constamment et n’ont pas un effet négatif réel sur votre productivité.

Cela s'appelle un processus itératif et c'est un concept de base dans toutes les techniques modernes de développement logiciel.