Est-il toujours possible de commettre un code qui ne fonctionne pas?

Est-ce une bonne idée d'exiger de n'engager que du code fonctionnel?

Ce commit n'a pas besoin de laisser le référentiel dans un état de fonctionnement tel que:

• ... nous en sommes aux premières étapes de la conception, le code n'est pas encore stable.
• ... vous êtes le seul développeur du projet. Vous savez pourquoi les choses ne fonctionnent pas. De plus, vous n'arrêtez le travail de personne en commettant un code erroné.
• ... le code ne fonctionne pas actuellement. Nous allons faire un grand changement à cela. Engageons-nous afin d'avoir un point sur lequel revenir si les choses se gâtent.

• ... la chaîne est longue, pas de problème si du code erroné existe dans la branche locale. C'est à dire

  1. fichiers locaux
  2. zone de transit
  3. commets dans la branche locale
  4. commet dans la branche de fonctionnalité personnelle distante
  5. fusionner avec une developbranche distante
  6. fusionner avec une masterbranche distante
  7. fusionner avec une releasebranche distante

• ... commets tôt, commets souvent.

Ainsi, dans la question ci-dessus liée, la majorité des réponses indiquent qu'engager du code non compilable ne pose aucun problème dans les branches locales et les entités. Pourquoi? Quelle est la valeur d'un commit bloqué?

Ajouté: Il y a quelques commentaires très votés, disant que sur une branche locale, on peut faire ce que l'on veut. Cependant, l'aspect technique de la question ne m'intéresse pas. J'aimerais plutôt apprendre les meilleures pratiques - les habitudes que les personnes qui ont travaillé de nombreuses années dans l'industrie ont été les plus productives.

Je suis émerveillé par la quantité de bonnes réponses! Ils me conduisent à la conclusion que je ne suis pas assez habile à utiliser des branches pour organiser mon code.

Une des philosophies de branchement (section Développer une stratégie de branchement et une politique de ligne de code dans Stratégies de branchement avancées de SCM - lisez également Perforce Best practices , c’est un pdf mais va dans d’autres détails) est que vous branchez sur une politique incompatable.

Une stratégie de ligne de code spécifie les vérifications d'utilisation équitable et autorisée pour la ligne de code et constitue le manuel de l'utilisateur essentiel pour le SCM de ligne de code. Par exemple, la politique d'une ligne de code de développement devrait stipuler que ce n'est pas pour la publication; De la même manière, la politique d'une version de codeline devrait limiter les modifications aux corrections de bogues approuvées. La stratégie peut également décrire comment documenter les modifications archivées, quelle révision est nécessaire, quels tests sont nécessaires et les attentes en matière de stabilité de la ligne de code après les archivages. Une stratégie est un composant essentiel pour un processus de développement logiciel documenté et exécutable, et une ligne de code sans stratégie, d'un point de vue SCM, est hors de contrôle.

