Comment puis-je empêcher mes projets de traîner avec des ajustements et des changements sans fin?

Après avoir élaboré un projet, il pourrait nécessiter trop de modifications et de changements pour le faire fonctionner correctement ...

Que puis-je faire pour éviter cela?

Il y a une règle simple, que j'applique tout le temps parce que j'ai tendance à être perfectionniste aussi. Et le perfectionnisme vous mène à la médiocrité.

Fixez une date limite. Expédier à cette date limite.

Pour éviter que votre logiciel d'avoir un unfishined état de fonctionnalité manquante qui le rendre inutilisable, utiliser cette définition de fait pour chaque fonction que vous produisez. Ne démarrez pas la fonctionnalité suivante avant que TOUTES les étapes soient terminées:

• Développer la fonctionnalité
• Le test est (couverture de code à 80%)
• Valider / intégrer
• Document (documentation technique et utilisateur final)
• Mettre à jour la note de publication (à la fois dans le fichier et peut-être pour votre site Web, y compris les captures d'écran)
• Mettre à jour l'installateur (si nécessaire)

Je suppose que vous pouvez créer une version en un clic de souris (en utilisant des scripts de construction)

Avant de donner ma réponse (ou une suggestion de réponse, vraiment), je dois dire que je n'ai pas beaucoup d'expérience dans les grands projets et je ne ferai que déclarer ce que j'ai lu et que je pense être l'une des causes. Je peux très bien me tromper, mais j'aurai très probablement appris quelque chose de tous les commentaires que je recevrai. ^^

Un facteur important, je crois, est de ne pas laisser votre code se détériorer pendant que le projet est en cours. Cela peut être évité de nombreuses manières, dont je ne connais que quelques-unes:

N'attendez pas trop longtemps avec le refactoring: le refactoring prend un certain temps, mais cela vaudra la peine de ne pas avoir à faire d'appels de fonction alambiqués simplement parce que vous ne pourriez pas être dérangé par la réécriture du code pour permettre ce paramètre supplémentaire. Un code plus intuitif et moins dupliqué réduit le nombre de bogues.

Réparer la fenêtre cassée: dans The Pragmatic Programmer , j'ai lu un phénomène connu sous le nom de fenêtre cassée. Les auteurs soutiennent que le code commencera à se détériorer de la même manière qu'un bâtiment se détériore: il commence par une fenêtre cassée. En code, cela signifie de vilaines corrections, des noms de variables, des fonctions; en général juste du mauvais code. J'ai trouvé cela vrai: je code mieux et je suis plus heureux de coder lorsque ma base de code est solide. S'il y a trop de fenêtres cassées, je n'ai souvent pas envie de faire l'effort d'écrire du bon code. Donc, si vous voyez une fenêtre cassée, réparez-la le plus rapidement possible; refactoriser si vous devez. Cela entraînera moins de bogues et des ajustements inutiles.

Et n'oubliez pas de lire la réponse de Pierre 303 .

Qu'est-ce que «trop» de modifications et de changements? La maintenance du logiciel peut prendre beaucoup plus de temps que le développement initial du logiciel. Il n'y a rien de mal à cela. Pour rester organisé, utilisez un outil de suivi des problèmes .

Quoi qu'il en soit, vous voudrez bien sûr au départ le rendre aussi bon que possible. Pour cela, rien ne vaut le test .