Que dois-je faire lorsque j'ai déjà attendu trop longtemps entre les validations?
J'étais méchant ... Trop de "codage de cow-boy", pas assez d'engagement. Maintenant, je suis ici avec un énorme engagement. Oui, j'aurais dû m'engager tout au long, mais il est trop tard maintenant.
Qu'est-ce qui est mieux?
- Faire un très gros commit listant tout ce que j'ai changé
- Essayez de le diviser en commits plus petits qui ne se compileront probablement pas, car les fichiers ont plusieurs correctifs, modifications, noms de méthode supplémentaires, etc.
- Essayez de faire des inversions partielles de fichiers uniquement pour les validations appropriées, puis remettez les nouvelles modifications.
Remarque: en ce moment, je suis le seul programmeur à travailler sur ce projet; la seule personne qui examinera l'un de ces commentaires de validation est moi, au moins jusqu'à ce que nous embauchions plus de programmeurs.
Au fait: J'utilise SVN et Subclipse. J'ai créé une nouvelle branche avant d'effectuer l'une de ces modifications.
Plus d'informations : J'ai posé une question distincte sur la façon dont je me suis retrouvé dans cette situation en premier lieu: Comment se préparer à la réécriture d'une application colle
Pour répondre, vous devez vous demander comment vous comptez utiliser les résultats de ces validations à l'avenir. Les raisons les plus courantes sont:
- Pour voir quelle version un bug a été introduit.
- Pour voir pourquoi une certaine ligne de code est présente.
- Pour fusionner dans une autre branche.
- Pour pouvoir consulter une version précédente afin de résoudre un problème rencontré par un client ou un testeur dans cette version.
- Pour pouvoir inclure ou exclure certaines parties d'une version.
Les deux premières raisons peuvent également être servies avec un grand enregistrement, en supposant que vous pouvez créer un message d'enregistrement qui s'applique également à chaque ligne de code modifié. Si vous êtes le seul programmeur, des commits plus petits ne faciliteront pas votre fusion. Si vous ne prévoyez pas de faire une version ou de tester avec seulement une partie de vos modifications non soumises, les deux dernières raisons ne s'appliquent pas.
Il y a d'autres raisons pour faire de petits commits, mais elles le sont pendant que vous êtes au milieu des changements, et que le temps est passé. Ces raisons facilitent la suppression d'une erreur ou d'un changement expérimental et facilitent la synchronisation avec des collègues sans d'énormes fusions effrayantes.
D'après ma compréhension de votre situation telle que vous l'avez décrite, il semble qu'il n'y ait pas ou peu d'avantages à fractionner votre engagement à ce stade.
Je pense que quoi que vous fassiez, essayez d'éviter de vérifier le code que vous savez ne compilerez pas.
Si vous pensez que votre troisième option est faisable, cela pourrait être une bonne façon de le faire, tant que vous pouvez vous assurer que votre séquence de validations ne créera pas un système incompilable. Sinon, faites le seul gros commit. C'est moche, mais c'est simple, rapide et ça se fait. À l'avenir, engager plus souvent.
La raison la plus importante pour effectuer des commissions fréquentes, petites et significatives est d'aider à la compréhension de l'histoire du code. En particulier, il est très difficile de comprendre comment le code a changé s'il est difficile de générer des différences compréhensibles.
Option 1 obscurcit l'historique des modifications que vous avez apportées, mais sinon cela ne causera aucun problème.
Option 2 obscurcit l'historique des modifications que vous avez apportées, peut-être un peu moins que l'option 1, mais cela pourrait causer d'autres problèmes pour vous-même ou pour les autres s'ils supposent ou concluent autrement que les validations sont distinctes, par ex. peut être fusionné dans d'autres branches indépendamment. À moins qu'il n'y ait une raison pratique solide pour laquelle cela est préféré à l'option 1, c'est moins idéal que cela.
Option est préférable, toutes choses étant égales par ailleurs, mais si, comme vous l'avez décrit ailleurs, cela nécessiterait des délais "extrêmes" ou entraînerait d'autres coûts importants, vous devrez peser ces coûts par rapport aux avantages escomptés de la création d'engagements plus propres.
Sur la base des informations que vous avez fournies, j'opterais pour l'option 1. Peut-être devriez-vous configurer des rappels vous invitant à valider vos modifications?
Prototypage et réécriture
Une autre considération à garder à l'esprit, en particulier à la lumière de votre note sur le fait d'être le seul programmeur et de mon soupçon que vous travaillez sur une base de code relativement nouvelle, est qu'il est probablement bon de développer des habitudes différentes en ce qui concerne la validation des modifications lorsque vous 'prototypage de nouveau code par rapport à la maintenance ou l'extension du code existant. Il n'y a probablement pas de division terriblement nette entre les deux, mais je pense que c'est toujours une distinction utile.
Lorsque vous prototypez du nouveau code, validez chaque fois que vous souhaitez enregistrer vos modifications, presque certainement dans une branche, mais peut-être dans un projet distinct. Ou peut-être même simplement travailler en dehors du contrôle de version. Vous pouvez plutôt vous concentrer sur la collecte de preuves sur la faisabilité des différentes hypothèses ou conceptions que vous envisagez. J'écris souvent de petits prototypes en utilisant différents outils, par ex. LINQPad au lieu de Visual Studio pour le code C #.
Lorsque vous avez validé une hypothèse ou une conception particulière, réécrivez-la dans votre projet principal, idéalement dans une branche, et faites les petits commits significatifs qui aideront le mieux la compréhension des autres (y compris vous-même) de la nature des changements tu fais.
Bien que la seule réponse raisonnable soit ne jamais casser le tronc , parfois ce n'est pas possible. Par exemple, svn peut rompre la validation si vous effectuez trop (peut-être une option ou une fonctionnalité, je ne suis pas sûr). Dans ces cas particuliers, enregistrez-vous simplement en morceaux. Puisque vous êtes un seul programmeur, cela ne dérangera personne.
Par conséquent, je choisirais l'option 1. Si ce n'est pas possible, alors l'option 2.
L'option 3 demande beaucoup d'efforts et n'en vaut tout simplement pas la peine.
Essayez de le diviser en commits plus petits qui ne se compileront probablement pas, car les fichiers ont plusieurs correctifs, modifications, noms de méthode supplémentaires, etc.
Quand je me suis retrouvé dans une situation similaire, j'ai utilisé la technique suivante:
- Ajoutez uniquement le code correspondant à une fonctionnalité particulière:
git add --patch - Stockez toutes les autres modifications:
git stash save --keep-index - Exécuter des tests/essayer de compiler
- Validez les modifications si tout va bien, sinon passez à 1
Je ne connais pas SVN, donc je ne sais pas si cela s'applique à votre situation spécifique, mais la base devrait être la même - isoler de petites parties de code et les tester individuellement.
Que diriez-vous de l'option 4: sauvegarder l'état actuel de votre référentiel dans un emplacement temporaire, rétablir votre référentiel à son état d'origine, faire une liste de toutes les modifications que vous avez apportées (vous pouvez toujours regarder la sauvegarde temporaire), puis réimplémenter manuellement (et compiler et testez-les!) en tant que commits séparés.
Cela devrait être plus facile, car vous avez déjà écrit le code, c'est juste un peu de comprendre quelles parties copier et coller à partir de votre sauvegarde temporaire.
Lorsque vous avez réimplémenté chaque modification proprement et que vous vous êtes ainsi assuré que les validations sont autonomes, petites et compilées, vous pouvez supprimer la sauvegarde temporaire, et tout sera presque exactement comme (sauf l'heure/la date des validations). aurait été si vous l'aviez fait dès le début.
Vous êtes le seul programmeur; il suffit de faire un enregistrement massif unique détaillant les éléments importants de ce que vous avez fait.
Êtes-vous susceptible d'annuler des "parties" de ce que vous avez fait? Sinon, passez absolument à l'option 1.
Il y a plusieurs raisons de vérifier le code dans un système de contrôle de version. Et TOUS, lorsque vous êtes le seul développeur, tournent autour de la sécurité - à savoir, si vous bousillez, la machine meurt ou autre, vous pouvez toujours revenir à ce dernier point de contrôle.
Il est peu probable qu'un programmeur entrant dans le projet plus tard veuille revenir à une version qui ne se compile pas. Donc, à mon humble avis, l'option 2 est la folie.
L'option 3 ressemble à une telle perte de temps, que si j'étais votre patron et que je vous voyais perdre des heures à le faire, j'aurais une petite discussion avec vous sur la valeur de votre temps.
Pour itérer: en archivant votre code vous couvrez/enregistrez vos fesses en cas de panne sur votre machine. Tout le reste, dans une équipe d'un seul homme, est de l'habillage de fenêtre.
Ma règle est: pas d'enregistrement sans un examen sérieux du code. Si je suis seul, je devrai revoir le code moi-même, mais il sera être revu. Vous semblez avoir une quantité de changements de code que quelqu'un d'autre ne peut pas réviser, donc vous ne pouvez pas le réviser vous-même (réviser votre propre code est plus difficile et nécessite plus de discipline, car vous faites automatiquement l'hypothèse erronée que votre propre code est correct ).
La règle totalement incassable de tout le monde est la suivante: ne jamais archiver du code qui ne se construit même pas et éviter sérieusement d'archiver du code qui ne fonctionne pas.
Solution: copiez votre code modifié, revenez au point d'origine. Fusionnez une modification à la fois dans le code d'origine, examinez-le, testez-le, archivez-le. Avec la méthode de programmation que vous avez décrite, vous trouverez inévitablement de sérieux bogues.
C'est aussi un bon moyen de vous former de bonnes habitudes de programmation.
Je pense que vous vous inquiétez beaucoup trop. Si vous êtes le seul programmeur et que vous n'avez pas de fiche technique sur laquelle travailler, c'est à vous de décider ce que vous faites. Je suppose que personne ne vous punira pour avoir effectué un gros commit, donc les seuls problèmes que vous rencontrerez sont d'ordre technologique, comme le fait de ne pas pouvoir annuler les modifications de fichiers individuels dans le commit. Puisque vous contrôlez uniquement le repo en ce moment, cela ne devrait pas non plus être une énorme préoccupation.
Il y a une ligne à tracer entre le pragmatisme et le dogmatisme. Ce que vous avez fait ne serait pas une bonne idée dans une équipe et ne devrait probablement pas être répété à l'avenir, mais dans votre situation, je soumettrais simplement le gros commit.