Est-il mauvais d'avoir de nombreux contributeurs dans un référentiel de code?
Est-ce une mauvaise chose d'avoir un grand nombre de contributeurs dans un référentiel de code?
Mon entreprise actuelle a un repo très important. Ce repo compte plus de 40 contributeurs.
Et il y a un débat pour savoir si c'est une mauvaise chose ou non.
Qu'est-ce que tu penses? Quelle est la bonne pratique à ce sujet?
Cela déclenchera probablement beaucoup de réponses d'opinion qui, dans ce cas, peuvent ne pas être si mauvaises. Voici la mienne.
En général, je dirais que oui, 40 contributeurs pour une application propriétaire, c'est beaucoup. Lorsque vous aurez autant de contributeurs, vous feriez mieux de vous assurer d'avoir mis en place de nombreuses mesures de sécurité qui limitent la marge de manœuvre des individus. À cet égard, je suis d'accord avec Michael. Ma principale préoccupation serait le contrôle des problèmes de conception, en m'assurant que les choses ne descendent pas des rails. Vous aurez besoin d'un gardien de porte, quelqu'un familier avec la conception globale qui contrôle ce qui se passe et ce qui ne va pas. Il grandira pour faire confiance à quelques individus le long de la pyramide, une pyramide qui devra croître régulièrement. Ensuite, cela peut fonctionner. Vous ne voulez pas que des groupes de personnes développent des choses indépendamment les uns des autres où chaque groupe ne sait pas ce que font les autres groupes.
Plus il y aura de monde, plus cela demandera de gestion. Il faut du temps pour que les choses s'installent et pour que les gens deviennent efficaces, comme dans toute organisation. Le simple fait de démarrer un projet et d'y envoyer immédiatement 40 personnes n'est pas susceptible de réussir. Alors oui, cela peut fonctionner mais seulement si vous commencez petit et que vous le faites une étape à la fois.
Je ne crois pas que la responsabilité soit partagée, donc je dis que vous aurez besoin d'une hiérarchie assez rigide, d'un propriétaire technique pour régir toutes les contributions. Si vous ne l'avez pas, vous obtiendrez soit le chaos, soit l'incapacité de faire de grands changements en cas de besoin.
Il y a des projets qui comptent plusieurs centaines de contributeurs. Le noyau Linux vient à l'esprit, donc ne pas avoir 40 jeux d'yeux améliorant le code et corrigeant les bogues n'est pas une mauvaise chose.
Cependant, ce qui importe, ce sont les processus de gestion des changements et les contrôles en place pour garantir que quelques mauvaises validations par un développeur n'entraînent pas l'arrêt complet du développement.
Ceux-ci peuvent aider à garantir que davantage de développeurs puissent travailler ensemble:
- Le code a-t-il des tests unitaires?
- Les tests unitaires sont-ils exécutés avant la validation?
- Les développeurs travaillent-ils sur leur propre branche?
- Le code est-il révisé par les pairs dans le cadre d'une stratégie de fusion de succursales?
- Le code est-il modulaire? en ce que chaque changement individuel n'affecte que quelques fichiers isolés?