Une grande partie de mon code présente un défaut de conception majeur. Terminez-le ou réparez-le maintenant? [fermé]

Je suis un élève du secondaire qui travaille sur un projet C # avec un ami à moi qui a à peu près le même niveau de compétence que moi. Jusqu'à présent, nous avons écrit environ 3 000 lignes de code et 250 lignes de code de test sur une durée de 100 commits. En raison de mes études, j'ai reporté le projet pendant quelques mois et récemment, j'ai pu le reprendre.

Au moment où je l'avais récupéré, j'avais compris que le code que j'avais écrit était mal conçu, notamment l'inclusion de threads excessifs dans le moteur de rendu, la mauvaise prévention des conditions de concurrence dans l'interaction entre le processeur émulé, le processeur graphique et la cartouche de jeu. , ainsi que du code qui est simplement redondant et déroutant.

Le problème est que je n'ai pas encore fini les fonctionnalités principales de mon programme, je ne peux donc pas vraiment refactoriser et je me sens découragé de continuer à être parfaitement conscient du fait que la conception de mon code est défectueuse. En même temps, je ne veux pas abandonner le projet; des progrès considérables ont été accomplis et le travail ne doit pas être gaspillé.

J'ai le sentiment que j'ai plusieurs choix: terminer simplement la fonctionnalité en contournant le mauvais design, puis refactoriser une fois que tout fonctionne, en arrêtant tout et en cherchant à tout démêler avant que le reste de la fonctionnalité ne puisse être terminé, puis en démarrant le projet. de nouveau pour qu'il soit frais dans mon esprit, ou abandonne carrément le projet en raison de sa taille excessive (essentiellement "retour à la planche à dessin").

D'après l'expérience des autres dans de tels projets, quel est le recours pour me remettre sur la bonne voie? D'après les réponses fournies sur ce site, le consensus général est que la réécriture est généralement inutile mais constitue une option disponible si le code ne peut pas être maintenu sans coût excessif. Je voudrais vraiment poursuivre ce projet, mais dans l’état actuel des choses, mon code n’est pas assez bien conçu pour que je puisse continuer, et un sentiment de découragement m’empêche de continuer.

Si j'étais à votre place, j'essaierais probablement de cette façon:

• d’abord, terminez le projet actuel - au moins partiellement - le plus tôt possible, mais dans un état opérationnel . Vous devez probablement réduire vos objectifs initiaux. Réfléchissez à la fonctionnalité minimale dont vous avez réellement besoin dans la "version 1.0".

• alors, et alors seulement penser à une réécriture à partir de zéro (appelons cette "version 2.0"). Peut-être que vous pouvez réutiliser une partie du code de la version 1.0. Peut-être que, après avoir de nouveau dormi à propos de la situation, vous pourriez prendre la décision de refactoriser V1.0 et d’économiser la majeure partie de celle-ci. Mais ne prenez pas cette décision avant de ne pas avoir de "preuve de concept V1.0".

Un programme de travail "1.0" est quelque chose que vous pouvez montrer aux autres, même lorsque le code est mauvais (ce que personne ne va se soucier de faire, à part vous-même). Si vous êtes en train de créer la V2.0 et que vous vous rendez compte que vous manquez de temps, vous avez toujours la V1.0 partiellement réussie, ce qui sera bien meilleur pour votre moral. Cependant, si vous ne terminez pas d'abord avec la V1.0, il y a de grandes chances que vous ne terminiez jamais la V2.0 car, à mi-parcours, il y aura un moment où vous serez de nouveau insatisfait du design, et ensuite? Allez-vous abandonner à nouveau la V2.0 et travailler sur la V3.0? Il y a un risque élevé de tomber dans ce cercle sans fin et de ne jamais finir.

Mieux vaut en profiter pour saisir l'occasion d'atteindre des objectifs intermédiaires plutôt que pour laisser des projets inachevés.

Les projets informatiques finis, même ceux qui sont défectueux, sont bien meilleurs que les projets inachevés.

Les inachevés peuvent aussi vous apprendre beaucoup, mais pas autant que ceux qui sont finis.

Vous ne le verrez peut-être pas maintenant, mais vous obtenez une énorme valeur de travail même avec un code défectueux.

Mon vote va pour finir et ensuite, peut-être, refactoring - si nécessaire. Lorsque vous commencez à travailler avec plus de projets, vous constaterez que, de manière surprenante, la partie "destinée à être refactorisée" reste intacte pendant des années, tandis que d'autres sont prolongées.

