Facile à maintenir la culture d'entreprise en mots. Cependant, seules quelques entreprises explorent activement les quelques caractéristiques de la culture d'entreprise qui ont un impact significatif sur la productivité - car c'est le plus difficile.
Pour les équipes logicielles, la propriété du code est un prédicteur clé du bien-être de l'ingénierie. Dans ce guide pratique, nous analyserons exactement comment vous intégrez ce principe dans le travail quotidien de votre équipe de développement, afin que le bien-être de votre base de code soit préservé par lui-même.
J'ai eu la chance de rencontrer certains des meilleurs développeurs du monde - chez Stepsize, je travaille avec eux tous les jours. Et lors des discussions sur la création de la dette technique, avec les principaux développeurs de sociétés telles que Skyscanner, Spotify, Palantir et d'autres, une question est invariablement soulevée: la propriété.
Dans les équipes qui interagissent étroitement et se développent rapidement (enfin, c'est-à-dire dans les équipes modernes), où les développeurs peuvent s'engager dans n'importe quelle partie de la base de code, le code est facilement encombré et devient un monstre similaire à Frankenstein. Et quand les choses vont assez mal, quelqu'un devrait intervenir, comme le capitaine Marvel, et réparer le tout avec un gros refactoring.
Pour éviter cette situation, les équipes de développement essaient d'adhérer à l'un des nombreux bons conseils de Robert S. Martin («Oncle Bob»), à savoir les « Règles du boy-scout »: gardez le code en meilleur état qu'auparavant . Voici une extension gratuite pour VSCode pour vous aider à rendre cela beaucoup plus facile .
Néanmoins, malgré le niveau de compétence et les meilleures incitations des développeurs, il semble que la loi immuable du développement logiciel est que la dette technique s'accumule - jusqu'à ce qu'elle devienne trop, et ensuite nous devons prendre le temps de beaucoup de refactoring . Nous avons été réticents à accepter cela dans le cadre du cycle de vie du développement logiciel.
Peut-être que tout cela se résume à un manque de discipline?
Alors j'ai pensé avant. Et puis j'ai rencontré Gareth Vizaji , l'architecte en chef de Snyk.io , et il m'a frappé avec la phrase suivante:
La propriété est le principal indicateur du bien-être de l'ingénierie.
Que voulait-il dire? Et comment pourrait-il faire une telle déclaration?
Il existe une énorme quantité de recherches montrant que lorsque les membres de l'équipe possèdent les fruits de leur travail, sont responsables devant les gestionnaires et assument la responsabilité du succès et de l'échec, toutes sortes de bonnes choses commencent à se produire.
Malheureusement, cela n'est pas facile à réaliser dans la pratique. En partie parce que, apparemment, la productivité de l'ingénierie ne peut pas être mesurée , et les pratiques de développement modernes peuvent être considérées comme encourageant une mauvaise propriété du code en toutes circonstances. La vérité est que jusqu'à présent, il était incroyablement difficile de mesurer correctement la propriété dans les équipes de développement ... donc nous ne savions même pas à quel point il était «bon» pour cet indicateur.
Heureusement, des recherches scientifiques récentes ont montré que la propriété du code - la meilleure mesure indirecte de la notion vague de «propriété» dans les équipes de développement - peut être mesurée par l'activité de validation de Git. Et c'est un merveilleux indicateur avancé du bien-être de votre base de code.
Les parties de la base de code auxquelles de nombreux développeurs apportent des modifications sont encombrées au fil du temps, et celles avec lesquelles moins de personnes travaillent sont généralement en meilleur état. Ne me croyez pas sur parole - de bonnes personnes de Microsoft ont étudié cela par leur propre exemple.
Source: étude Microsoft
Je peux presque entendre certains d'entre vous crier que vous ne voulez pas d'une situation où un seul développeur est la seule personne autorisée à toucher n'importe quel morceau de code - cette approche a des effets secondaires terribles. Je vous comprends et ce n'est pas ce que nous proposons.
Écoutez-moi jusqu'au bout.
Il existe différentes formes de propriété de code adaptées à différentes circonstances.
Propriété collective et manque de propriété
La propriété collective est la propriété [...] dans laquelle le code est détenu conjointement, mais les responsabilités et les horaires sont clairement définis. Chaque membre de l'équipe peut travailler sur n'importe quel sous-système ou service, si nécessaire.
Non-propriété - une situation dans laquelle [...] plusieurs développeurs apportent des modifications au même sous-système, mais la coordination des actions, la responsabilité de la qualité ou la communication intra-équipe est minime. Dans de tels systèmes, il ne faut pas s'attendre à un travail de haute qualité.
Source: étude Microsoft
Vous pouvez continuer cette partition en ajoutant au tas également le code sans propriétaire et la propriété exclusive, mais je ne veux pas manquer l'essentiel, alors voici un graphique montrant le spectre des formes de propriété du code:
La propriété collective devrait être votre choix par défaut et la forme de propriété que vous devriez viser. Notez que cela ne signifie pas qu'un seul développeur de votre équipe est autorisé à modifier le code, ou que toute modification du code nécessite son approbation. Cela signifie seulement qu'il est parfaitement clair pour tous les membres de l'équipe avec qui il doit discuter de toutes les questions qu'il a, et que le propriétaire du code fera très probablement face à la révision du code (révision du code). Cela permettra à tous les membres de l'équipe d'améliorer les normes d'écriture de code et de prendre conscience de la façon dont leur propre code a été modifié.
Le propriétaire est responsable de l'état de son code, et les gérants doivent le lui demander. Cela ne signifie pas qu'il doit être frappé à la tête pour chaque bug qui s'est infiltré dans son code; cela signifie que les propriétaires sont autorisés à prendre des décisions concernant la qualité du code et la dette technique; ils seront tenus responsables de ces décisions avec des mesures supplémentaires à l'appui, telles que la cohésion et l'activité répétée (désabonnement) (pour plus de détails, consultez notre article sur les mesures techniques de la dette ).
Le manque de propriété, ou la faible propriété, est l'opposé de la propriété collective, et dans la plupart des cas, cette forme de propriété doit être évitée. Comme déjà mentionné (et cela peut sembler évident) pour des fichiers comme package.json n'ayant pas de propriétaire clairement défini est une situation normale. Aller à l'extrême n'est pas nécessaire.
Code orphelin
Le type le plus désagréable de manque de propriété, l'un des bords du spectre des formes de propriété du code. Vous n'avez certainement pas besoin de cette forme de propriété. Évitez-le à tout prix ... sauf s'il s'agit bien sûr d'un code que vous ne toucherez plus jamais. Mais un tel code est très rare.
Le code est considéré comme sans propriétaire si son développeur principal a cessé d'apporter des modifications à la base de code. Peut-être qu'il a quitté l'organisation ou qu'il est passé des développeurs aux gestionnaires. Dans tous les cas, vous avez de sérieux problèmes - et votre base de code aussi.
Cependant, il existe une solution. Vous devez traduire le code source en toute autre forme de propriété qui lui convient le mieux. Pour éviter l'apparition de tout code sans propriétaire dans votre base de code, assurez-vous que vos plans pour le cas de rejet ou de renvoi de cas incluent l'introduction de nouveaux propriétaires du code dans le cours des affaires de son ancien propriétaire. Vous pouvez leur faciliter la tâche en les affectant automatiquement à l'affichage des demandes d'extraction de modifications de code. En l'absence d'un tel, vous pouvez simplement désigner les propriétaires du code comme bon vous semble.
Quelle que soit la méthode que vous choisissez, ne laissez pas le code sans propriétaire suspendu dans votre base de code. Vous ne savez jamais ce qui lui arrivera si vous le laissez à la merci du destin.
Propriété exclusive (propriété absolue)
C'est l'autre extrémité du spectre de la propriété du code. Avec lui, tout peut être à la fois merveilleux et très difficile.
Le code est considéré comme la propriété exclusive lorsque le propriétaire est le seul développeur qui peut apporter ou approuver des modifications au code, ou lorsque le propriétaire est, en substance, la seule personne qui a déjà apporté des modifications au code dans le passé.
Les petites startups rencontrent souvent des pratiques similaires dans leur travail. En règle générale, chaque développeur est responsable de l'intégralité de l'historique d'un seul fichier et il est prévu que la propriété de ce fichier soit conservée. Ce n'est pas la fin du monde; les startups, après tout, ont des ressources limitées, et vous devez faire certains sacrifices. Mais si un jour le développeur déplace le bus, cette partie du code sera sans propriétaire. Pour de telles situations, vous devriez avoir un plan de sauvegarde.
Dans les grandes entreprises d'ingénierie, un faible « facteur bus » peut être un véritable problème, en particulier lorsqu'il s'agit de parties critiques de la base de code, le roulement du personnel est élevé et la dette technique recrutée par l'entreprise est trop importante. Par exemple, si vous laissez un développeur qui a gâché tout votre système de paiement configuré manuellement, vous aurez un énorme mal de tête - au cas où vous voudriez changer votre modèle de tarification, ou si vous trouvez un bogue dans sa base de code qui vous fait pendant de nombreux mois, ils ont reçu moins d'argent de leurs plus gros clients. Ensuite, soit quelqu'un devra se réunir et essayer de comprendre le code pour y apporter des modifications, soit vous devrez déclarer une faillite technique sur votre système de paiement et le réécrire à partir de zéro (mais avant de le faire, veuillez lire ceci ).
Ne laissez pas cela vous arriver.
Cependant, il y a des moments où la propriété exclusive du code est acceptable ou même recommandée. Vous voudrez peut-être établir cette forme de propriété pour les parties de la base de code pour lesquelles la déclaration «si cette partie tombe en panne, nous pouvons nous replier, car alors l'entreprise ne pourra pas nous payer de salaires ou nous irons en prison».
Dans de tels cas, même si vous souhaitez diffuser des connaissances sur la partie critique du code entre plusieurs développeurs pour maintenir un facteur de bus suffisamment élevé, vous souhaitez probablement également établir des règles interdisant l'injection de demandes de tirage sans l'approbation du propriétaire unique du code correspondant.
Résumé
Efforcez-vous de la propriété collective de la grande majorité des fichiers de votre base de code (50% à 90% de la propriété du code pour un fichier donné) et soyez plus discipliné pour augmenter la propriété du code et réduire la dette technique si nécessaire.
Les avantages sont les suivants:
- Normes d'écriture de code plus élevées et correctement maintenues. Dans un petit groupe bien informé, le respect de normes élevées est plus facile. Cela s'applique non seulement aux développeurs qui modifient leur propre code, mais aussi aux revues de code rédigées par leurs pairs et affectant les parties qu'ils possèdent.
- Facilitez la communication. Une propriété explicite et claire signifie que chaque développeur de l'équipe sait qui répondra le mieux à sa question.
- Refactorisation plus ciblée et efficace. Si vous décidez de rembourser une partie de la dette technique, les développeurs solides qui possèdent le code approprié sont les mieux adaptés pour ce travail. Utilisez les mesures de propriété, de connectivité et d'activité répétitive pour définir les domaines de préoccupation dans votre base de code. Vos développeurs utiliseront leur budget pour la dette technique à bon escient et ne passeront plus jamais de temps à rembourser une dette technique qui n'en vaut pas la peine.
- Le facteur bus ne sera jamais incontrôlable. Vous pouvez utiliser la propriété du code pour organiser le partage des connaissances dans votre organisation. Si le degré d'appropriation est trop élevé, demandez à d'autres développeurs d'examiner le code et les tâches associées à sa modification. Vous améliorerez progressivement vos indicateurs de propriété, ce qui conduira à une meilleure qualité de code et à une dette technique moindre.
Comme tout ce qui en vaut vraiment la peine, créer une culture d'ingénierie de la propriété du code (et la suivre!) Prend du temps et des efforts, mais cela sera payant avec intérêt. Ce facteur affecte directement presque tout le bien-être d'ingénierie KPI que vous pouvez imaginer. Intégrez-le dans la culture de votre entreprise et, à long terme, il deviendra votre énorme avantage concurrentiel.