Comment apprendre la bonne approche pour implémenter une demi-fonctionnalité? [fermé]


12

Je dirige une équipe de développement et je souhaite sortir notre produit le plus souvent possible (livraison continue).

Dans de nombreux cas, nous devons implémenter une fonctionnalité qui prend plus de temps à implémenter que le temps entre les versions. Je veux toujours que les gens engagent leur code au quotidien (intégration continue).

Plusieurs fois, la mise en œuvre d'une nouvelle fonctionnalité nécessite la modification d'une fonctionnalité existante et les fonctionnalités existantes, bien sûr, doivent encore fonctionner, même si la nouvelle fonctionnalité n'est pas encore terminée.

Si le développeur utilise la bonne approche , il peut ajuster soigneusement les fonctionnalités existantes et tout ce qui précède n'est pas un problème.

Cependant, quelle EST la bonne approche en fait? Ma propre sensibilité à la programmation me dit quoi faire pour chaque cas individuel, mais j'ai besoin d'en savoir plus et j'ai besoin de matériel de lecture que je peux lire et recommander aux membres de l'équipe de lire. Ou toute autre méthode d'apprentissage de la bonne façon d'apprendre cette approche fera l'affaire.

Voilà donc la question. Comment m'assurer que les membres de l'équipe apprennent la bonne approche pour implémenter une demi-fonctionnalité?

J'ai recherché des personnes affirmant avoir des stratégies à ce sujet, mais je ne les ai pas encore trouvées, à l'exception des personnes écrivant quelques réflexions aléatoires sur le sujet. Peut-être que je n'utilise pas les bons mots de recherche ou peut-être que personne n'a fait de directives faisant autorité à ce sujet.


"les fonctionnalités existantes, bien sûr, doivent encore fonctionner" - selon le contexte, le terme pour une exigence comme celle-ci pourrait être une compatibilité descendante ou l' absence de bogues
moucher

1
voir aussi: Existe
moucher

1
Différents types de tests automatisés peuvent réduire le risque d'erreurs dans les modifications de code. Vérifier. Je recherche l'approche à utiliser en tant que développeur qui doit implémenter une grande fonctionnalité pouvant impliquer 75% de modifications dans le code existant et 26% de nouveau code (le pourcentage supplémentaire est là pour ajouter du mystère).
Niels Brinch du

1
@Niels: Vous devez avoir des développeurs incroyables pour qu'ils puissent avoir du code de travail à la fin de chaque journée qui peut être archivé dans la branche principale et passe tous les tests. Soit cela, soit ils ne font que le strict minimum afin qu'ils soient en mesure de vérifier leur code d'ici la fin de la journée.
Dunk

n'appelleraient-ils pas cela une "branche de fonctionnalité". Vous apportez vos modifications dans la branche, puis fusionnez la branche dans le maître lorsque la fonctionnalité est terminée. Vous ne devriez pas présenter de fonctionnalités à moitié implémentées dans les démos, donc je ne vois pas pourquoi cela ne fonctionnerait pas.
deltree

Réponses:


14

J'ai déjà un point de vue différent des autres réponses ici. Je suis d'accord avec vous que vous souhaitez intégrer les changements des développeurs dès que possible et continuer à tester le mélange combiné de code.

Cependant, je ne suis pas d'accord pour dire que son code de droit d'expédition a été développé ce matin, simplement parce que nous publions cet après-midi. C'est une recette pour des clients déçus.

La solution consiste à avoir des branches dans votre arborescence de contrôle de version et à disposer d'un processus distinct pour promouvoir les deltas vérifiés de la branche de développement à la branche de publication.

De cette façon, vous obtenez le meilleur des deux mondes. Vous avez des développeurs qui font une intégration continue, et les avantages que cela apporte, vous avez un envoi de code stable régulièrement au client, et vous avez un nouveau processus qui teste les fonctionnalités terminées dans la branche développeur, et s'ils réussissent les tests, faites-les partie du produit publié .

Il y a deux outils que je connais qui supportent bien ce genre de processus. Si votre structure de développement est simple, alors git, avec git-flow implémente une bonne structure de branchement qui fonctionne bien dans les petites et moyennes équipes (peut-être 20 développeurs).

Pour les grandes équipes de développement, ou lorsqu'une stratégie de branchement plus complexe est nécessaire pour prendre en charge plusieurs «spins» de votre produit, la précision est la meilleure qui soit. Les développeurs qui ne sont pas impliqués dans la gestion des changements se plaindront que c'est plus difficile que la sous-version etc ... mais il supporte des environnements de développement complexes.


Je serais très intéressé d'en savoir plus sur la stratégie de branchement à laquelle vous faites référence. Avez-vous un lien vers un article ou quelque chose d'autre qui explique plus en profondeur le concept auquel vous faites référence?
Niels Brinch


La caractéristique clé de Git Flow est sa stratégie de branchement clairement définie, ce qui en fait un bon choix pour un produit qui n'a qu'une seule version à produire. Accurrev n'applique pas de stratégie de branchement, mais a la flexibilité et fournit les outils pour gérer efficacement un arbre de branches beaucoup plus complexe.
Michael Shaw

6

Il y a deux problèmes ici: l'un met en œuvre une demi-fonctionnalité; l'autre maintient le produit d'expédition pendant le développement continu.

Implémentation d'une demi-fonctionnalité

Une conception globale solide aidera à cela. Cela vous permet d'implémenter la fonctionnalité avec ses limites clairement définies - par exemple, des API pour des bits de code adjacents, des attentes sur les structures de données et une compréhension de la façon et du moment où le code implémenté sera appelé.