Du point de vue de l'emploi, dans la plupart des cas, vous obtiendrez plus de félicitations pour un projet terminé.

Je reprendrais volontiers le projet.

Vous êtes étudiant et vous continuez d'apprendre. Cela vous place dans une position très différente de celle à laquelle vous vous êtes lié.

• Vous n'avez aucune responsabilité professionnelle pour votre code; Si vous supprimiez tout le projet maintenant et vous en retiriez, vous ne subiriez aucune répercussion. C'est un avantage énorme pour un développeur. Dans la question que vous avez liée, ces développeurs essaient de maintenir un logiciel pour lequel les gens paient de l'argent, et même de minuscules bugs peuvent causer de gros problèmes aux clients, ce qui rend dangereux d'écrire à partir de zéro. Vous n'avez pas ce problème.

• En tant que projet personnel, c’est l’occasion idéale pour essayer de nouvelles choses et apprendre de vos erreurs. Il est bon que vous reconnaissiez que votre ancien code présente des problèmes, car cela signifie que vous avez appris à mieux faire. L'expérience d'essais et d'erreurs peut être inestimable pour les programmeurs débutants.

• Votre projet est relativement petit et vous n'avez essentiellement pas de tests. Il pourrait être aussi court que quelques nuits pour écrire 3 000 lignes à partir de rien, d’autant plus que vous avez déjà une idée de ce qu’il faut faire mieux la prochaine fois.

• Travailler dans une base de code défectueuse pèsera beaucoup plus sur votre moral que ne le ferait une réécriture.

Soit dit en passant, cela pourrait être une bonne occasion d’écrire un programme plus modulaire avec des tests unitaires. Cela facilite grandement la compréhension du code si vous y revenez après une longue pause et vous aide à éviter les erreurs que vous pourriez introduire accidentellement en raison de l'oubli.

Enfin, voici un avis sur la sagesse de faire parfois des pas en arrière pour aller plus loin.

Vous êtes probablement encore dans la partie "apprentissage rapide" de votre développement. Il y a de fortes chances pour que dans quelques mois, vous découvriez que votre tout nouveau design est horriblement brisé d'une manière dont vous n'aviez même pas conscience au début.

Faites avancer les choses - c’est la chose la plus importante à apprendre. Croyez-moi, je connais beaucoup de personnes (pas seulement les programmeurs) qui sont coincées dans la boucle "recommencez à zéro depuis que j'ai tant appris avant de commencer ce projet". Le problème est que cela ne finit jamais - jusqu'à ce que vous cessez d'apprendre de nouvelles choses, ce qui n'est pas un endroit agréable pour être :)

Il est également important de pouvoir terminer quoi que ce soit. Recommencer est excitant, cool, amusant ... mais si vous apprenez seulement cela, vous ne pourrez jamais rien finir. Encore une fois, ce n'est pas une capacité très utile, et cela ne donne pas l'impression de faire quelque chose d'utile (ou d'amusant). La vie est courte, le temps est limité, et vous ne pouvez pas continuer à vous entraîner sans résultat tangible - vous allez devenir complètement fou. Si vous êtes incapable de commencer à travailler parce que vous ne pouvez pas décider quelle approche adopter, vous êtes déjà dans la zone de danger.

Il y aura toujours des pulsions pour recommencer. Même dans un environnement d'apprentissage, ce sont probablement une mauvaise idée. Cela ne signifie pas que vous devez intégrer chaque prototype à une application prête pour la production, loin de là. Mais vous devez au moins passer à une phase de prototype opérationnelle - cela aidera probablement votre moral, et c'est un trait très utile pour un développeur de toute sorte. Faire avancer les choses . Et la partie amusante est que vous verrez rapidement qu'il y a un million de choses plus amusantes ou utiles que vous pouvez faire avec votre prototype plutôt que de "la réécrire à partir de zéro" - et dans de nombreux cas, même de la refactoriser. Tout ce que vous faites a un coût - à tout le moins, vous auriez pu faire autre chose entre-temps.

Je suis l’ idéologie "Faire que ça marche, Faire bien, Faire vite" dans le développement de logiciels.

