Comment refactoriser une base de code alors que d'autres s'y engagent rapidement?

Je suis sur un projet privé qui finira par devenir open source. Nous avons quelques membres de l'équipe, suffisamment talentueux avec les technologies pour créer des applications, mais pas des développeurs dédiés qui peuvent écrire du code propre / beau et surtout à long terme.

J'ai décidé de refactoriser la base de code, mais c'est un peu compliqué car quelqu'un de l'équipe dans un autre pays avec lequel je ne suis pas en contact régulier pourrait mettre à jour cette chose totalement distincte.

Je sais qu'une solution consiste à communiquer rapidement ou à adopter de meilleures pratiques de gestion des particules, mais nous ne sommes tout simplement pas encore si gros. Je veux juste nettoyer le code et bien fusionner avec ce qu'il a mis à jour. L'utilisation d'une succursale serait-elle un plan approprié? Une fusion au mieux? Autre chose?

Une chose que les gens oublient souvent est qu'une architecture propre accélère non seulement la maintenance à long terme, mais accélère également le développement en ce moment . N'essayez pas d'isoler vos changements de vos collègues jusqu'à ce qu'ils soient «terminés». Vos modifications les aideront à être plus productifs et moins sujets aux bugs.

L'erreur la plus fréquente que les gens commettent lorsqu'ils entreprennent un gros remaniement est de ne pas fusionner assez souvent, plutôt d'essayer de le faire en une seule fois. La bonne façon de le faire est de créer le plus petit remaniement possible, de le tester, puis de le fusionner dans la branche de votre collègue et de lui expliquer le changement afin qu'il puisse l'incorporer à l'avenir. Idéalement, vous effectuez une fusion par jour, ou au moins une par semaine.

Vous n'êtes jamais "pas assez grand pour communiquer". Si vos doigts peuvent faire la frappe, vos lèvres peuvent aussi parler. À la fin de la journée, l'amélioration de la technologie est de 85% de communication et 15% de technique. Ce n'est pas parce que vous préférez rester assis à coder que d'avoir des conversations difficiles avec quelqu'un ... que c'est une bonne idée. La communication est en fait la partie difficile de ce que vous essayez de faire, mais ne l'évitez pas.

Oui, une succursale est une bonne solution pour cela.

Je vous suggère de commencer à travailler sur cela sur une branche et de vous assurer qu'il s'applique proprement au-dessus de votre courant HEADentre-temps (c.-à-d. Faire des rebases de test et des fusions à intervalles réguliers pour vous assurer que vous pouvez appliquer facilement vos modifications et que vos tests réussissent toujours - - cherchezgit rerere également de l'aide gità ce sujet). Ensuite, une fois que vous avez terminé, rebasez et fusionnez vos modifications dans votre HEAD.

Le plus tôt vous commencez à travailler dessus, mieux c'est, car changer d'architecture devient de plus en plus de travail, plus le code est froid. En outre, il pourrait y avoir de nombreuses instances de code codé à la main dispersées dans la base de code où, par exemple, votre nouvelle fonction d'assistance Shiner aurait pu rendre les choses beaucoup plus simples.

Avez-vous envisagé l'option "Ne le faites pas encore"?

Bien que faire ce travail dans une branche distincte soit probablement la meilleure approche, vous vous préparez à une fusion douloureuse massive sur toute la ligne.

Les autres gars ajoutent probablement beaucoup de nouvelles fonctionnalités, changent les fonctionnalités existantes et éventuellement suppriment certaines fonctionnalités.

Une fois que le développement traditionnel a ralenti un peu à un moment donné dans le futur, alors vous pourriez être dans une position beaucoup plus facile à refactoriser.

tl; dr - On dirait qu'il est temps de passer aux ligues majeures. Mettre du rouge à lèvres sur un cochon ne le rend pas plus joli, sauf si vous êtes dans ce genre de chose ...

Le problème des personnes

Le premier problème est la synchronisation de validation. SI plusieurs personnes travaillent sur le même code en même temps, vous n'avez besoin que d'une seule règle pour éviter les problèmes:

Rule 1: Always pull before you merge/rebase

En ce qui concerne DVCS, il est difficile d'apporter des modifications à une branche distante (c'est-à-dire le référentiel principal) et très facile d'apporter des modifications au local. Chaque personne est responsable de faire en sorte que ses propres ajouts de code s'intègrent dans le grand ensemble sans problèmes. À moins que 2 personnes ne s'engagent en même temps, vous ne devriez pas en faire l'expérience. L'accès de validation au maître d'origine / distant doit être limité à quelques développeurs et ils doivent extraire les modifications des autres développeurs via des branches de suivi à distance.

Le problème du code

Comment savez-vous que les modifications que vous apportez ne cassent pas le code?

