Est-ce que la validation / l'archivage quotidien du code est une bonne pratique?
J'ai lu la note de Martin Fowler sur Intégration continue et il répertorie comme incontournable "Tout le monde s'engage chaque jour sur le réseau principal".
Je n'aime pas valider le code sauf si la section sur laquelle je travaille est terminée et qu'en pratique je valide mon code tous les trois jours: un jour pour enquêter/reproduire la tâche et faire quelques changements préliminaires, un deuxième jour pour terminer les changements et un troisième jour pour rédiger les tests et les nettoyer ^ pour soumission. Je ne me sentirais pas à l'aise de soumettre le code plus tôt.
Maintenant, je récupère les modifications du référentiel et les intègre localement, généralement deux fois par jour, mais je ne m'engage pas souvent, sauf si je peux me tailler une petite tâche.
Question: commet quotidiennement une telle bonne pratique que je devrais changer mon flux de travail pour l'adapter, ou ce n'est pas conseillé?
Edit: Je suppose que j'aurais dû préciser que je voulais dire "commit" dans le sens CVS de celui-ci (aka " Poussez ") car c'est probablement ce que Fowler aurait voulu dire en 2006 quand il a écrit ceci.
^ L'ordre est plus arbitraire et dépend de la tâche, mon but était d'illustrer la durée et les activités, pas la séquence exacte.
Je ne suis pas d'accord avec cette règle et je suis d'accord avec ce que Mason Wheeler a dit. Je voudrais ajouter quelques idées.
J'essaie de valider chaque fois que j'ai un changement significatif à valider: cela peut être plusieurs fois par jour si je corrige plusieurs petits bugs, ou une fois par semaine si je travaille sur un logiciel plus grand qui ne peut pas être utilisé par le reste de le code de manière significative jusqu'à ce qu'il atteigne un état cohérent.
Aussi, j'interprète committing comme publiant une révision significative qui apporte de nouvelles fonctionnalités à la base de code. Je pense que l'on devrait essayer de nettoyer le code avant de s'engager afin que les autres développeurs puissent comprendre la signification et le but du changement quand ils regardent l'historique de révision. Moins les autres développeurs voient de changements dans l'historique, mieux c'est: quand je regarde l'historique des révisions, je veux voir des incréments qui ajoutent des fonctionnalités significatives; Je ne suis pas intéressé par chaque petite idée que chaque développeur avait et voulait essayer avant d'arriver à la solution.
De plus, je ne pense pas que ce soit une bonne idée d'utiliser le serveur SVN (ou n'importe quel système de contrôle de version) comme une installation de sauvegarde dans laquelle l'instantané actuel du code est validé (à condition qu'il compile): vous pouvez utiliser une clé USB ou un lecteur USB externe ou un disque réseau pour refléter votre code actuel afin qu'il ne se perde pas si votre ordinateur tombe en panne. Le contrôle des révisions et la sauvegarde des données sont deux choses différentes. La publication d'une révision n'est pas la même chose que l'enregistrement d'un instantané de votre code .
Enfin, je pense que cela ne devrait pas être un problème de s'engager de temps en temps (c'est-à-dire uniquement lorsque l'on est vraiment satisfait de l'état actuel du code) et éviter les conflits de fusion n'est pas une bonne justification pour s'engager (trop) souvent. De nombreux conflits de fusion se produisent lorsque différentes personnes travaillent sur les mêmes fichiers en même temps, ce qui est une mauvaise pratique (voir par exemple cet article , point 7). Les conflits de fusion doivent être réduits en divisant un projet en modules avec des interfaces claires et aussi peu de dépendances que possible, et en coordonnant le travail des développeurs afin que le code sur lequel ils travaillent chevauche le moins possible.
Juste mes 2 cents.
[~ # ~] modifier [~ # ~]
Une autre raison contre les commits prématurés qui m'est venue à l'esprit est qu'une version (très) buggée ne peut pas être testée. Si vous vous engagez sur le coffre et que votre équipe de test teste tous les jours, il se peut qu’ils n’aient pas de version testable pendant quelques heures (ou pendant une journée). Même si vous n'essayez pas de corriger le bogue et de simplement annuler vos modifications, une reconstruction peut prendre quelques heures. Avec, disons, cinq testeurs travaillant dans votre équipe, vous avez perdu 5 x 2 = 10 heures de temps en raison de l'inactivité. Cela m'est arrivé une fois, donc j'essaie vraiment d'éviter les commits prématurés au nom de commit dès que possible.
Je valide le code plusieurs fois par jour. Chaque fois que j'atteins un point où le code est suffisamment complet pour être compilé et ne rompt rien d'autre, il entre.
Vous devriez envisager de diviser votre travail afin de pouvez vous enregistrer en toute sécurité plusieurs fois par jour.
Les raisons à cela sont deux:
- Tout travail non enregistré peut être perdu - votre ordinateur peut avoir une défaillance catastrophique. Dans ce cas, plus vous attendez, plus vous perdez de travail.
- Plus vous faites de travail sans vous enregistrer, plus les autres devront intégrer de code lorsque vous déciderez finalement qu'il cuit. Cela introduit plus de risques de conflits et de problèmes de fusion.
Adhérer servilement à toute méthodologie ou pratique sans en comprendre les raisons n'est jamais une bonne idée. C'est de là que vient la programmation culte.
Par conséquent, "je devrais m'engager chaque jour parce que Martin Fowler l'a dit" est tout simplement stupide. Et parfois, c'est aussi impossible. Si vous travaillez sur une nouvelle fonctionnalité compliquée, vous n'atteindrez peut-être pas le point de s'enregistrer avant d'avoir déjà travaillé dessus pendant quelques jours.
Cela ne signifie pas que vous devez vous assurer que tout est parfait avant de le vérifier. C'est un bon moyen de perdre du travail en cas de problème. La bonne chose à faire est de développer et d'utiliser un bon jugement sur la question. Les règles de base ne peuvent que vous aider beaucoup.
Oded a donné deux raisons importantes pour valider le code aussi souvent que possible. J'en ajouterai quelques autres:
Tout en travaillant sur votre morceau de code, d'autres pourraient avoir besoin de certaines fonctions sur ce code. Ils ne devraient pas attendre 6 jours pour l'obtenir. Dans ce cas, mes collègues créent généralement un prototype dans mon morceau de code, le valident, j'ajoute le corps et le valide à nouveau. Et cela se fait généralement en quelques heures.
Le code "commun" permet à chacun de voir chaque changement le plus tôt possible. Si le morceau de code sur lequel vous travaillez est totalement distinct du travail des autres et que vous ne les attendez pas, il est recommandé de créer une branche sur laquelle vous pouvez travailler, puis, si tout réussit, fusionnez-la avec la ligne principale.
Je crois fermement à la réalisation de tous les changements logiques qui méritent d'être conservés. Engagez-vous souvent et si le code ne vaut pas la peine d'être conservé, remettez-le dans un état propre. Plus vous attendez pour repousser/publier votre code, plus il est difficile à implémenter et plus vous rencontrerez de problèmes. Vous obtiendrez également des commentaires sur vos contributions beaucoup plus rapidement:
- cassent-ils la construction?
- dupliquez-vous les efforts d'un autre membre de l'équipe?
- faites-vous quelque chose de mal?
- ou les gens attendent-ils de vous?
Les petits changements sont beaucoup plus faciles à gérer.
Il convient également de noter la différence entre les différents systèmes de contrôle de version. Certains, comme Git (distribué), vous permettront de valider et de contrôler tout votre historique localement, en ne poussant que lorsque vous serez prêt à publier. D'autres, comme SVN (centralisé), combineront les deux étapes, rendant les petits commits très inefficaces.
N'oubliez pas que vos validations sont essentiellement des modifications de documentation. Lorsque les choses tournent mal, vous serez heureux d'avoir plus d'histoire que pas assez. Un seul engagement pour une semaine de travail me semble inutile. Je finirais par lire chaque ligne de code modifiée plutôt que le résumé de chaque bloc logique.
Je pense que la plupart des réponses ici manquent l'un des principaux points de la déclaration de Martin Fowlers. Ceci est lié à intégration continue. Le code qui n'est pas archivé (poussé/publié/fusionné) dans la ligne principale n'est pas testé.
Cela ne doit pas être lu comme un encouragement à valider le code que vous avez sur votre machine locale chaque fois qu'il est temps de quitter le bureau. Comme l'ont souligné plusieurs autres ici, ce serait mauvais, cela casserait la construction et causerait une ligne principale instable.
Cependant, il est encourageant d'essayer d'apporter vos modifications par petites étapes qui peuvent être archivées sur la ligne principale sans causer de problèmes. Cela encourage l'évolution du code au lieu de tout déchirer et de réécrire.
Maintenant, qu'est-ce qui est bon dans cette façon de travailler?
- Ne pas commettre de gros morceaux de code ou des changements révolutionnaires réduit les chances de casser la construction.
- Si votre commit rompt la construction, il est assez trivial d'identifier les problèmes, de le rétablir et de valider rapidement une version fixe.
- En vous assurant que tous les tests s'exécutent à chaque petite modification du code, vous vous assurez de ne pas introduire de bogues ou de régressions subtils pouvant résulter de la croissance du code en dehors du schéma d'intégration continue.
Bien entendu, tous les changements ne se prêtent pas à cette approche. Comme d'autres l'ont souligné, aucune règle n'est absolue. Cependant, pour les changements qui devraient rester en dehors de la ligne principale pendant longtemps, configurez une ligne principale alternative avec son propre schéma d'intégration continue et suivez la même approche. Avec les VCS distribués d'aujourd'hui, c'est une chose assez facile à faire.
Arguments pour l'enregistrement chaque jour:
- Le code est stocké et sauvegardé contre les pannes de disque dur
- L'activité peut être enregistrée dans des notes de validation (qu'est-ce que j'ai fait jeudi ...?)
- L'intégration avec la base de code existante se produit plus tôt et en petits morceaux, en espérant identifier les conflits ou fusionner les problèmes plus tôt
- Votre équipe a une visibilité de ce sur quoi vous avez travaillé
- Vos collègues peuvent travailler contre vos interfaces plus tôt, ce qui leur donne plus de temps pour s'intégrer à votre "gros morceau de code complexe"
- Votre code sera testé dans le monde réel plus tôt, ou du moins exposé à une utilisation plus importante que celle que vous lui accorderez, ce qui permettra d'identifier plus tôt les bogues ou les omissions.
Arguments contre l'enregistrement chaque jour:
- Je n'ai pas besoin ou je ne veux pas
- Je n'ai pas encore `` nettoyé '' mon code, c'est un gâchis
- Je n'ai pas le temps
Je ne pense pas qu'il y ait de bonnes raisons de s'enregistrer moins que quotidiennement, à part la paresse ou la désorganisation. Rien de pire que de voir le code s'exécuter dans l'environnement de développement ne correspond pas au code dans la branche de développement parce que quelqu'un `` n'a pas encore fini '' et n'a donc pas vérifié.
J'adorerais me tromper sur ce point, alors faites-moi savoir tout argument légitime contre l'enregistrement quotidien.
Si vous entendez "valider" comme "fusionner dans la ligne principale", vous ne devriez certainement pas le faire tous les jours sur un projet logiciel qui est mis à la disposition des clients. Vous devez fusionner les modifications effectuées et testées, de sorte que la ligne principale fonctionne toujours et soit libérable, et non dans un état cassé avec des fonctionnalités semi-terminées.
Cependant, le luxe de travailler avec le contrôle de version distribué d'aujourd'hui est que vous pouvez à la fois maintenir la ligne principale stable et en même temps git/hg/whatever commit chaque fois que vous sentez que vous voulez préserver l'état des choses. Je le fais une fois toutes les quelques heures et définitivement à la fin de chaque journée.
Avec DVCS, vous pouvez publier votre travail, y collaborer avec d'autres membres de votre équipe et le tenir à jour avec les changements dans la branche principale. Vous pouvez faire tout cela sans polluer la stabilité du code dont dépendent vos clients et/ou d'autres équipes.
À une époque où Subversion était la dernière technologie et qu'il n'y avait aucun moyen de bifurquer et de fusionner des branches de fonctionnalités sans douleur extrême, avoir une ligne principale où plusieurs fonctionnalités différentes étaient en construction simultanée aurait pu être la meilleure approche. Mais cette supériorité ne s'étend pas au-delà de 2010.
Dans Team Foundation Server, vous pouvez "Shelve", ce qui n'est pas la même chose qu'un enregistrement, mais fait juste une sauvegarde de votre code afin que si votre machine meurt, vous n'avez pas perdu les modifications.
J'ai également vu des éditeurs de logiciels qui ont une "ligne de développeur" et une "ligne principale". Les développeurs sont libres de se connecter à la ligne de développeur chaque fois qu'ils le jugent approprié et seul le chef d'équipe a accès à la ligne principale, ils sont donc responsables de la copie du code du développeur vers le principal lorsqu'il est prêt pour la production.