1. Make it Work : écrivez la fonctionnalité principale pour que le projet soit utilisable. Faites ce que vous devez faire pour que tout fonctionne, même si cela signifie du code laid.
2. Make it Right : corrige les bugs et refactorise le code afin qu'il soit plus facile à lire, à comprendre et à maintenir.
3. Make it Fast : optimisez le programme en recherchant un bon équilibre entre vitesse, utilisation des ressources et facilité de maintenance.

Pour l'instant, vous n'avez pas terminé l'étape 1. Commencez par le faire fonctionner, puis vous pourrez vous inquiéter de la laideur de votre code. En fait, créer un produit fonctionnel est l’une des tâches les plus difficiles à réaliser pour les nouveaux développeurs, car ils sont tellement occupés à essayer de rendre leur code parfait du premier coup. Ils se retrouvent donc coincés dans Optimization Hell et n’arrivent jamais à finir. mettre en œuvre toutes les fonctionnalités. Vous devez apprendre à mettre de côté toutes ces préoccupations relatives à la refactorisation et à l'optimisation pour pouvoir vous concentrer sur le fonctionnement du logiciel. Une fois que vous aurez acquis un peu plus d’expérience, vous ferez naturellement plus de choses du premier coup, donc moins de refactorisation est nécessaire.

Gardez à l'esprit: l' optimisation prématurée est la racine de tout mal (voir cette excellente question de Programmers.SE pour une bonne discussion). Si vous passez trop de temps à réfléchir à l'amélioration de votre code, vous êtes pris dans une paralysie de l'analyse . Cela tue le projet. Il est préférable de simplement terminer le projet avant d'essayer de l'optimiser.

Pour citer un excellent conférencier motivateur: faites-le .

Comme toujours, il y a un xkcd pertinent:

Réécris-le. Le code qui ne fonctionne pas a peu de valeur et trois mille lignes ne représentent pas beaucoup de code. Cela ne prendra pas aussi longtemps que l'écriture du code que vous avez actuellement, et ce sera beaucoup mieux. J'ai souvent jeté cinq cents ou mille lignes de code médiocre, et souvent la réécriture prend un cinquième de temps.

La plupart des notions sur "ne pas réécrire" se rapportent à de grands systèmes réalisant des tâches importantes et subissant des changements constants pour répondre à l'évolution des besoins. Les réécritures de systèmes complexes utilisés réussissent rarement.

Votre situation est complètement à l'opposé. Vous avez une petite application sans utilisateur et les seules exigences sont celles que vous choisissez d'implémenter. Alors allez-y et réécrivez-le.

Redémarrer à partir de zéro est généralement une mauvaise chose dans les projets de la vie réelle, principalement parce que les projets de la vie réelle accumulent des corrections de bogues dont un développeur débutant n'a pas connaissance (par exemple, consultez les choses que vous ne devriez jamais faire , dans le blog Joel on Software ).

Néanmoins, les projets d'école n'héritent pas d'une telle histoire et commencent généralement par coder et concevoir en même temps avec une connaissance partielle de l'informatique et un manque d'expérience. Je considérerais votre première version comme un prototype, utilisé comme une preuve de concept qui a échoué, et je la jetterais volontiers (voir Quelles sont les différences entre les prototypes jetables et évolutifs? Pour une discussion sur le prototypage jetable et évolutif.)

La bonne conception a mûri dans votre tête et ne devrait pas prendre beaucoup de temps pour l'écrire en code.

Je serais respectueusement en désaccord avec les suggestions selon lesquelles la réécriture est une mauvaise idée.

Dans le domaine du cycle de vie d'un logiciel, il est généralement admis que le temps et les efforts nécessaires pour corriger une erreur augmentent d'un ordre de grandeur chaque couche du cycle de vie. En d’autres termes, s’il faut 1 heure pour corriger une erreur au niveau des exigences, il faudra 10 heures en conception, 100 heures en test de codage et 1 000 heures en tant que correction de bogue. Ces chiffres peuvent sembler scandaleux, mais ils sont reconnus par l'industrie comme approximativement correct. Évidemment, moins dans un projet plus petit, mais l’idée générale demeure. Si votre projet présente un défaut de conception élémentaire, il est plus approprié d’appeler cela une expérience d’apprentissage et de revenir en arrière, de passer en revue vos exigences initiales et de le revoir.

Je vous encourage également à envisager un modèle de développement piloté par les tests utilisant des tests unitaires structurés. Ils sont pénibles et semblent au départ une perte de temps, mais leur capacité à détecter les erreurs, en particulier lors de l'intégration au code de quelqu'un d'autre, ne peut être surestimée.