Réponse simple ... Écrivez des tests pour prouver qu'ils ne le font pas. Si vous ignorez l'école de pensée TDD (Test Driven Design), tout l'intérêt des tests est d'ajouter un niveau de vérification qui vous permet de changer le code sans le casser.

Rule 2: Don't make assumptions, write proofs (ie tests).

En plus de cela, la gamme complète de tests doit être exécutée avant de passer au maître d'origine / distant.

Gardez vos commits aussi petits et concis que possible. De cette façon, si vous devez annuler une modification qui a cassé quelque chose plus tard, vous économiserez d'avoir à réimplémenter les parties qui n'ont pas cassé le code.

Vous devrez peut-être d'abord une restructuration organisationnelle

Si les solutions ci-dessus ne peuvent pas être facilement appliquées, il y a probablement quelques problèmes avec la structure de développement qui doivent être résolus en premier.

Le propriétaire du projet doit être le portier. S'il y a des problèmes de synchronisation de validation, il y a probablement trop de personnes avec un accès de validation. Même sur des projets massifs comme le noyau Linux, seule une poignée de développeurs ont validé l'accès au référentiel maître d'origine / distant. Il existe en fait plusieurs niveaux de référentiels pour gérer les validations. Au lieu d'un modèle de validation à une seule couche où tout le monde applique ses modifications à l'origine, le modèle hiérarchique a des contrôleurs qui récupèrent les modifications et vérifient leur qualité avant de les inclure dans le projet. Le modèle de validation hiérarchique peut évoluer beaucoup plus grand et plus efficace que le modèle à couche unique sans sacrifier la qualité.

Pour les développeurs qui ne reçoivent pas un accès en , ils devraient apprendre à créer leurs propres branches de suivi à distance (git et gitorious sont bons pour cela) de sorte que les développeurs qui font ont un accès en peut facilement tirer / intégrer des branches dans l'origine. Si les modifications sont minimes, les correctifs fonctionneront tout aussi bien.

La possibilité d'extraire des modifications avant d'effectuer une fusion / rebase suppose que vous ne développez pas sur votre branche principale locale. Le moyen le plus simple est de faire une traction initiale avant de commencer à coder, puis de faire tout votre travail sur cette branche. Le plus difficile est de le ramifier juste avant la fusion et de restaurer le master.

Définissez le style de codage du projet dans son ensemble et faites en sorte que les développeurs le suivent. Les développeurs contributeurs doivent écrire du code conforme aux standards / normes du projet pour minimiser le nettoyage. Le style de codage peut être une grande barrière d'ego dans un projet ouvert. Si aucune norme n'est définie, tout le monde codera dans son propre style préféré et la base de code deviendra très moche très rapidement.

Le mythe du "Mois de l'homme mythique"

Croyez-le ou non, les projets open source plus importants / plus réussis ne sont pas gérés comme une démocratie. Ils sont gérés comme une hiérarchie. Déclarer qu'un projet ne peut pas se développer efficacement au-delà de 8 à 10 développeurs est naïf. Si c'était vrai, alors les mégaprojets comme le noyau Linux n'existeraient pas. Le problème le plus profond est que donner à tout le monde un accès de validation rend la communication efficace trop difficile à gérer.

Le problème du mois mythique de l'homme peut en fait être surmonté. Vous avez juste besoin de gérer votre projet comme les militaires. Il existe de nombreux niveaux dans la hiérarchie, car il est de notoriété publique que les individus ne sont vraiment efficaces que pour gérer les communications avec une poignée de personnes. Tant qu'aucun individu n'est responsable de la gestion du travail de plus de 5 à 7 personnes, le système peut évoluer indéfiniment.

Cela peut limiter les développeurs les plus expérimentés à faire plus d'intégration et de conception / planification de niveau supérieur, mais ce n'est pas une mauvaise chose. Une partie de l'intensification consiste à prendre la décision de décider que le projet a besoin d'un plan à long terme. Les personnes aux niveaux les plus élevés qui investissent le plus (le temps est aussi une ressource) dans l'avenir des projets devraient être chargées de prendre les grandes décisions.

C'est agréable d'entendre parler d'un projet open source qui connaît des difficultés croissantes. Félicitations et bonne chance.

code propre / beau et surtout maintenable à long terme.

D'après mon expérience, clean / beautiful est l'ennemi du maintenable. Beau code souvent:

• A une couche sur le cadre qui introduit un niveau d'abstraction plus élevé
• Optimise la réutilisation du code, entraînant de nombreuses dépendances
• Tente de résoudre le problème générique au lieu du problème spécifique

D'autre part, le code maintenable:

• Est écrit directement sur le framework, donc tous les développeurs peuvent le lire
• Optimise pour un faible nombre de dépendances, donc un changement dans un domaine n'a pas d'impact sur un autre
• N'essaie pas de résoudre plus de problèmes que nécessaire