(d'après Perforce Best Practices)

Supposons que vous avez la «version» (ou le «maître») des branches à partir de laquelle une version est construite et le «trunk» (ou «dev») où les développeurs archivent le code de travail. Ce sont les politiques des branches. En notant que le "code de travail" fait partie de la politique de la branche "dev", il ne faut jamais commettre de code cassé dans la branche dev. Il arrive souvent que des serveurs CI soient connectés à ces branches et que l'enregistrement de code erroné dans dev puisse gâcher la branche de tout le monde et casser la construction.

Cependant, il est parfois approprié d’archiver du code partiel qui ne fonctionne pas. Dans ces cas, il convient de créer une branche - une stratégie incompatible avec le tronc. Dans cette nouvelle branche, on peut décider de la politique à suivre ("le code erroné est correct"), puis le valider.

Il existe une règle simple pour déterminer si une ligne de code doit être branchée: elle doit l'être lorsque ses utilisateurs ont besoin de stratégies d'enregistrement différentes. Par exemple, un groupe de version de produit peut avoir besoin d'une stratégie d'enregistrement appliquant des tests rigoureux, tandis qu'une équipe de développement peut avoir besoin d'une stratégie autorisant des vérifications fréquentes de modifications partiellement testées. Cette divergence de politique appelle une branche de code. Lorsqu'un groupe de développement ne souhaite pas en voir un autre

(d'après Perforce Best Practices)

Sachez que cela vient d'un GDS basé sur un serveur central et doté d'un esprit d'entreprise fort. L'idée de base est toujours bonne. Celles-ci sont souvent considérées de manière implicite - vous ne archivez pas de code dev non testé dans la branche release. C'est une politique.

Alors branche, disons que cette branche peut avoir du code erroné et s’engager.

Une des philosophies suggérées par Linus Torvalds est que la programmation créative devrait être comme une série d’expériences. Vous avez une idée et suivez-la. Cela ne fonctionne pas toujours, mais au moins vous l'avez essayé. Vous souhaitez encourager les développeurs à expérimenter des idées créatives. Pour ce faire, il doit être peu coûteux d'essayer cette expérience et bon marché pour le récupérer. C'est le vrai pouvoir de git qui est si bon marché (rapide et facile). Cela ouvre ce paradigme créatif qui permet aux développeurs d'essayer des solutions qu'ils n'auraient peut-être pas autrement. C'est la libération de git.

Oui, tant que ce n'est pas une branche de publication.

Dans les branches personnelles, tout va et peut ensuite être jeté si l'expérience n'a pas fonctionné. C’est l’un des principaux avantages du DVCS: la liberté

La valeur de commettre un code erroné ?: collaboration et expérimentation

Oui, c’est bien et c’est quelque chose que je fais souvent.

L’intérêt de commettre du code non compilable (au moins dans les branches) est que parfois votre code est un travail en cours, mais que le travail effectué jusqu’à présent vaut la peine d’être sauvegardé et / ou partagé avec d’autres.

Mes pratiques sont:

• écrire des tests d'abord
• wip (travaux en cours) commits sont bons
• commettez souvent (plusieurs dans la journée) et tôt (sauvegardez les étapes de travail)
• appuyez après chaque commit (au cas où votre disque dur planterait ou que le bus vous frappe).
• toujours travailler dans les branches d'abord
• dans la mesure du possible, ne fusionner que dans le code de travail pour maîtriser
• rebase interactive dans git pour réduire les effets avant la fusion du master

Le problème principal, et peut-être celui que vous abordez, concerne le fait que vous possédez une fonctionnalité qui fonctionne et dont l'entreprise a grandement besoin (et doit donc être maîtrisée), mais dont certains tests ont échoué. Une option ici peut être de faire un test en attente qui vous permet d’avancer pour le moment. Toutefois, cela présente un grand danger, car le test peut ne jamais être corrigé et il peut en résulter une tendance dans d’autres domaines de tests simplement «en suspens» cassés au lieu de les corriger.

Une autre option serait d'utiliser et de déployer temporairement la branche. Cela peut aider dans certaines situations, mais n'est généralement pas recommandé et n'est pas durable.

La meilleure option est peut-être d’adopter une approche plus professionnelle du développement logiciel et d’exiger des tests de travail pour chaque code validé. C’est souvent la partie «difficile» du développement logiciel, et non le codage imaginé par beaucoup de gens. Une meilleure approche nécessitera probablement de meilleures estimations initiales, une allocation des ressources, une définition des priorités, etc. De plus, pendant le développement Agile, vous disposez de suffisamment de temps et de discipline pour résoudre les problèmes, au moment où ils se produisent et pendant les séances de pointage.

Concentrez-vous sur ce que «fait» signifie - cela signifie que le code ET les tests sont écrits, ont été remaniés et fonctionnent. Si vous entendez des commentaires tels que "la plupart du temps fait, qu'il vous suffit d'écrire / de corriger / de refactoriser des tests, alors ce n'est PAS fait. Dire qu'une fonctionnalité est réalisée sans être techniquement complète est l'une des erreurs les plus courantes des programmeurs débutants.

La valeur de toute validation, rompue ou non, est que le code est validé sur un serveur. Dans les environnements professionnels, ce serveur est sécurisé, redondant et en cours d'exécution. Si je travaille toute la journée, s’engager est une façon de s’assurer que mon code survivra à tout ce qui arrivera à ma machine locale. Les disques durs meurent. Les ordinateurs portables sont perdus ou volés. Les sauvegardes du serveur de référentiel seront disponibles même si le bâtiment est détruit.

Pensez-y de cette façon. En tant que développeur, l’une des choses les plus perturbantes que vous faites est d’empêcher d’autres développeurs de votre équipe de s’acquitter de leurs tâches.

La philosophie consistant à n'engager que du code de travail provient des équipes de développement travaillant sur le même tronc unique dans le référentiel. Cela peut sembler une folie maintenant, mais il y a 10 ans, c'était la façon normale de travailler. Une branche apparaît lorsque vous souhaitez créer une version stable, mais l'idée d'un développeur travaillant dans une branche pour implémenter une nouvelle fonctionnalité était pratiquement inconnue.

Si votre environnement signifie que vos commits n'affectent pas immédiatement les autres développeurs, alors commettez-les souvent. cela vous donne plus de sécurité dans votre code, ce qui facilite l'annulation d'une erreur de code et de nombreux systèmes de contrôle de source vous procurent une protection de code pour le code engagé (bien que pas tous).

Maintenant, assurez-vous que vos fusions avec des branches partagées avec d'autres développeurs fonctionnent et que tout code que vous promouvez à ce niveau se compile, passe tous les tests unitaires et autres contrôles de cohérence basés sur l'équipe: c'est essentiel si vous ne voulez pas continue à acheter la bière dans le pub ...

Avant de commencer à devenir dogmatique sur la façon de travailler avec le contrôle de version, réfléchissez bien. raisons lesquelles vous travaillez avec le contrôle de version.

S'engager à contrôler les versions bloque l'état de votre code pour référence future - tout le reste est en dehors de cela. Regarder les diffs et créer des correctifs, c'est simplement voir comment le code change entre les instantanés. Les branches et les balises ne sont que des moyens d’organiser des instantanés. Le partage de code avec d'autres développeurs ne leur permet que de regarder un instantané particulier.

Quand devriez-vous vous engager? Lorsqu'il y a une chance raisonnable que vous examiniez l'état de votre code (ou le message de validation expliquant un changement) dans le futur.

Git vous donne beaucoup de flexibilité pour organiser vos instantanés. Il n'y a pas de référentiel central, vous pouvez donc partager votre code avec d'autres développeurs sans transférer votre état dans le référentiel principal. Vous pouvez facilement créer, fusionner et supprimer des branches pour isoler les détails d'un ensemble d'états de la narration du code principal. Vous pouvez vous engager localement pour vous aider à annuler le suivi de votre développement actuel, puis regrouper le tout dans un seul commit avant de le diffuser pour que les autres le voient. Vous pouvez baliser des révisions spécifiques pour les retrouver facilement par la suite.

KISS . Ce qui fonctionne le mieux pour un seul développeur dans les premières étapes du développement d’un petit projet sera complètement différent de ce que vous devez faire lorsque vous avez une centaine de développeurs travaillant sur un système essentiel depuis une dizaine d’années. Dans tout processus de développement logiciel, vous devez éviter de créer des artefacts inutiles simplement parce que quelqu'un d'autre vous a dit de le faire.

Construire / libérer des branches

Vous ne devriez jamais engager délibérément du code erroné dans une branche de construction. Toute branche sous intégration continue ou à partir de laquelle des versions ou des versions quotidiennes sont générées doit toujours être dans un état potentiellement libérable.

Autres branches: Save State Souvent

Pour les branches privées ou à fonctionnalités, les objectifs sont souvent différents. Il peut être souhaitable d’enregistrer fréquemment le code (qu’il fonctionne ou non). En règle générale, vous souhaiterez vous engager chaque fois que vous devrez peut-être revenir à l'état actuel.

Considérez ces exemples où l'état enregistré offre un avantage significatif:

• Vous pouvez effectuer une validation avant d'exécuter une recherche et un remplacement globaux afin de pouvoir rétablir l'arborescence en une seule opération si les choses tournent mal.
• Vous pouvez effectuer une série de validations provisoires lors de la refactorisation d'un morceau de code complexe afin de pouvoir bissecter ou revenir en arrière si vous finissez par casser quelque chose dans le processus.
• Vous pouvez effectuer une validation, créer une nouvelle branche ou créer une balise lorsque vous souhaitez essayer quelque chose d'expérimental tout en pouvant revenir à tout moment à l'état de l'arbre de travail actuel.

Commettre une base de code cassée est acceptable tant que c'est local.

Pourquoi?

• Il est essentiel d'utiliser l'engagement en tant que point de sauvegarde dans votre développement.
• Il vous montre un schéma de pensée utilisé lors du développement du produit.
• Cela ne rompt pas la collaboration .

Cependant, lorsqu'il y a une équipe de programmeurs, la philosophie de la maison de programmation est primordiale et remplace les comportements individuels des commits. Certaines maisons de programmation décident de consigner toute la progression, tandis que d'autres décident de ne valider que le code qui résout une fonctionnalité. Dans ce cas, la valeur ( coût , du point de vue de la gestion logicielle) d'un commit bloqué est terrible:

1. le temps passé à d'autres fonctionnalités est maintenant passé à corriger des erreurs ...
2. la coupe de développement n'est pas remplie ...
3. le produit n'est pas expédié à temps

D'autres points peuvent être ajoutés à ces trois cascadant leurs effets de manière exponentielle dans une fusion de l'entreprise ... bien sûr, cela doit être un effet de la perpétration habituelle chronique de mauvais code.

Je ne pense pas qu'il soit correct de commettre un code erroné.

Ce qui se passe si

• Un correctif urgent est requis. La base de code est dans un état cassé. Vous êtes obligé de restaurer, réparer et déployer.

• Quelqu'un d'autre commence à travailler dans la même branche sans savoir que vous avez commis un code erroné. Ils sont peut-être en train de pourchasser un "hareng" en pensant que leurs changements ont brisé quelque chose.

• Vous décidez de quitter l'entreprise, de partir en vacances ou ne pouvez pas venir au travail pour une raison quelconque. Vos collègues devront creuser à fond pour trouver ce qui est brisé et pourquoi il a été commis dans un état brisé.

• Quelqu'un déploie votre "code erroné"? Cela peut être un "jeu fini" si vous travaillez avec des données personnelles ou sur un fournisseur de paiement.

Répondre à @WarrenT

Je conviens avec vous que, dans un monde idéal où tout le monde travaille dans une branche, engager du code qui ne fonctionne pas peut fonctionner. J'ai travaillé sur de grands projets et même dans certains cas, plusieurs personnes devaient travailler dans une seule branche. J'ai également vu des gens commettre du code «ne fonctionne pas» dans la branche principale, car la publication était dans quelques semaines et ils prévoyaient de le corriger le lendemain. Toutes ces choses sont candidates à un désastre et je suis fermement convaincu qu'elles devraient être évitées à tout prix.

Quelques questions pour vous aider à déterminer s’il est acceptable d’engager du code qui ne fonctionne pas:

1. Êtes-vous surmené?
2. Est-ce que vos coéquipiers cassent constamment la construction?
3. Votre base de code est-elle en désordre et ne peut apparemment pas s'aggraver?

Si vous répondez oui à l'une des questions ci-dessus, vous pouvez valider du code qui ne fonctionne pas.

Rappelez-vous simplement de le réparer le plus tôt possible, de le couvrir de tests unitaires applicables et de vous excuser pour avoir rompu le build.