Tu m'as perdu à cette phrase:

Le problème est que je n'ai pas encore fini les fonctionnalités principales de mon programme, je ne peux donc pas vraiment refactoriser et je me sens découragé de continuer à être parfaitement conscient du fait que la conception de mon code est défectueuse.

Je crois au principe (énoncé dans Systemantics ) que

• On constate invariablement qu'un système complexe qui fonctionne a évolué d'un système simple qui fonctionne.
• Un système complexe conçu à partir de zéro ne fonctionne jamais et ne peut pas être corrigé pour le faire fonctionner. Vous devez recommencer, en commençant par un système simple et fonctionnel.

Ainsi, l'écriture d'un système complexe comprend

• Écrire un système simple
• S'assurer que cela fonctionne

... c'est-à-dire les étapes suivantes:

1. Écrire un peu de code
2. Testez-le pour vous assurer qu'il fonctionne
3. Ecrire un peu plus de code
4. Testez à nouveau
5. Etc.

Notez que l'étape 3 pourrait impliquer:

3. Ecrire un peu plus de code
   1. Refactoriser le code existant pour le préparer à une nouvelle addition
   2. Testez le refactoring pour vous assurer qu'il fonctionne toujours
   3. Ajouter la nouvelle fonctionnalité

En outre, l'étape 2 "Testez-la pour vous assurer qu'il fonctionne" peut impliquer une réécriture si cela ne fonctionne pas.

Si je construisais sur une base de code pourrie, je ne serais pas enclin à ajouter d'autres fonctionnalités. Donc, je serais enclin à planifier quelque chose comme "simplifier l'implémentation de threading existante" comme prochain travail à implémenter. En supposant que vous ayez effectué des tests au fil du temps, vous devriez pouvoir traiter ceci comme un exercice de refactoring. Les critères de réussite / de sortie pour cette phase de travail seraient:

• Le code source est plus simple
• Et pas de nouveaux bugs introduits
• (Et quelques vieux bugs éliminés)

Incidemment, "tester pour s'assurer qu'il fonctionne" ne signifie pas nécessairement "tests unitaires" - lorsque la structure d'équipe est simple, vous pouvez tester un système (simple) à l'aide de (simples) tests système (à la place de tests unitaires) .

L'un des problèmes que vous rencontrez lorsque vous rencontrez un problème comme celui-ci est que vous êtes émotionnellement attaché au code que vous avez écrit jusqu'à présent, d'une manière ou d'une autre.