Les tests peuvent inclure des versions simulées du code pour les autres parties de la fonctionnalité; cela aide à faciliter la transition lorsque vous allez implémenter la seconde moitié.

Maintenir le produit d'expédition en état de marche

Il existe une poignée d'options ici:

  1. Désactivez la fonction dans le produit expédié. Ce n'est pas parce que le code est dans le produit qu'il doit être exécuté ou présenté aux utilisateurs. L'inconvénient est que vous n'apporterez pas de valeur incrémentielle à vos utilisateurs et que vous n'obtiendrez pas de commentaires.
  2. Révélez les bords de la fonctionnalité à vos utilisateurs. Montrez ce que vous avez et donnez une indication de ce qui va arriver.
  3. Permettez aux utilisateurs de basculer entre les nouvelles et les anciennes fonctionnalités. Cela nécessite parfois de maintenir deux chemins de code prêts pour l'utilisateur final.

Enfin, si vous rencontrez des problèmes avec l'une de ces solutions, demandez-vous si vous avez divisé la fonction le long des bonnes limites. Si vous découpiez les choses différemment, serait-il plus facile de les séparer?


Il est assez facile de désactiver une nouvelle fonctionnalité qui n'est pas complètement prête. Voilà un bon conseil. Le problème principal du produit livré est donc que les fonctionnalités EXISTANTES peuvent se briser si les gens n'utilisent pas la bonne approche lorsqu'ils modifient le code existant.
Niels Brinch

2
C'est là que de bons tests entrent en jeu. Si vous n'avez pas une couverture décente pour votre base de code, cela pourrait peut-être être un déclencheur pour cet effort?
Alex Feinman

Mais la réponse à ma question peut-elle simplement être "effectuer de bonnes pratiques de code et faire des tests unitaires" etc ...?
Niels Brinch

1

Comment m'assurer que les membres de l'équipe apprennent la bonne approche pour implémenter une demi-fonctionnalité?

En leur enseignant. (duh)

L'apprentissage impliquera l'itération: essayer quelque chose, voir comment cela fonctionne, puis modifier leur approche pour obtenir de meilleurs résultats. Pour ce genre de chose, je recommanderais des revues de conception / code. Vous pouvez voir comment la demi-fonctionnalité est conçue / implémentée et avez la possibilité de donner votre avis. "Ceci et cela ne fonctionnera pas car ils vont casser notre CI; que diriez-vous de XYZ?", "Bon travail ici, c'est vraiment propre."

Faire les évaluations en équipe aidera tout le monde à apprendre ce que vous savez déjà intuitivement.


Je suis totalement d'accord avec ça. Mais tout comme je peux enseigner à quelqu'un comment faire des tests unitaires OU les référer au livre "L'art des tests unitaires" - existe-t-il une ressource similaire à laquelle je peux me référer pour ce sujet?
Niels Brinch

1

La plus grande chose qui vous aidera ici est d'avoir une bonne séparation des préoccupations afin que, autant que possible, un domaine de code n'interfère pas avec un autre.

C'est un endroit où l'utilisation de l'injection de dépendances et de la programmation de l'interface aide vraiment, de sorte que vous puissiez avoir votre implémentation actuelle de ISupportingFeature sur le site, puis lorsque vous devez créer INewFeature qui dépend d'une implémentation différente, vous pouvez simplement développer avec le nouvelle implémentation et maintenir l'existant en production jusqu'à ce qu'il soit bien testé et prêt à être mis en service. En supposant que votre DI fonctionne sur un système de configuration quelconque, cela vous permettra d'avoir le même code en parallèle dans votre système et d'utiliser un code stable à tout moment.

En fait, cette approche de configuration est décrite par Martin Fowler comme un basculement de fonctionnalité.

Bien sûr, le problème ne se pose que si vous déployez tout le code tout le temps. C'est précisément le type de scénario pour lequel les branches de fonctionnalité ont été conçues et bien que je reconnaisse que M. Fowler les fronce les sourcils, je ne sais pas si elles sont si mauvaises, surtout si elles sont créées et utilisées dans un plan et une pensée- par voie.


J'ai l'impression que engager tout le code dans la même branche et déployer tout mon code tout le temps fait partie d'une bonne stratégie d'intégration continue?
Niels Brinch

En lisant davantage sur la livraison continue, cela en fait certainement partie. Je grimace un peu à l'idée de cela, cependant - voulez-vous déployer du code à moitié écrit même s'il doit être désactivé? Peut-être que cela fonctionne bien dans un scénario où la sécurité n'est pas importante, mais cela ressemble à une approche à haut risque pour de nombreux espaces d'application. Cependant, cela me marque probablement comme un vieux mec à la mode.
glenatron

Il semble y avoir deux stratégies concurrentes, où l'une a une seule branche principale et une autre a une branche pour chaque tâche et beaucoup de fusions ... Je ne sais pas ce qui est le mieux ou le mieux - ou si cela touche au cœur de mes questions.
Niels Brinch

Je pense que cela dépend beaucoup du type de chose que vous faites - je serais plus enclin aux branches si j'avais une priorité sur la sécurité et que je ne voulais pas risquer de déployer réellement du code non testé où quelqu'un pourrait le trouver ou ce pourrait être accidentellement activée. Donc, si je dirigeais un site bancaire, je ne pense pas que le CD serait la chose, mais peut-être que si je dirigeais un site Web à fort chiffre d'affaires pour les visiteurs occasionnels / occasionnels, il pourrait être idéal.
glenatron
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.