Comment refactoriser une branche sans perdre la tête?

Question

Je refacture mon code et celui des autres tout le temps . Lorsque je travaille dans une branche et non dans Trunk, cela entraîne parfois des fusions extrêmement pénibles, en particulier si je ne fusionne pas régulièrement dans Trunk (le code de la branche s'éloigne lentement du Trunc et lorsque des personnes modifient Trunk I comprendre manuellement comment appliquer cela à la branche).

Les solutions que je connais sont soit

1. Fusionner constamment vers et à partir de Trunk - réduit les fusions douloureuses, mais pourquoi alors travailler dans une branche?
2. Chaque fois que vous avez besoin de refactoriser quelque chose, basculez vers Trunk, effectuez le refactoring là-bas et fusionnez avec votre branche. Je ne trouve pas cela très pratique, car le coût réel de la commutation des environnements pour chaque refactoring est énorme.

Que faites-vous?

Answer 1

La refactorisation à grande échelle doit être effectuée au bon moment dans la chronologie du développement. Si vous effectuez d'énormes quantités de refactoring au moment de la publication, vous finirez par vous blesser, car vous introduirez des fusions douloureuses à un moment où les changements doivent être minimisés. Plus la refactorisation sera perturbante, plus le cycle de développement devrait avoir lieu tôt (et plus le processus sera spécial, par exemple, arrêter les modifications apportées aux fichiers concernés autant que possible pendant un certain temps).

La fusion constante vers et depuis le tronc est généralement une bonne pratique.

Pourquoi travailler dans une branche du tout dans ce cas? Parce que vous avez plus de contrôle (vous pouvez cesser de fusionner dans trunk pour le stabiliser avant la publication, par exemple, sans arrêter les archivages vers votre branche de développement). Parce que vous pouvez placer un niveau élevé de validation autour de la fusion vers / à partir du tronc sans impacter beaucoup la vitesse d’enregistrement dans la branche de développement.

Answer 2

Je pars avec 1, fais de petits changements lorsque cela est possible et enregistre souvent, sinon les fusions deviennent douloureuses. Avoir une branche distincte peut faciliter les choses si vous devez travailler sur d'autres choses en même temps ou si la refactorisation prend plus de temps que prévu. L’autre avantage est qu’il est plus facile pour plusieurs personnes de prendre part à la refactorisation et que vous pouvez enregistrer les choses dans la branche aussi souvent que vous le souhaitez.

Answer 3

Je suggérerais la stratégie suivante pour les scénarios dans lesquels la fenêtre temporelle entre les versions est d'au moins 2 mois.

Lorsque vous approchez d'une version, créez une branche de version. La branche de publication doit être traitée comme pas de refactoring ici s'il vous plaît et je suis (presque) avec la branche complète . C’est à ce stade que vous devriez commencer à concentrer vos efforts sur la stabilisation de la version sur la branche de version . Fusionner si nécessaire les correctifs de la branche de publication sur le coffre. Pendant ce temps, le coffre est traité comme ouvert pour le refactoring . Aussi, si possible, essayez de réduire la refactorisation à mesure que vous vous rapprochez d'une version majeure et accélérez-la dans les jours qui suivent.

Si vous suivez une stratégie de libération continue (c.-à-d. une publication toutes les 1 à 2 semaines), vous ne devez pas séparer la refactorisation et le codage sur des branches distinctes, sauf si vous effectuez une amélioration chirurgicale majeure. Dans de telles situations d’amélioration chirurgicale (qui doivent être espacées de pas moins de 3 mois), supprimez une sortie de votre programme à l’avance lorsque vous avez l’intention de procéder à une fusion, utilisez l’un des cycles pour la fusion de la libération et un test accru, croise les doigts puis relâche.

Answer 4

Les modifications doivent être rapides (afin de ne pas trop changer sous vous) ou locales (pour que vous ne teniez compte que des modifications apportées dans un petit nombre de lieux).

Sinon, la fusion peut représenter autant de travail que le refactor. En tant qu'algorithme, le verrouillage optimiste ne fonctionne tout simplement pas lorsque trop de transactions échouent et doivent être redémarrées.

Fondamentalement, vous ne pouvez pas autoriser une situation dans laquelle 20 programmeurs d’une entreprise changent tous les jours le nom de 50% des méthodes de la base de code. Et d’ailleurs, si plusieurs personnes refactorisent toujours au même endroit au même moment, elles annulent de toute façon le travail de l’autre.

Si les programmeurs passent beaucoup de temps à superviser manuellement les fusions, offrez à vos responsables l’occasion d’accroître la productivité en modifiant la manière dont les tâches sont définies et attribuées.

De même, "refactorisez l'ensemble du système pour utiliser les usines partout". n'est pas une tâche. "Refactoriser cette interface et ses implémentations pour utiliser des usines" est une tâche.

Answer 5

C’est là qu’un bon VCS distribué excelle. Mais je suppose que vous vous engagez déjà pour SVN.

Personnellement, je fais juste le refactor, puis je fusionne dès que possible pour éviter l’enfer du conflit. Ce n'est pas la méthode la plus productive, mais la moins sujette aux erreurs.

Une fois, j'ai eu une branche qui était restée en veille pendant environ 3 semaines parce que la fonction avait été mise en attente et qu'il était impossible de la fusionner. Je viens de recommencer la fonctionnalité dans une nouvelle branche, en utilisant l’ancienne comme référence pour certaines pièces.

Answer 6

Au risque d’être évident, je dirais qu’il faut éviter de créer des ramifications. La quantité de frais généraux que cela cause ne doit pas être sous-estimée. Même lorsque vous pensez que vous ne pouvez plus vous en tenir (version 1 du système en production, version 2 en cours de création mais également modification des demandes en version 1), essayez de trouver un autre moyen: n'y a-t-il vraiment aucun moyen d'isoler les fonctionnalités sans créer de branche (par exemple, scission d’un projet "commun" et de certains sous-projets)? N'y a-t-il vraiment aucun moyen d'intégrer tout le code sur la tête (par exemple, créer des classes de stratégie intégrant les différences ou créer des commutateurs pour activer ou désactiver les nouvelles fonctionnalités)?

Si vous devez absolument créer une branche, j'opterais pour l'option 1. Essayez de fusionner le moins possible et faites-le fréquemment.

Answer 7

Commencez tôt, commettez souvent.

Ou dans ce cas ... Fusionnez tôt, fusionnez souvent.

Answer 8

L’intégration continue est la clé ... 1 petit lot de modifications à la fois ...