Un collègue m'a dit qu'il écrivait un programme alors qu'il était à l'université alors qu'il suivait les cours d'un professeur célèbre (je crois que c'était Dijkstra). Il a demandé au professeur de consulter le code sur lequel il travaillait depuis plus d'un mois. Le professeur lui a demandé s'il avait fait une copie de sauvegarde, il a répondu non. Le professeur a ensuite supprimé tout son code et lui a demandé de l'écrire à nouveau.

Il était énervé, mais trois jours plus tard, il finissait le programme, avec un code plus propre, moins de bugs et moins de lignes de code.

Essayez de faire une estimation honnête de la meilleure option dans le temps disponible pour le projet.

Les 3 choix sont

• Supprimez-le (complètement, sans regarder en arrière)
• Continuer à travailler dans l'ancien design
• Code du refactor pendant que vous allez.

Je suis programmeur professionnel depuis plus de 10 ans et, dans mon travail, je conclus que la dernière option est la plupart du temps celle choisie, mais ce n'est pas toujours la meilleure option.

Il semble que vos compétences ont considérablement augmenté au cours de cette période. Peut-être que travailler sur ce projet y a contribué. Le concevoir à nouveau comme une expérience d'apprentissage intentionnelle serait fructueux.

N'oubliez pas que ce n'est pas quelque chose que vous devez offrir comme programme fonctionnel pour un client. Il a été écrit spécifiquement pour la pratique. Donc, à moins que vous vouliez vous entraîner à avoir des problèmes d'expédition et une livraison imparfaite, je pense que vous êtes actuellement dans une phase de développement où travailler avec vos "muscles du design" s'avérerait fructueux.

Ce faisant, concentrez-vous sur le processus de conception et la planification, réfléchissez au contenu existant et réfléchissez à ce que vous comprenez mieux.

Refactor. Refactor. Refactor! RÉFACTEUR !!!!

Honnêtement, peu importe votre niveau d'expérience, c'est un problème courant. Vous avez écrit du code, vous avez appris quelque chose et vous souhaitez utiliser les nouvelles connaissances sur l'ancien code. Vous voulez mesurer l'ancien code avec les nouvelles connaissances.

Cela ne marchera pas. Si vous faites cela, votre application / jeu ne sera jamais terminé. Au lieu de cela, essayez d’allouer votre temps au projet afin que certaines de vos «tâches» soient de refactoriser le code incorrect. Disons, par exemple, que vous avez eu une méthode horrible pour sauver la partie. Continuez à travailler sur le jeu lui-même, mais prenez le temps de refactoriser (remplacer) cette horrible méthode. Essayez de garder les refactors petits, et cela ne devrait pas être un problème.

Lorsque vous arrivez à une partie importante de l'application qui a besoin d'un refactor, vous le faites mal, sérieusement. Casser ce refactoring en petites parties. Essayez de passer sept heures à écrire du code et à une heure de refactoring.

Lorsque vous en avez terminé avec le projet et que vous activez le gel des fonctionnalités, vous pouvez alors consacrer un temps considérable à la refactorisation. Pour le moment, finissez le jeu, mais essayez quand même d’en refactoriser certains. C'est le mieux que tu puisses faire.

Il y aura toujours quelque chose à refactoriser.

Je dirais que cela dépend un peu du type de code que vous avez maintenant et du problème. Par exemple, si vos bases sont bonnes (conception de classe correcte dans la plupart des cas, bon découplage / cohésion, etc., juste quelques mauvais choix comme les fils que vous avez mentionnés), alors vous devez absolument obtenir une version nue 1.0 puis une refactorisation comme il n'y a pas de lendemain.

D'un autre côté, s'il ne s'agit en réalité que d'un tas de fichiers texte déplacés qui passent au compilateur, sans structure discernable, etc. (autrement dit, un prototype d'apprentissage sur le tas à l'essai), alors je préfère le supprimer et recommencer.

Sur votre prochaine version, faites une approche agile: définissez-vous un calendrier de répétition fixe, comme 2 semaines ou tout ce qui convient à votre emploi du temps. Au début de chaque morceau (appelons ça un sprint), fixez-vous des objectifs réalisables dans les 2 semaines. Allez-y et faites-les, essayez votre damndest pour le faire fonctionner. Définissez vos objectifs de manière à ce que toutes les deux semaines, vous puissiez présenter quelque chose à un ami, et pas seulement un travail interne abstrait. Google "scrum" et "objectif intelligent". Tout cela est très facile à faire, si vous êtes seul, juste un morceau de papier avec quelques points de balle rapidement notés.

Si vous pouvez le faire, recommencer est une bonne chose. Si vous savez au fond de vous qu'après tout recommencer, vous finirez probablement par retrouver votre position actuelle, de toute façon, restez fidèle à votre code et faites-le fonctionner.

Vous devez vous mettre à la place de l'employeur.

Pour la plupart des recruteurs, vous auriez le plus de valeur si vous procédiez ainsi: - Terminez le processus avec 100% de tests sur le nouveau code que vous écrivez. - Ajouter des tests pour l'ancien code (mal conçu). - Refacturez-le pour réaliser ce que vous vouliez en tant que conception.

Faites tout cela avec un bon processus de gestion des versions, des branches et des balises.

La réécriture est souvent une idée sexy, mais c'est souvent une idée des nouveaux arrivants qui est un peu dangereuse dans la vie réelle. Montrer que vous êtes plus disposé à améliorer la qualité du travail que vous avez déjà fait plutôt que de partir de zéro est un bon signe que vous êtes une personne sérieuse.

Vous pouvez évidemment le réécrire, mais faites-en un autre projet alors.

Juste pour ajouter une partie de mon expérience passée dans le mélange. Je travaille sur un projet parallèle depuis plus d'un an maintenant, chaque fois que je dispose de quelques minutes. Ce projet est passé d’un simple banc d’essai à une classe statique en passant par un design finement ligné orienté objet.

Au cours de toutes ces modifications, j'ai conservé la même fonctionnalité du code, à l'exclusion des corrections de bogues et des avantages en termes de performances (doit être aussi rapide que possible). La même base de code, bien que refactorisée, est restée la même et, de ce fait, je l’ai considérablement améliorée sans avoir à réécrire le code à partir de zéro et à perdre du temps.

Cela signifie que j'ai pu améliorer le code plus rapidement que je n'aurais pu le faire auparavant. Cela signifiait également que pendant que j'y allais, il était plus facile de dire ce qui devait être supprimé, à savoir les cours inutiles, et ce qui pouvait rester plus facile que de réécrire avec l'ancienne idée toujours dans mon esprit.

Par conséquent, mon conseil serait de refactoriser votre code et de procéder à des améliorations si nécessaire. N'oubliez pas que si vous décidez de réécrire à partir de zéro, vous devriez prendre les bonnes idées de l'ancien projet et les regarder de près pour voir où elles sont défectueuses. Par exemple, ne copiez pas simplement l'ancien code dans le nouveau projet.

La réponse dépend de quelque chose que j'aime appeler le "plafond de complexité". Au fur et à mesure que vous ajoutez de plus en plus à une base de code, celle-ci a tendance à devenir de plus en plus complexe et de moins en moins organisée. À un moment donné, vous atteindrez un "plafond de complexité", point auquel les progrès deviennent très difficiles. Plutôt que d'essayer de continuer à avancer par la force brute, il est préférable de sauvegarder, réorganiser / réécrire, puis de continuer à avancer.

Votre base de code est-elle si mauvaise que vous approchez d'un plafond de complexité? Si vous le sentez, prenez le temps de nettoyer et de simplifier avant de continuer. Si le moyen le plus simple de nettoyer est de réécrire certaines parties, c'est très bien.

Ni? Tous les deux?

Continuez, passez du temps à réviser la conception existante et à ajouter de nouvelles fonctionnalités.

Si vous avez des interactions racées, c'est peut-être un bon point de départ ("un nombre excessif de threads dans le moteur de rendu" semble plutôt inefficace, plutôt qu'un problème susceptible de causer des problèmes de correction). Voyez si vous pouvez trouver un moyen général d’éviter les courses (et éventuellement des impasses), ou au moins plusieurs moyens spécifiques de le faire.

