* Code propriétaire * système: est-ce un moyen efficace? [fermé]

Il y a un nouveau développeur dans notre équipe. Une méthodologie agile est utilisée dans notre entreprise. Mais le développeur a une autre expérience: il considère que des parties particulières du code doivent être attribuées à des développeurs particuliers. Donc, si un développeur avait créé une procédure de programme ou un module, il serait considéré comme normal que tous les changements de la procédure / du module soient effectués uniquement par lui.

Du côté positif, avec l’approche proposée, nous épargnons le temps de développement habituel, car chaque développeur connaît bien sa partie du code et apporte des corrections rapides. L'inconvénient est que les développeurs ne connaissent pas complètement le système.

Pensez-vous que l'approche fonctionnera bien pour un système de taille moyenne (développement d'un site de réseau social)?

Comme beaucoup de ces questions, je pense que la réponse est:

Ça dépend

Il y a des raisons de croire que prendre la position que chaque programmeur devrait savoir que chaque ligne de code est erronée.

Si nous supposons un instant que quelqu'un qui a une compréhension profonde d'un élément de code apportera des modifications 5 fois plus rapidement que quelqu'un qui ne le sait pas du tout (ce n'est pas un acte de foi énorme dans mon expérience) et que cela prend environ un mois d’expérience de codage pour bien comprendre un module de taille importante (ce qui n’est pas non plus déraisonnable), nous pouvons alors exécuter des nombres (complètement fictifs et fictifs):

• Programmeur A: a une compréhension profonde
• Programmeur B: aucun

Disons que le programmeur A effectue 1 unité de travail par jour. En 4 semaines de 5 jours ouvrables, il / elle peut obtenir 20 unités de travail.

Ainsi, le programmeur B, commençant à 0,2 unité de travail par jour et se terminant à 0,96 unité de travail le 20e jour (le 21e jour, est aussi bon que le programmeur A), accomplira 11,6 unités de travail dans le même Période de 20 jours. Au cours de ce mois, le programmeur B a atteint une efficacité de 58% par rapport au programmeur A. Cependant, vous avez maintenant un autre programmeur qui connaît ce module aussi bien que le premier.

Bien sûr, sur un projet de taille décente, vous pourriez avoir ... 50 modules? Donc, se familiariser avec chacun d’entre eux prend environ 4 ans, ce qui signifie que le programmeur d’apprentissage travaille en moyenne avec une efficacité de 58% par rapport au programmeur A… hmmm.

Alors considérez ce scénario: mêmes programmeurs, même projet (A sait tout, et B ne sait rien du tout.) Disons qu'il y a 250 jours ouvrables dans l'année. Supposons que la charge de travail est répartie de manière aléatoire sur les 50 modules. Si nous divisons les deux programmeurs de manière égale, A et B ont tous deux 5 jours ouvrables pour chaque module. A peut faire 5 unités de travail sur chaque module, mais B n’obtient, selon ma petite simulation Excel, que 1,4 unité de travail sur chaque module. Le total (A + B) est de 6,4 unités de travail par module. C'est parce que B passe le plus clair de son temps sans aucune connaissance du module sur lequel il travaille.

Dans cette situation, il est préférable que B se concentre sur un sous-ensemble plus petit de modules. Si B se concentre sur seulement 25 modules, il dispose de 10 jours, totalisant 3,8 unités de travail pour chacun. Le programmeur A pourrait ensuite passer 7 jours chacun sur les 25 modules sur lesquels B ne travaille pas, et 3 jours sur les mêmes modules que B. La productivité totale varie de 6,8 à 7 unités par module, soit une moyenne de 6,9, ce qui est nettement supérieur. que les 6,4 unités par module que nous avons obtenues lorsque A et B ont réparti le travail de manière uniforme.

Si nous réduisons la portée des modules sur lesquels B travaille, nous obtenons encore plus d’efficacité (jusqu’à un certain point).

Entraînement

Je dirais également que quelqu'un qui en sait moins sur un module interrompra la personne qui fait beaucoup plus que quelqu'un qui a plus d'expérience. Ainsi, les chiffres ci-dessus ne tiennent pas compte du fait que plus B consacre de temps au code qu'ils ne comprennent pas, plus le temps de A est long, en posant des questions, et parfois, A doit aider à réparer ce que B a fait. Former quelqu'un est une activité qui prend du temps.

Solution optimale

C'est pourquoi je pense que la solution optimale doit être basée sur des questions telles que:

