Comment tenir les développeurs informés d'une bibliothèque de code dans les grandes organisations?
Bien que nos produits aient souvent les mêmes exigences, les solutions sont toujours développées à nouveau. De différentes personnes, avec de bons résultats différents et une qualité différente. Une bibliothèque de code spécialement pour les besoins de nos produits semble être une bonne idée.
Je pense que le principal problème ne serait pas de développer cette bibliothèque, mais de dire à tous les programmeurs pour quelles tâches il existe déjà des solutions.
Dans une petite entreprise comme la nôtre, cela est possible, mais comment cela fonctionne-t-il dans les grandes entreprises? Lorsque vous avez de grandes bibliothèques, avec plusieurs centaines de méthodes.
Comment un développeur découvre-t-il qu'il n'a pas à développer une nouvelle solution à un problème car il existe déjà une solution?
Comment empêcher qu'une solution existante soit à nouveau accidentellement développée?
Il existe de nombreuses façons d'y parvenir, mais l'une des plus utiles est révision de code, et c'est quelque chose qui vaut la peine d'être fait dans une organisation de toute taille. Tout le code validé doit être examiné par au moins un autre développeur. Ils donnent ensuite des commentaires à l'auteur d'origine, faisant des suggestions sur la façon dont il devrait être amélioré. Ces remarques peuvent inclure:
- erreurs de programmation possibles
- code où l'intention n'est pas claire
- améliorations des noms de fonction/variable
- de longues fonctions/classes à décomposer, et
- code qui duplique la fonctionnalité de bibliothèque existante
Les révisions de code et généralement parler sont bonnes. Mais je contesterais l'hypothèse sous-jacente.
Essayez pas d'avoir du code partagé du tout.
Vraiment, vous ne voulez écrire que le code qui vous est propre.
Si vous avez une bibliothèque commune, il y a probablement une bibliothèque tierce qui fait mieux le travail et qui est maintenue par un groupe de personnes qui; A. ne sont pas payés par vous. et B. se consacrent à ce seul problème et y apportent une solution valable.
Réduisez vos bibliothèques communes au point où elles ne sont plus courantes.
"Lorsque vous avez de grandes bibliothèques, avec plusieurs centaines de méthodes."
Je n'en ai pas. Ayez de petites bibliothèques qui font un travail.
"Comment empêcher qu'une solution existante soit à nouveau accidentellement développée"
Gardez votre logiciel se divise de la même manière que votre problème se divise. c.-à-d. conception pilotée par domaine ou microservices. Si je travaille sur un problème, je travaille sur le code spécifique à ce problème. Je n'ai pas à me soucier d'un autre code.
Il existe de nombreuses raisons pour lesquelles le redéveloppement de solutions similaires est une chose bonne:
- Vos développeurs auront appris ce que pas à faire des implémentations antérieures. La répétition des mêmes erreurs rendra le processus de développement lent, douloureux et coûteux. Inversement, apprendre des erreurs fera la prochaine itération meilleure que la précédente.
- Lors de la réutilisation, les développeurs de la bibliothèque réutilisent code, mais ce qu'ils veulent réutiliser est expérience. Tant que le code n'est pas aussi flexible que notre esprit, il ne peut pas l'être aussi réutilisable que l'expérience.
- La dette technique des projets sur le terrain commence à 0. Une bibliothèque commune garantirait que la dette technique commence bien au-dessus.
- Les interdépendances au sein d'un projet sont suffisamment difficiles à gérer dans des projets non triviaux. Interdépendances entre les projets deviennent très rapidement douloureux. Fondamentalement, vous mangez rapidement plusieurs ETP simplement en coordonnant les projets, en corrigeant les solutions communes et en gérant les conséquences inévitables des changements de rupture dans votre organisation.
- Les fonctionnalités communes à tous vos projets sont très probablement communes aux développeurs du monde entier. Il est donc très probable que quelqu'un l'ait déjà emballé afin que vous puissiez l'utiliser tel quel plutôt que de passer du temps à le développer.
La quête de la réutilisation du code est le Saint Graal qui OO programmation depuis sa création.
Pourtant, de nos jours, nous réécrivons encore et encore la même fonctionnalité, car:
- nous ne savons pas qu'il existe déjà,
- nous pensons que ce qui existe n'est pas ce dont nous avons besoin
- nous savons qu'il existe mais sommes persuadés que nous pouvons faire mieux
- nous n'avons pas le temps et préférons écrire notre propre code.
En fait, le problème n'est pas technique: il est culturel:
Ce qui a très bien fonctionné jusqu'à présent, c'est la réutilisation des motifs. Nous nous sentons toujours libres et élaborons le code. Et c'est cool de réutiliser un modèle: tout le monde en parle, et c'est dans tous les programmes avancés.
Une autre chose qui fonctionne bien est l'utilisation de bibliothèques standard. Ici, il existe une abondante documentation à ce sujet qui facilite leur utilisation. Il est inclus dans la formation linguistique, donc il y a une énorme sensibilisation. Il est bien entendu que les bibliothèques standard sont plus fiables que les bibliothèques personnalisées. Ensuite, il y a une pression des pairs pour l'utiliser.
Le problème avec le code réutilisable personnalisé est triple:
- il pourrait ne pas y avoir suffisamment de sensibilisation. l'effort supplémentaire de trouver;
- la réutilisation n'est pas valorisée de manière appropriée
- la fiabilité du code interne pourrait ne pas être évaluée à sa valeur légitime.
Le premier problème peut être facilement résolu via des revues de code ou et de la documentation. Beaucoup d'autres réponses abordent ce point.
Malheureusement, les deuxième et troisième sont liés à la perception des gens et à la culture de l’entreprise. Il n'y a rien que vous puissiez faire pour surmonter ces problèmes directement et convertir miraculeusement les gens à de nouvelles croyances.
Il faut donc travailler sur la valeur. Expliquez clairement aux gens que la réutilisation est valorisée par la direction plutôt que le réaménagement. Offrez des opportunités d'échange sur ce qui existe déjà.
Maintenant une idée qui n'est pas applicable dans tous les contextes. Mais quoi de plus attrayant que de faire de la bibliothèque un produit? Que ce soit un produit interne, un produit open source ou un vrai produit ajouté à votre catalogue?
La connaissance de la bibliothèque, la disponibilité de la documentation et la promotion transmettront le bon message à vos employés.
La disponibilité en tant que produit montre également clairement qu'il existe une incitation à réutiliser les composants de la bibliothèque: non seulement ils sont minutieusement testés, mais son utilisation fait la promotion du produit de l'entreprise avec un cas de réussite si nécessaire.
faire de votre bibliothèque un produit encouragera les collègues à faire des tutoriels, mais aleo à élever les normes de qualité, brisant ainsi les obstacles de faible qualité.
La seule autre chose que je peux ajouter est de recréer essentiellement la communauté open source à l'intérieur votre organisation. Concentrez-vous sur de petites bibliothèques étroites et utilisez des gestionnaires de packages pour votre pile technologique (NuGet pour .NET, Maven pour Java, NPM pour JavaScript, etc.). Mais alors vous avez besoin de l'infrastructure pour soutenir cette communauté. Cela signifie essentiellement quelque chose de similaire à GitHub ou Azure DevOps, pour n'en nommer que quelques-uns. Cela augmentera les coûts juste pour gagner du temps pour le développeur, c'est donc un acte d'équilibrage. Pouvez-vous gagner suffisamment de temps de développeur pour compenser le coût supplémentaire?
Vous auriez vraiment besoin d'une grande quantité de code partagé pour que cela en vaille la peine et le temps de maintenir cette infrastructure. À ce stade, il est plus rentable d'emprunter la route mentionnée par Ewan dans sa réponse, qui consiste à décomposer votre code en services réutilisables.
Tout code "partagé" est susceptible d'être des fonctions de bibliothèque qui sont petites et peu nombreuses. Copier et coller est presque plus facile et plus rentable.