Je ne sais pas dans quelle mesure des détecteurs de race et d'interblocage sont disponibles pour C #, mais s'ils existent, ils peuvent être utiles pour identifier les problèmes existants et pour vérifier que vos correctifs fonctionnent.

Je trouve qu'en général, je suis plus motivé pour résoudre les problèmes avec du code qui fait quelque chose d'utile, plutôt que de le jeter et de recommencer à zéro. Il y a des cas où le développement de champs brûlés (par analogie avec les terrains en friches et en friches ...) est plus satisfaisant, mais c'est généralement pour des choses où l'approche existante est tellement éloignée de l'endroit où il devrait être qu'il n'est même plus faux.

Si votre code est modulaire, vous devriez pouvoir terminer le reste du code autour des composants mal écrits, puis réécrire les composants mal écrits sans affecter le reste du code.

Dans ce cas, c'est à vous de décider de réécrire les composants mal écrits. Si les composants mal écrits sont si mal écrits que le code fini ne fonctionnera pas tels quels, vous devrez les réécrire avant de pouvoir terminer le reste du code.

La première question que vous devriez vous poser est la suivante: "quelle est la faille?"

Qu'as-tu fait de mal exactement?

Si quelque chose est si grave que vous allez perdre des heures à essayer de résoudre le problème, à exposer des données sensibles (mots de passe / cartes de crédit) ou à créer une vulnérabilité, vous devriez peut-être l'éditer, mais la plupart du temps prenez ce que vous avez, terminez-le et résolvez le problème plus tard.

Les programmeurs aiment améliorer leurs applications et souhaitent qu’elles soient «les meilleures possibles», mais ce n’est pas la bonne approche.

Si vous publiez votre application dès que possible, même si ce n'est pas à 100%, bugs et toutes choses , alors vous obtenez FEEDBACK des autres, tout en ayant le temps de corriger les bugs et autres éléments de la version 1.1. D’autres personnes pourront vous aider à améliorer l’application et vous aurez peut-être perdu du temps à faire quelque chose que les gens n’auraient pas aimé.

Donc, dans votre cas, publiez-le, obtenez des commentaires, puis vous pourrez structurer la version 2.0 avec tous les changements et corriger le défaut que vous avez.