• Quelle est la taille de votre équipe? Est-il judicieux de faire en sorte que tous les participants soient formés de manière croisée, ou si nous avons une équipe de 10 personnes, pouvons-nous simplement nous assurer que chaque module est connu d'au moins 3 personnes? (Avec 10 programmeurs et 50 modules, chaque programmeur doit connaître 15 modules pour obtenir une couverture 3x.)
• Comment est le roulement de votre personnel? Si vous renvoyez des employés tous les trois ans en moyenne, et qu'il faut plus de temps pour vraiment connaître tous les aspects du système, ils ne seront pas assez longtemps pour que la formation soit remboursée.
• Avez-vous vraiment besoin d'un expert pour diagnostiquer un problème? Beaucoup de gens utilisent l'excuse, "et si cette personne part en vacances", mais on m'a appelé à plusieurs reprises pour diagnostiquer un problème dans un système pour lequel je n'avais aucune expérience. Il est peut-être vrai que la personne expérimentée pourrait le trouver beaucoup plus rapidement, mais cela ne signifie pas que vous ne pouvez pas vivre sans eux pendant une semaine ou deux. Peu de systèmes logiciels sont si critiques que le problème doit être diagnostiqué en 1 heure au lieu de 5 heures, sinon le monde va se terminer. Vous devez peser ces risques.

C'est pourquoi je pense "ça dépend". Vous ne voulez pas diviser 20 modules entre deux programmeurs en plein milieu (10 chacun), car vous n’avez alors aucune flexibilité, mais vous ne voulez pas non plus former 10 programmeurs sur les 50 modules, car vous perdriez beaucoup de temps. l'efficacité et vous n'avez pas besoin de beaucoup de redondance.

C'est une idée terrible . Cela peut être plus rapide à court terme, mais cela encourage un code mal documenté, difficile à comprendre, car seul le codeur qui l’a écrit est responsable de sa maintenance. Quand quelqu'un quitte l'entreprise ou part en vacances, tout le plan est bouché. Cela rend également très difficile l’allocation des charges de travail; que se passe-t-il lorsque deux bogues urgents arrivent avec le code que le codeur "possède"?

Vous devriez coder en équipe . Les personnes se voient naturellement attribuer des tâches et se concentrer sur certains domaines, mais le partage de la charge de travail et la collaboration ne doivent pas être découragés.

Cela dépend du domaine du problème.

S'il s'agit d'éléments généraux (actions CRUD simples, etc.), je suis d'accord avec Tom Squires (tout le monde devrait pouvoir y travailler et le modifier).

Cependant ...

