Une grande partie de mon code présente un défaut majeur de conception. Le terminer ou le réparer maintenant?
Je suis un lycéen travaillant sur un projet C # avec un de mes amis avec à 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 période de 100 commits. En raison de l'école, 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'ai compris que le code que j'avais écrit était mal conçu, comme l'inclusion de threads excessifs dans le moteur de rendu, une mauvaise prévention des conditions de concurrence dans l'interaction entre le CPU émulé, le GPU et la cartouche de jeu , ainsi que du code simplement redondant et déroutant.
Le problème est que je n'ai pas encore terminé la fonctionnalité principale de mon programme, donc je ne peux pas vraiment refactoriser, et je me sens découragé de continuer à être parfaitement conscient que la conception de mon code est défectueuse. En même temps, je ne veux pas abandonner le projet; des progrès substantiels ont été accomplis et les travaux ne doivent pas être vains.
Je me sens comme si j'avais deux choix: terminer simplement la fonctionnalité en contournant le mauvais design puis refactoriser une fois que tout fonctionne, arrêter tout et travailler à tout démêler avant que le reste de la fonctionnalité puisse être terminé, démarrer le projet partout pour qu'il soit encore frais dans mon esprit, ou abandonner carrément le projet à cause de sa taille excessive (essentiellement "retour à la planche à dessin").
Sur la base de 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 sur ce site, le consensus général est que la réécriture n'est généralement pas nécessaire mais une option disponible si le code ne peut pas être maintenu sans coût excessif. Je voudrais vraiment poursuivre ce projet, mais en l'état, 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, je l'essayerais probablement de cette façon:
tout d'abord, terminer le projet en cours - au moins partiellement - dès que possible, mais dans un état de fonctionnement. Vous devez probablement réduire vos objectifs d'origine, pensez aux fonctionnalités minimales que vous devez vraiment voir dans la "version 1.0".
puis, et seulement alors pensez à une réécriture à partir de zéro (appelons cela "version 2.0"). Vous pouvez peut-être réutiliser une partie du code de la V1.0. Peut-être qu'après avoir à nouveau dormi sur la situation, vous décidez que vous pourriez refactoriser la V1.0 et en conserver la majeure partie. Mais ne prenez pas cette décision avant d'avoir une "preuve de concept V1.0" à portée de main.
Un programme de travail "1.0" est quelque chose que vous pouvez montrer aux autres, même lorsque le code est mauvais (ce qui ne dérangera personne, sauf vous). Si au milieu de la création de la V2.0, vous réalisez que vous manquez de temps, vous avez toujours la V1.0 comme un succès partiel, ce qui sera beaucoup mieux pour votre moral. Cependant, si vous ne terminez pas la V1.0 en premier, il y a de grandes chances que vous ne terminiez jamais la V2.0 car lorsque vous serez à mi-chemin, il y aura un point où vous ne serez plus satisfait de la conception, 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, de ne jamais se terminer.
Mieux vaut saisir cela comme une opportunité d'apprendre à atteindre des objectifs intermédiaires, plutôt que comme une opportunité d'apprendre à laisser des projets dans un état inachevé.
Les projets informatiques terminés, même défectueux, sont bien meilleurs que les projets inachevés.
Ceux qui sont inachevés peuvent aussi vous apprendre beaucoup, mais pas autant que ceux qui sont terminés.
Vous ne le voyez peut-être pas maintenant, mais vous obtenez une énorme quantité de valeur en travaillant avec un code même défectueux.
Mon vote va pour terminer et ensuite, peut-être, refactoring - si nécessaire. Lorsque vous commencez à travailler avec plus de projets, vous verrez que, de manière surprenante, souvent la partie qui "devait être refactorisée" reste intacte pendant des années, tandis que d'autres pièces sont étendues.
Du point de vue de l'emploi, dans la plupart des cas, vous obtiendrez plus de félicitations pour un projet terminé.
Je recommencerais volontiers le projet.
Vous êtes étudiant et vous apprenez toujours. Cela vous place dans une position très différente de la question à laquelle vous avez lié.
Vous n'avez aucune responsabilité professionnelle pour votre code; si vous supprimiez tout le projet maintenant et que vous vous retiriez, vous ne subiriez aucune répercussion. C'est un énorme avantage 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 avec les clients, ce qui rend dangereux l'écriture à partir de zéro. Vous n'avez pas ce problème.
En tant que projet personnel, c'est l'occasion idéale d'essayer de nouvelles choses et d'apprendre de vos erreurs. C'est formidable que vous reconnaissiez que votre ancien code a des problèmes, car cela signifie que vous avez appris à faire mieux. L'expérience par essais et erreurs peut être précieuse pour les programmeurs débutants.
Votre projet est relativement petit et vous n'avez pratiquement aucun test. Quelques nuits pourraient être aussi courtes pour écrire 3000 lignes à partir de zéro, d'autant plus que vous avez déjà des idées sur ce qu'il faut faire mieux la prochaine fois.
Travailler dans une base de code cassée sera un drain beaucoup plus lourd sur votre moral qu'une réécriture.
En passant, cela peut être une excellente occasion d'essayer d'écrire un programme plus modulaire avec des tests unitaires. Cela facilite beaucoup la compréhension du code si vous y revenez après une longue pause et aide à prévenir les erreurs que vous pourriez accidentellement introduire en raison de l'oubli.
Enfin, ici est une opinion sur la sagesse de prendre parfois des pas en arrière pour faire de plus grands pas en avant.
Vous êtes probablement encore dans la partie "apprentissage rapide" de votre développement. Il y a de fortes chances que dans quelques mois, vous constatiez que votre nouveau design impressionnant est horriblement cassé d'une manière dont vous ne saviez même pas quand vous avez commencé.
Faites avancer les choses - c'est la chose la plus importante que vous devez apprendre. Croyez-moi, je connais beaucoup de gens (pas seulement des programmeurs) qui sont coincés dans la boucle "recommencer à 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 arrêtiez d'apprendre de nouvelles choses, ce qui n'est pas un endroit agréable :)
Il est également important de pouvoir terminer quoi que ce soit. Tout recommencer est excitant, cool, amusant ... mais si vous apprenez cela, vous ne pourrez jamais rien finir. Encore une fois, ce n'est pas une capacité très utile, et cela ne se sent pas aussi bien que de créer quelque chose d'utile (ou de amusant). La vie est courte, le temps est limité et vous ne pouvez pas continuer à pratiquer sans résultats tangibles - vous en deviendrez fou. Si vous ne pouvez pas commencer à travailler parce que vous ne pouvez tout simplement pas décider de l'approche à adopter, vous êtes déjà dans la zone de danger.
Il y aura toujours des impulsions pour recommencer. Même dans un environnement d'apprentissage, ce sont très probablement une mauvaise idée. Cela ne signifie pas que vous devez transporter chaque prototype dans une application prête pour la production, loin de là. Mais vous devez au moins accéder à une phase de prototype fonctionnelle - cela aidera très probablement votre moral, et c'est un trait très utile pour un développeur de tout genre. Faites avancer les choses. Et la partie amusante est, 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 le "réécrire à partir de zéro" - et dans de nombreux cas, même le 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 "Make it Work, Make it Right, Make it Fast" dans le développement de logiciels.
- Make it Work : Écrivez la fonctionnalité de base, afin que le projet soit utilisable. Faites ce que vous devez faire pour que tout fonctionne, même si cela signifie du code laid.
- Faites les choses correctement : corrigez les bogues et refactorisez le code afin qu'il soit plus facile à lire, à comprendre et à maintenir.
- Faites vite : optimisez le programme en visant un bon équilibre entre la vitesse, l'utilisation des ressources et la maintenabilité.
Pour l'instant, vous n'avez pas terminé l'étape 1. Faites-le d'abord fonctionner, puis vous pouvez vous inquiéter de la laideur de votre code. En fait, la création d'un produit fonctionnel est l'une des choses les plus difficiles à faire pour les nouveaux développeurs, car ils sont tellement occupés à essayer de rendre leur code parfait la première fois, et donc ils se retrouvent coincés dans Optimization Hell et ne parviennent jamais à terminer mettre en œuvre toutes les fonctionnalités. Vous devez apprendre à mettre de côté tous ces soucis de refactorisation et d'optimisation afin de vous concentrer uniquement sur le fonctionnement du logiciel. Une fois que vous aurez plus d'expérience, vous ferez naturellement plus de choses correctement la première fois, donc moins de refactoring est nécessaire.
Gardez à l'esprit: l'optimisation prématurée est la racine de tout mal (voir cette excellente question Programmers.SE pour une bonne discussion). Si vous passez trop de temps à réfléchir à la façon d'améliorer votre code, vous êtes coincé dans paralysie de l'analyse . Cela tue le projet. Il est préférable de simplement terminer le projet avant de commencer à l'optimiser.
Pour citer un excellent orateur de motivation: faites-le .
Comme toujours, il existe un xkcd pertinent:
Réécrivez-le. Le code qui ne fonctionne pas a peu de valeur et trois mille lignes, ce n'est pas beaucoup de code. Cela ne prendra pas autant de temps qu'il a fallu pour écrire le code que vous avez actuellement, et ce sera beaucoup mieux. J'ai souvent jeté cinq cents ou mille lignes de mauvais code, et souvent la réécriture dure un cinquième.
La plupart des notions de "ne pas réécrire" concernent les grands systèmes qui accomplissent des tâches importantes et subissent des changements constants pour répondre à l'évolution des exigences. Les réécritures de systèmes complexes utilisés réussissent rarement.
Votre situation est tout le contraire. 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.
Le redémarrage à partir de zéro est généralement une mauvaise décision 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 nouveau n'est pas au courant (par exemple, voir Choses que vous ne devriez jamais faire , from Joel sur le logiciel blog.)
Néanmoins, les projets scolaires 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 serais ravi de la jeter (voir Quelles sont les différences entre les prototypes jetables et évolutifs? pour une discussion sur jetable contre prototypage évolutif.)
Le bon design a mûri dans votre tête et ne devrait pas prendre beaucoup de temps pour l'écrire dans le 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 du logiciel, il est généralement admis que le temps et l'effort requis pour corriger une erreur augmentent d'un ordre de grandeur pour chaque couche du cycle de vie. Autrement dit, s'il faut 1 heure pour corriger une erreur au niveau des exigences, cela prendra 10 heures en conception, 100 heures en test de codage et 1000 heures en tant que correction de bogue. Ces chiffres peuvent sembler scandaleux, mais ils sont reconnus par l'industrie comme étant approximativement corrects. Évidemment, moins dans un petit projet, mais l'idée générale demeure. Si votre projet présente un défaut de conception de base, il est plus approprié d'appeler cela une expérience d'apprentissage et de revenir en arrière, de revoir vos exigences initiales et de repenser.
J'encourage également à envisager un modèle de développement piloté par les tests utilisant des tests unitaires structurés. Ils sont une douleur et semblent initialement une perte de temps, mais leur capacité à découvrir des erreurs, en particulier lors de l'intégration avec le code de quelqu'un d'autre, ne peut pas être surestimée.
Tu m'as perdu à cette phrase:
Le problème est que je n'ai pas encore terminé la fonctionnalité principale de mon programme, donc je ne peux pas vraiment refactoriser, et je me sens découragé de continuer à être parfaitement conscient que la conception de mon code est défectueuse.
Je crois au principe (énoncé dans Systemantics ) que
- Un système complexe qui fonctionne s'avère invariablement avoir évolué à partir 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:
- Écrivez un peu de code
- Testez-le pour vous assurer qu'il fonctionne
- Écrivez un peu plus de code
- Testez à nouveau
- Etc.
Notez que l'étape 3 peut impliquer:
- Écrivez un peu plus de code
- Refonte du code existant pour le préparer à un nouvel ajout
- Testez le refactoring pour vous assurer qu'il fonctionne toujours
- Ajoutez la nouvelle fonctionnalité
En outre, l'étape 2 "Testez-le pour vous assurer qu'il fonctionne" peut impliquer une réécriture si ce n'est pas le cas.
Si je construisais sur une base de code pourrie, je ne serais pas disposé à ajouter d'autres fonctionnalités. Je serais donc enclin à planifier quelque chose comme "simplifier l'implémentation de threading existante" comme la prochaine œuvre à implémenter. En supposant que vous ayez fait des tests au fur et à mesure, vous devriez pouvoir traiter cela comme un exercice de refactorisation. Les critères de réussite/sortie pour cette phase de travail seraient:
- Le code source est plus simple
- Et aucun nouveau bogue n'a été introduit
- (Et quelques vieux bugs éliminés)
Soit dit en passant, "le tester pour s’assurer qu’il fonctionne" ne signifie pas nécessairement "les tests unitaires" - lorsque la structure de l’équipe est simple, vous pouvez tester un système (simple) en utilisant (simples) tests système (au lieu de l’unité tests) .
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 pendant ses études universitaires alors qu'il recevait des 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 sauvegarde, il a répondu non. Le professeur a ensuite supprimé tout son code et lui a dit de le réécrire.
Il était énervé, mais 3 jours plus tard, il a terminé le programme, avec un code plus propre et moins de bogues et moins de lignes de code.
Essayez de faire une estimation honnête sur quelle option est la meilleure dans le temps disponible pour le projet.
Les 3 choix sont
- Supprimez-le (complètement, sans regarder en arrière)
- Continuez à travailler dans l'ancien design
- Refactorisez le code pendant que vous partez.
Je suis un programmeur professionnel depuis plus de 10 ans, et dans mon travail, je suis arrivé à la conclusion que la dernière option est la plupart du temps celle choisie, mais ce n'est pas toujours la meilleure option.
Refactor. Refactor. Refactor! REFACTOR !!!!
Honnêtement, peu importe votre 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 souhaitez mesurer l'ancien code par rapport aux nouvelles connaissances.
Cela ne fonctionnera tout simplement pas. Si vous faites cela, votre application/jeu ne sera jamais terminé. Au lieu de cela, essayez d'allouer votre temps sur le projet afin que certaines de vos "tâches" consistent à refactoriser le mauvais code. Disons, par exemple, que vous aviez une horrible méthode pour sauvegarder la partie. Continuez à travailler sur le jeu lui-même, mais trouvez du temps pour refactoriser (remplacer) cette horrible méthode. Essayez de garder les refacteurs petits, et cela ne devrait pas être un problème.
Lorsque vous accédez à une partie importante de l'application qui a besoin d'un refactor, vous vous trompez sérieusement. Divisez ce refactoring en pièces plus petites. Essayez de passer sept heures à écrire du code et une heure de refactoring.
Lorsque vous avez terminé avec le projet et que vous appuyez sur le gel des fonctionnalités, vous pouvez passer un temps considérable à refactoriser. Pour l'instant, faites le jeu, mais essayez toujours d'en remanier certains. C'est le mieux que vous puissiez faire.
Il y aura toujours quelque chose à refactoriser.
Il semble que vos compétences aient 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 ciblée serait fructueux.
N'oubliez pas que ce n'est pas quelque chose que vous devez fournir en tant que programme de travail pour un client. Il a été écrit spécifiquement pour la pratique. Donc, à moins que vous ne souhaitiez vous entraîner à avoir des problèmes d'expédition et une livraison défectueuse à la place, je pense que vous êtes actuellement dans une phase de développement où travailler vos "muscles de conception" s'avérerait fructueux.
Ce faisant, concentrez-vous sur le processus de conception et la planification, réfléchissez à vos éléments existants et réfléchissez à ce que vous comprenez mieux.
Je dirais que cela dépend un peu du type de code que vous avez maintenant et de l'endroit exact des problèmes. C'est-à-dire, si vos fondations sont bonnes (conception de classe appropriée dans la plupart des cas, bon découplage/cohésion, etc., juste quelques mauvais choix comme les fils que vous avez mentionnés), alors par tous les moyens, sortez un bare-bones 1.0 puis refactorisez comme il n'y a pas de lendemain.
D'un autre côté, si c'est vraiment juste un tas de fichiers texte hideux giflés passant en quelque sorte le compilateur, sans structure discernable, etc. (en d'autres termes, un prototype d'apprentissage sur le tas de preuve de concept), alors je préfère le supprimer et recommencer.
Sur votre prochaine version, adoptez une approche agile: fixez-vous un calendrier de répétition fixe, comme 2 semaines ou tout ce qui correspond à votre horaire. Au début de chaque morceau (appelons ça un sprint), fixez-vous des objectifs réalisables en 2 semaines. Allez-y et faites-les, essayez de votre mieux pour le faire fonctionner. Fixez-vous des objectifs pour qu'après chaque 2 semaines vous ayez quelque chose qui puisse être montré à un ami, pas seulement un travail interne abstrait. Google "mêlée" et "objectif intelligent". Tout cela est très facile à faire, si vous êtes seul, juste un morceau de papier avec quelques puces rapidement notées.
Si vous pouvez le faire, recommencer est bien. Si vous savez au fond de vous qu'après avoir recommencé, vous vous retrouverez probablement où vous êtes maintenant, de toute façon, alors restez avec votre code et faites-le fonctionner.
Vous devez vous mettre à la place de l'employeur.
Pour la plupart des recruteurs, vous seriez le plus utile si vous procédez comme suit: - Terminez-le avec des tests à 100% sur le nouveau code que vous écrivez. - Ajouter des tests pour l'ancien code (mal conçu). - Refactorisez-le pour obtenir ce que vous vouliez en tant que design.
Faites tout cela avec un bon processus de versionnage, des branches et des balises.
La réécriture est souvent une idée sexy, mais c'est souvent une idée que les nouveaux arrivants ont, ce qui est un peu dangereux dans la vraie vie. 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 au mix. Je travaille sur un projet parallèle depuis plus d'un an maintenant, chaque fois que j'ai quelques minutes de rechange. Ce projet est passé d'un simple banc d'essai à une classe statique à un design mince orienté objet qu'il est actuellement.
Tout au long de toutes ces modifications, j'ai conservé les mêmes fonctionnalités du code, à l'exception des corrections de bogues et des avantages 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, en tant que telle, 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 à un rythme plus rapide que je n'aurais pu le faire auparavant. Cela signifiait également que pendant que j'allais, il était plus facile de dire ce qui devait être supprimé, c'est-à-dire les classes inutiles, et ce qui pouvait rester plus facile que de réécrire avec l'ancienne idée encore dans mon esprit.
Par conséquent, mon conseil serait de refactoriser votre code et de continuer à partir de là en apportant les améliorations nécessaires. Bien que vous vous souveniez 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. C'est à dire. ne vous contentez pas de copier 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, elle a tendance à devenir de plus en plus complexe et de moins en moins organisée. À un moment donné, vous atteindrez un "plafond de complexité", auquel cas les progrès futurs deviendront très difficiles. Plutôt que d'essayer de continuer à avancer par la force brute, il vaut mieux sauvegarder, réorganiser/réécrire, puis 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 la façon la plus simple de nettoyer est de réécrire certaines parties, c'est bien.
La première question que vous devriez vous poser est "quelle est la gravité du défaut?"
Qu'avez-vous fait exactement de mal?
Si quelque chose est si mauvais que vous perdrez des tonnes d'heures à essayer de résoudre le problème, expose des données sensibles (mots de passe/cartes de crédit) ou cause une mauvaise vulnérabilité, alors peut-être devriez-vous le modifier, mais la plupart du temps vous pouvez prenez ce que vous avez, terminez-le et résolvez le problème plus tard.
Les programmeurs adorent améliorer leurs applications, souhaitant 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%, les bugs et tous, alors vous obtenez FEEDBACK des autres, tout en ayant le temps de les corriger les bugs et autres choses pour la version 1.1. D'autres personnes pourront vous aider à améliorer l'application tellement mieux, et vous pourriez avoir perte de temps faire quelque chose que les gens pourraient ne pas aimer.
Donc, dans votre cas, diffusez-le, obtenez des commentaires, puis vous pouvez structurer la version 2.0 avec toutes les modifications 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 qu'il est mauvais, cela signifie que vous vous améliorez toujours, et c'est une bonne chose.
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 réécrire les composants mal écrits. Si les composants mal écrits sont si mal écrits que le code fini ne fonctionnera pas avec eux tels qu'ils sont, alors vous devrez les réécrire avant de pouvoir terminer le reste du code.
Ni? Tous les deux?
Continuez, passez du temps à réviser la conception existante et ajoutez de nouvelles fonctionnalités.
Si vous avez des interactions délicates, cela pourrait être un bon point de départ ("un nombre excessif de threads dans le rendu" sonne comme une inefficacité, plutôt que comme quelque chose qui causerait des problèmes de correction). Voyez si vous pouvez trouver soit un moyen général de vous éloigner des races (et éventuellement des blocages), soit au moins plusieurs façons spécifiques de le faire.
Je ne sais pas dans quelle mesure des éléments comme les détecteurs de blocage et de course sont disponibles pour C #, mais s'ils existent, ils peuvent être utiles pour identifier les problèmes et vérifier que vos correctifs fonctionnent.
Je trouve que, 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 sur le terrain brûlé (par analogie avec les nouveaux sites et les sites contaminés ...) est plus satisfaisant, mais c'est généralement pour des choses où l'approche existante est tellement éloignée de ce qu'elle devrait être qu'elle n'est même plus mauvaise.
Cela dépend de la façon dont votre code est foiré.
Si vous avez fait de vraies erreurs n00b qui rendent votre code trop complexe ou verbeux, alors je recommanderais de réécrire ces parties.
Si vous pensez que vous avez de sérieux bugs que vous devrez de toute façon corriger, 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 corriger les bogues tôt, et il est certainement préférable de corriger les bogues pendant que vous vous souvenez encore de ce que fait 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, alors utilisez simplement l'IDE. (N'oubliez pas, il s'agit de C #, pas de javascript, python, Perl, php, etc.) Lorsque vous travaillez sur du code qui utilise le composant affecté et que vous avez une idée claire de ce que ce composant devrait faire, puis refactorisez-le si votre IDE le rend indolore.
Sinon, faites-le fonctionner et perfectionnez vos compétences sur le prochain projet.
Comme d'autres l'ont suggéré, comme il s'agit d'un projet personnel, pas (encore) professionnel, j'envisagerais sérieusement une réécriture.
Cependant, vous pouvez tirer parti de la méthode scientifique ici, en effectuant une expérience. Concevez d'abord une hypothèse. Le mien serait, "il est probablement temps de réécrire." Afin de gagner du temps, de réduire le coût de l'échec et de limiter quelque peu les biais a priori, avant de poursuivre la programmation, choisissez une durée ("time box"). Je suggérerais peut-être 4 heures d'horloge murale. Décidez également d'une méthodologie pour évaluer l'hypothèse. Étant donné que les enjeux sont faibles, je suggérerais, comme méthodologie, de vous demander simplement: "suis-je content d'avoir fait cela?" Commencez maintenant 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 content 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 de tel que de tester empiriquement une hypothèse.
Quelques raisons d'envisager de sélectionner une réécriture comme expérience:
- D'après mon expérience, c'est généralement plus amusant. Une grande raison pour laquelle les réécritures ne sont souvent pas sélectionnées dans des situations professionnelles est que le plaisir est loin d'être le seul critère. Mais vous êtes encore relativement nouveau dans le codage, donc le plaisir est probablement un critère assez important, et aussi un indicateur d'autres facteurs qui peuvent être intangibles pour vous à ce stade précoce (le plaisir suggère que vous en apprendrez plus, etc.).
- Votre expérience et probablement un sentiment de conscience tenace semblent vous dire qu'une réécriture vaut la peine d'être considéré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 devez 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 composants plus réutilisables et plus fiables que vous pouvez exploiter pour d'autres projets. Vous pouvez même constater qu'en fin de compte, ce qui semblait être un simple module de votre projet principal se révèle être le morceau de code le plus intéressant et le plus précieux que vous écriviez.
Finir quelque chose est une bonne idée, mais pas dans le vide. Si vous commencez une réécriture, vous pouvez choisir de terminer quelque chose en terminant 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 la portée entière de votre projet d'origine, si vous le souhaitez.