Une autre chose à retenir est que nous nous améliorons constamment. Il y a un dicton qui dit que si vous pouvez regarder votre code d'il y a un an et voir que c'est mauvais, cela signifie que vous continuez de vous améliorer, et c'est une bonne chose.

Cela dépend de l'état de votre code.

• Si vous faites de vraies erreurs n00b qui rendent votre code excessivement complexe ou trop détaillé, je vous recommande de réécrire ces parties.

• Si vous pensez que vous avez des bugs sérieux que vous devrez corriger de toute façon, alors écrivez quelques tests unitaires qui peuvent vérifier si vous avez corrigé le bogue (... puisque vous ne pouvez pas encore lancer le programme). Il est préférable de réparer les bogues tôt, et il est certainement préférable de les corriger tout en gardant à l'esprit le code.

• Si vous n'aimez pas comment les méthodes sont appelées, ou à quelle classe elles appartiennent, ou de petites choses comme ça, utilisez simplement l'EDI. (N'oubliez pas qu'il s'agit de C # et non de javascript, de python, de perl, de php, etc.) Lorsque vous travaillez sur du code qui utilise le composant affecté, vous avez une idée claire de ce que ce composant doit faire, puis refactorisez-le si votre IDE le rend indolore.

Sinon, faites-le fonctionner et perfectionnez vos compétences lors du prochain projet.

Comme d'autres l'ont suggéré, comme il s'agit d'un projet personnel et non (encore) professionnel, je considérerais sérieusement une réécriture.

Cependant, vous pouvez utiliser la méthode scientifique ici, en effectuant une expérience. Premièrement, concevez une hypothèse. Le mien serait, "il est probablement temps pour une réécriture." Afin de gagner du temps, de réduire le coût des échecs et de limiter quelque peu les biais a priori, déterminez une durée avant de continuer à programmer, puis définissez une durée ("time box"). Je suggérerais peut-être 4 heures murales. Décidez également d’une méthodologie d’évaluation de l’hypothèse. Étant donné que les enjeux sont faibles, je suggérerais, en tant que méthodologie, de vous demander simplement: "Suis-je heureux de l'avoir fait?" Maintenant, commencez l'expérience. Après l’heure choisie, quelle est l’évaluation de l’hypothèse? Par exemple, d'après mon exemple, êtes-vous heureux d'avoir commencé à réécrire maintenant que vous avez passé 4 heures à le faire? Alors c'est probablement le bon choix.

Vous pouvez demander tous les conseils du monde, mais rien ne vaut tester une hypothèse de manière empirique.

Quelques raisons pour envisager de sélectionner une réécriture comme test:

• D'après mon expérience, c'est généralement plus amusant. Une des principales raisons pour lesquelles les réécritures ne sont souvent pas sélectionnées dans les situations professionnelles est que le plaisir est loin d'être le seul critère. Mais vous êtes encore relativement novice en matière de programmation, le plaisir est donc probablement un critère assez important, mais également un indicateur d'autres facteurs qui pourraient être intangibles pour vous à ce stade précoce (le plaisir suggère que vous en apprendrez davantage, etc.).
• Votre expérience et probablement un sens aigu de la conscience semblent vous dire qu'une réécriture est une bonne idée. Écoutez cette voix, s'il y en a une. Même si vous ne suivez pas ses conseils, écoutez au moins. À l'avenir, il y aura plus de voix externes et vous aurez besoin de vous entraîner à écouter votre propre bon sens.
• Je soupçonne qu'avec une réécriture, vous êtes plus susceptible de modulariser davantage votre code. Lorsque vous créez des modules, vous disposez de davantage de composants réutilisables et fiables que vous pouvez exploiter pour d'autres projets. Vous constaterez peut-être qu’en fin de compte, ce qui semblait être un simple module de votre projet principal s’avère être la partie de code la plus intéressante et la plus précieuse que vous écrivez.

Terminer quelque chose est une bonne idée, mais pas en vase clos. Si vous commencez une réécriture, vous pouvez choisir de terminer quelque chose en finissant un sous-module particulier. Vous pouvez définir cela comme premier objectif, après l'expérience ci-dessus. Finir ne signifie pas nécessairement terminer votre projet principal initial pour l'instant. Après avoir terminé un module, terminez-en un autre, etc., jusqu'à ce que vous ayez fini de réécrire tout le contenu de votre projet d'origine, si vous le souhaitez.