Si la solution en question nécessite une expertise du domaine (beaucoup de temps a déjà été investi dans le passé ou de nombreuses recherches doivent être effectuées avant la mise en œuvre, car il s’agit là d’une chose que vous qualifieriez de connaissance spécialisée comme une connaissance spécialisée qui: Tout le monde sur le projet n'a pas), alors un propriétaire devrait définitivement être assigné à cette partie du code. Cela dit, tout le monde devrait pouvoir y apporter des modifications si nécessaire, mais elles devraient toujours être examinées par le propriétaire de cette zone du projet.

Vous ne voulez pas que toute votre équipe (ou plusieurs personnes de l'équipe) recherche et apprennez le même sujet (cycles perdus). Désignez un propriétaire, mais demandez-lui de documenter ses apprentissages et ses conceptions et peut-être qu'il organise des sessions de formation informelles (ou formelles, peu importe) sur la technologie.

C'est une idée horrible . J'ai travaillé dans une entreprise qui a utilisé cette approche et c'est à peu près une recette pour des tas de dettes techniques . L'essentiel est que deux têtes valent presque toujours mieux qu'une. Pourquoi? Parce que si vous n'êtes pas idiot, vous savez que vous n'êtes pas un programmeur parfait et que vous n'allez pas attraper toutes les erreurs que vous faites. C'est pourquoi vous avez besoin d'une équipe - plus d'yeux regardent le même code sous différents angles.

Cela se résume à une chose: la discipline . Combien de programmeurs isolés connaissez-vous qui sont vraiment disciplinés dans leur style de codage? Lorsque vous ne codez pas avec discipline, vous prenez des raccourcis (parce que vous allez "résoudre le problème plus tard") et la maintenabilité du code en souffre. Nous savons tous que "plus tard" ne vient jamais. Fait : Il est plus difficile de prendre des raccourcis lorsque vous êtes immédiatement responsable envers vos pairs dans une équipe. Pourquoi? Parce que vos décisions seront remises en question et qu'il est toujours plus difficile de justifier des raccourcis. Résultat final? Vous produisez un code meilleur, plus maintenable mais également plus robuste.

L'avantage est que tout le monde n'a pas besoin de rechercher et de tout comprendre. L'inconvénient est que cela rend chaque personne nécessaire pour son propre domaine de code, et personne d'autre ne sait comment le maintenir.

Un compromis serait d'avoir au moins 2 propriétaires pour chaque zone de code. Ensuite, quelqu'un peut partir en vacances, occuper un nouvel emploi ou prendre sa retraite, mais il y a toujours quelqu'un qui connaît le code (et peut former la nouvelle deuxième personne). Tout le monde n'a pas besoin de tout apprendre, ce qui est un peu plus efficace.

Ne pas avoir les mêmes 2 (ou 3) personnes travaillent ensemble tout le temps. Échangez des paires pour différents domaines. Ainsi, les connaissances sont également partagées par inadvertance lorsque vous travaillez avec une autre personne dans un domaine de programme associé.

Oui, il est légèrement plus efficace à court terme. Et voilà les avantages. Cela ne dépasse même pas le coût.

Que se passe-t-il lorsqu'il est en vacances ou lorsqu'il est malade inopinément, qu'il quitte ou se fasse frapper par le bus? Que se passe-t-il lorsque vous souhaitez assouplir vos ressources pour obtenir un travail plus rapidement qu'un autre? Quelle est l'efficacité des revues de code? Comment un gestionnaire, en particulier celui qui ne figure pas dans la base de code, peut-il savoir si le développeur travaille dur ou s’arrache les yeux? Qui remarquera si la dette technique commence à courir?

D'après mon expérience, les personnes qui aiment travailler de cette façon sont au mieux des chasseurs de gloire, au pire des paresseux. Ils aiment être la seule personne à qui vous pouvez contacter un problème donné et ils aiment que leur code reste privé. Et ils aiment souvent coder rapidement, sans égard à la lisibilité.

Cela ne veut pas dire que, sur une équipe de 50 développeurs, tout le monde devrait connaître tout le code, mais une équipe de 5 à 7 personnes devrait posséder un module suffisamment puissant pour que ces personnes restent actives. Aucun individu ne devrait rien posséder.

Les autres réponses soulignent au moins trois problèmes. mais je voudrais essayer de traiter les deux ensemble. Les deux problèmes sont:

• expertise : un membre de l'équipe possède des connaissances détaillées sur un domaine particulier; cette connaissance est indépendante de la mise en œuvre spécifique de ce domaine dans le projet
• leadership : bien que le travail de construction du projet puisse être partagé entre de nombreux développeurs; la feuille de route, ainsi que les décisions immédiates concernant les détails importants de la mise en œuvre, sont entre les mains d'un membre de l'équipe en particulier ou de quelques membres seulement de l'équipe.
• Code sans code : la manière particulière dont le projet est mis en œuvre ne dépend pas des styles, des pratiques ou des connaissances de codage d'un développeur particulier de l'équipe; et par le strict respect d'un style de codage bien connu ou d'une spécification bien conservée, tout nouveau membre de l'équipe a une chance égale de comprendre le comment et le pourquoi du projet en tant que développeur expérimenté.

Lorsque le sujet est purement une expertise, le succès du projet peut dépendre d'un niveau élevé de connaissance du domaine; mais cela ne dépend pas de la connaissance spécifique de ce domaine par un expert. Les experts, bien que peut-être rares et précieux, restent essentiellement interchangeables; un comptable fiscaliste expérimenté est aussi utile à un projet de logiciel de planification fiscale qu'un autre, du point de vue de la connaissance de leur domaine. La question est de savoir dans quelle mesure l’expert est capable de transférer ses connaissances au projet.

Lorsque le sujet est purement lié au leadership, la réussite du projet dépend principalement de la cohérence et de la perspicacité des décisions prises par le chef de projet. Bien que nous ayons tendance à privilégier les chefs de projet qui ont une expérience dans le domaine ou qui ont fait leurs preuves en tant que chefs de projet, cela est parfois secondaire par rapport à leur rôle. Le "chef" peut changer de jour en jour si les décisions prises sont cohérentes d’un cas à l’autre et si chaque décision est rapidement exécutée par l’équipe. Si cela fonctionne bien; de nombreuses décisions ne doivent pas nécessairement être "prises" par le responsable du projet car l'équipe comprend déjà quelles décisions seront prises.

Je ne pense pas que la question portait vraiment sur le code sans ego, mais il est difficile de parler de la propriété du code sans aussi discuter de l'importance de ce problème. Maintenir un projet est probablement la plus grande partie du cycle de développement. La meilleure façon de comprendre ce problème est de se demander ce qui se passerait si certains développeurs devaient le quitter immédiatement. Que se passerait-il si toute l'équipe devait être remplacée? Si le projet est mis en doute parce qu'il dépend de certains acteurs clés, vous courez un risque d'échec élevé. Même si vous ne perdez jamais un seul membre de l'équipe, le simple fait qu'un ou plusieurs développeurs soient nécessaires pour faire avancer le projet signifie que vous ne travaillerez peut-être pas aussi efficacement que vous le pourriez si davantage de développeurs étaient informés.

La possession de code a tendance à empêcher le refactoring, à créer des goulots d'étranglement pour le développement et à causer des problèmes d'ego lorsque le code a des problèmes qui devraient être traités.

Je recommande de consulter les auteurs de code avant de modifier le code, même si le code standard élevé doit être suffisamment documenté, testé en unité, testé en intégration et en système pour rendre ce système redondant, rien ne peut nuire à l'obtention d'un autre avis.

C'est mauvais pour beaucoup de raisons, j'ai travaillé dans un magasin où ils ont essayé de passer de ceci à quelque chose de plus raisonnable et c'était moche.

Les raisons pour lesquelles c'est mauvais:

• Si le propriétaire du code prend des vacances et qu'un gros bogue survient, il sera très difficile et fastidieux d'essayer d'apprendre le code ET de corriger le bogue.
• Si le propriétaire du code quitte l'entreprise, leurs projets seront sérieusement retardés, car tout le savoir-faire patrimonial et tribal vient de sortir.
• La documentation est faible. Si je suis la seule personne à le coder, pourquoi devrais-je le documenter? Le problème est lié au fait que toute documentation forcée à être créée sera probablement aussi médiocre, car personne n'en saura suffisamment sur le code pour dire réellement si la documentation est complète ou même exacte.
• Les guerres saintes de code peuvent facilement s'enflammer lorsque tout le monde a son propre petit bac à sable, comme d'autres l'ont mentionné, cela peut devenir très stupide très rapidement. Là où il y a un problème, c'est quand deux personnes doivent travailler ensemble, ni l'une ni l'autre n'a l'habitude de faire des compromis.
• En raison du point ci-dessus, les compétences de travail en équipe ne se forment jamais - les gens ne doivent jamais travailler avec les autres.
• Des fiefs peuvent facilement se former, de petits royaumes constitués de poches de déchets qui n'achètent rien à l'entreprise. Vous ne savez pas que cela se produit jusqu'à ce qu'il soit trop tard, car le module ou l'outil X est la responsabilité de Bob. Et malheur à vous qui devriez même vous demander ce que fait Bob dans son code.
• Les révisions de code et les révisions par les pairs souffrent car personne ne sait rien du code. Si vous ne connaissez pas le code, vous ne pouvez pas repérer les endroits qui ne sont pas corrects et vous contenter de commenter le formatage du texte et les conventions de dénomination.
• Et si vous travaillez pour moi ... la société est propriétaire du code, pas vous. Nous sommes fiers de ce que nous faisons et de ce que nous accomplissons, ainsi que de ce que nous écrivons, mais il s’agit d’une affaire de groupe, comme lorsque votre équipe gagne un match difficile. Tout employé qui travaille pour l'entreprise possède le code à parts égales et, dans le cadre de son travail, il est autorisé à le modifier comme bon lui semble pour que son travail soit de transmettre les objectifs de l'entreprise.

Les plus importants sont vraiment les problèmes de personnel et la documentation. Cette personne partira un jour et vous pousserez l'horaire vers la gauche pendant quelques semaines.

La meilleure approche consiste à faire en sorte que tout le monde se familiarise avec chaque partie de la base de code (ou une demi-douzaine de parties environ si elle est vraiment volumineuse et diversifiée), au point de pouvoir

• Réparer tout défaut dans cette zone
• Ajouter de nouvelles fonctionnalités ou améliorations mineures ou modérées

Chaque personne a tendance à en savoir un peu plus sur certaines choses que d’autres, alors pour les problèmes difficiles, deux ou trois personnes peuvent se regrouper ou l’expert de facto peut s’en occuper. J'ai travaillé dans des groupes où c'était le cas et cela a très bien fonctionné. Non seulement il n'y avait aucun des inconvénients énumérés ci-dessus, mais la dotation en personnel était beaucoup plus prévisible, car nous ne recherchions pas d'experts.

La propriété exclusive du code est que le "propriétaire du code" peut probablement faire les choses plus rapidement que les autres, mais cela ne vaut que si tout le monde est un "propriétaire du code" sur des projets ne se chevauchant pas. En d'autres termes, si les gens tournent autour de l'avantage du "propriétaire unique du code" disparaîtra.

Voir le numéro de camion aka Facteur de bus

Le facteur de bus (également appelé facteur de camion ou numéro de bus / camion ) est une mesure de la concentration d'informations dans les membres individuels de l'équipe. Le facteur autobus est le nombre total de développeurs clés qui devraient être incapables (par exemple, de se faire écraser par un bus / un camion) pour envoyer le projet dans un tel désarroi qu’il ne pourrait pas le faire. le projet conserverait des informations (telles que le code source ) avec lesquelles aucun membre de l'équipe restant ne serait familier. Un facteur de bus élevé signifie que de nombreux développeurs devront être supprimés avant que le projet échoue nécessairement.

"Se faire frapper par un bus" pourrait prendre différentes formes. Cela pourrait être une personne qui prend un nouvel emploi, accouche un bébé, change son mode de vie ou son statut de vie, ou se fait littéralement heurter par un bus: l'effet serait le même ...

Comme pour beaucoup de choses, c'est un gros "dépend". Si c'est un strict "personne d'autre ne peut travailler sur le code", c'est probablement à la limite du mauvais. Si c'est "le propriétaire doit faire une révision du code avant d'accepter un changement", c'est médiocre, ce qui dépend de la volonté du propriétaire d'accepter le changement externe.

L'inconvénient est grave; le "numéro de camion" de votre équipe devient à peu près 1.

Pour passer en revue, le "numéro de camion" est simplement défini comme "combien de membres de l'équipe, dans le pire des cas, pourraient être touchés par un camion avant que l'équipe ne perde la connaissance nécessaire pour effectuer une tâche critique".

Il est naturel, et quelque peu encourageant, que les développeurs se concentrent sur des sous-disciplines; si tout le monde devait tout savoir sur le projet, rien ne serait fait car tout le monde apprendrait ce que tout le monde avait fait, pourquoi cela fonctionnait et comment on pouvait le changer sans le rompre. En outre, si les développeurs ne font pas la même chose dans différents domaines, il est peu probable que les changements entrent en collision. Il est donc généralement utile d’avoir deux ou trois développeurs ou paires de développeurs qui travaillent principalement dans un sous-système particulier du projet et qui le connaissent bien.

Cependant, si une seule personne est supposée toucher une ligne de code particulière, ce dernier quitte, est licencié, part en vacances ou se rend à l'hôpital, et cette ligne de code est la cause d'un bogue. cela doit être corrigé, quelqu'un d'autre doit entrer et comprendre le code. Si personne d'autre que le gars qui l'a écrit ne l'a déjà vu, cela prendra du temps pour arriver à un niveau de compréhension qui permette au développeur de faire le changement qui corrige le bogue sans en faire plus. TDD peut aider, mais uniquement en informant le développeur qu’il a effectué le "mauvais" changement; Là encore, le développeur doit comprendre quels tests utilisent quel code afin de s’assurer que les tests qui échouent n’essayent pas de formuler des assertions erronées.

Je ne prends pas les choses à l'extrême, mais je préfère la responsabilité du code . Vous écrivez du code cassé, vous devriez le réparer. Cela peut être fait au niveau individuel, à deux ou en équipe. Cela évite de passer vos dégâts à quelqu'un d’autre pour les nettoyer. Cela vaut aussi pour les changements.

Les problèmes de charge de travail et de planification vont écraser ceci. Il serait stupide de ne pas réparer un bogue majeur car le coupable est en vacances de deux semaines.

L’objectif n’est pas de faire jouer votre équipe «au jeu du blâme» ou d’attraper trop de bugs (ils ne sont pas tous égaux de toute façon). Basez-vous sur qui a enregistré le dernier code ou demandez à un superviseur de prendre la décision et de l'attribuer à quelqu'un au lieu de parcourir toutes les parties de chaque ligne de code.

Les meilleurs programmeurs finissent probablement par corriger le code de beaucoup d'autres personnes, peu importe la façon dont vous l'assignez.