Faut-il s'attendre à ce que les développeurs compilent une bibliothèque interne avant le programme proprement dit?

Récemment, un développeur senior avec qui je travaille a plaidé pour exiger que les développeurs obtiennent la dernière version et compilent dans le cadre de leur projet une bibliothèque interne majeure. Cela contraste avec le contre-argument selon lequel les équipes de projet devraient travailler à partir d'une version stable qu'elles obtiennent d'un référentiel Maven interne auquel le développeur a fait valoir que le fait d'avoir le code source disponible sur les machines du développeur permet de gagner du temps car il peut lire la source des bibliothèques. code pour déterminer si la fonctionnalité requise est disponible.

Le développeur principal a-t-il un argument valable? Ou est-ce que demander aux développeurs de lire le code source des bibliothèques va à l'encontre de la philosophie de base de l'encapsulation et même d'avoir la bibliothèque en premier lieu?

L'argument de ce développeur principal n'a aucun sens pour moi.

Ils veulent ajouter des frais généraux pour récupérer et compiler constamment une bibliothèque interne afin que les développeurs puissent parfois lire le code source? Cela va perdre beaucoup plus de temps que les développeurs ne doivent regarder le code source que lorsqu'ils ont besoin de vérifier si une fonctionnalité est disponible.

C'est une idée particulièrement mauvaise si la bibliothèque et les clients sont développés par différents groupes de développement et si la bibliothèque est activement développée. Les développeurs clients n'auront aucune protection contre l'instabilité dans la bibliothèque.

Je ne vois pas pourquoi le code source ne peut pas être mis à la disposition des développeurs sans les obliger à faire partie de leur build normal.

La suggestion est

Les développeurs côté client peuvent gagner du temps en lisant le code source de la bibliothèque pour déterminer si les fonctionnalités requises sont disponibles

Vous pourriez faire une suggestion alternative

Nous pouvons gagner du temps en documentant la bibliothèque pour indiquer les fonctionnalités disponibles.

Je n'accepterais pas l'argument selon lequel avoir la possibilité de parcourir la source localement est un avantage, mais si la bibliothèque est en développement actif (éventuellement pour ajouter une prise en charge aux besoins de votre projet), je ne pense pas qu'il soit déraisonnable d'exiger des développeurs qu'ils télécharger les mises à jour fréquemment (éventuellement plusieurs fois par jour). Je pense qu'il est plus judicieux sur le plan commercial de rendre disponible un binaire compilé (et testé à l'unité) au lieu d'exiger des développeurs qu'il compile à partir de la source.

Avez-vous la possibilité au sein de votre projet de configurer une sorte de référentiel partagé où la dernière version compilée serait disponible? Idéalement, vous voudriez un serveur CI qui fasse la récupération et la construction selon un calendrier, mais même si ce n'est qu'une ressource réseau que l'un des chefs d'équipe est responsable de la mise à jour périodique, cela pourrait aider. Bien sûr, cela devrait être dans l'assiette de l'équipe de la bibliothèque, mais de toute évidence, ils ne sont pas intéressés, vous devrez donc prendre leur relais.

J'avais l'habitude de travailler pour une grande entreprise de logiciels qui «faisait constamment la promotion» de ses propres logiciels avec des systèmes commerciaux internes.

Ils ont vu cela comme un autre niveau de test.

Avec quoi je suis d'accord, pour une entreprise, c'est une bonne chose.

Je pense que vous forcer à télécharger et à compiler la dernière version est une étape trop loin, à moins que l'étape de compilation ne soit un élément important de l'offre de vente, voire d'externalisation, d'une bibliothèque.

Bien que la disponibilité du code source puisse être un avantage, si vous avez un agent de construction CI surveillant le référentiel, il est bien plus logique que cet agent compile cette bibliothèque et la copie dans des projets dépendants en tant qu'externe, que d'exiger que les développeurs exécutez deux étapes de compilation différentes lors de la création de leur copie.

Je travaille actuellement sur un projet qui n'est pas connecté à un agent de build, qui nécessite de construire une sous-application avant de construire l'application principale. C'est une douleur grave dans ma partie postérieure; pour apporter une modification à la sous-application, je dois d'abord créer l'intégralité du projet, puis aller dans un dossier de sous-génération, en extraire le produit compilé et le copier dans un autre sous-dossier, avant de générer à nouveau l'intégralité du projet pour vous assurer que la dernière version de la sous-application est incluse dans la génération de l'application principale. Ce n'est PAS ainsi que cela doit être fait; à tout le moins, il devrait y avoir un script MSBuild qui automatisera ce processus, et je préférerais que l'agent de construction mette à jour les externes chaque fois qu'un nouveau code est validé dans le tronc.

Étant donné que tant de personnes ont répondu qu'il n'était pas logique que tout le monde construise une bibliothèque interne, je présenterai le point de vue opposé qui pourrait justifier les raisons:

1. Vous utilisez beaucoup la bibliothèque et il n'y a pas de documentation. Donc, tout le monde devrait avoir la source de référence. S'il s'agit d'une bibliothèque qui est utilisée très fréquemment, avoir la référence à portée de main pourrait être utile

   • Bien sûr, on dirait qu'ils devraient travailler sur la documentation et plus que probablement votre développeur senior en est conscient. Mais avouons-le, la plupart du temps, les équipes de développement se retrouvent avec une tonne de code non documenté, donc quand vous avez besoin de savoir comment cela fonctionne, vous allez à la source. Vous ne devriez pas avoir à le faire, mais à court terme, c'est la meilleure alternative.
   • Habituellement, les meilleures personnes pour mettre en place la documentation sont celles qui connaissent le mieux la bibliothèque. Malheureusement, ce sont les mêmes personnes qui sont généralement les plus occupées, il n'est donc pas si facile pour eux de tout laisser tomber et de commencer à documenter.

2. Lorsque les gens commencent à écrire leur propre code qui dépend de la bibliothèque et que quelque chose dans la bibliothèque ne fonctionne pas, au lieu de jeter les bras en l'air, si la bibliothèque est construite localement, il devient très facile d'entrer directement dans le code de la bibliothèque

   • Cela peut se produire car de nombreuses bibliothèques sont loin d'être parfaites et bien que nous voulions tous travailler avec une version "stable", il peut toujours y avoir des problèmes.
   • Peut-être que vous obtenez de mauvais résultats en raison d'une mauvaise compréhension de l'utilisation d'une API. Même avec la documentation, les gens font souvent de fausses hypothèses
   • Votre gars senior est probablement fatigué de nouvelles personnes (et parfois il y a beaucoup plus de nouvelles personnes que celles qui connaissent le projet à l'intérieur comme à l'extérieur) jetant les bras en l'air chaque fois qu'un crash / une autre erreur semble provenir d'un code de bibliothèque. Donc, au lieu d'avoir à venir vers votre machine puis vers le gars assis à côté de vous, ils veulent avoir la possibilité de répondre avec ces questions: 1) où est exactement le crash? quel module / fichier / ligne? 2) l'avez-vous débogué? qu'avez-vous trouvé?
   • Vos gars seniors ont travaillé avec cette base de code (application et votre bibliothèque principale) assez longtemps et il a peut-être remarqué que lorsque le code est déjà sur la machine et qu'il est prêt à être débogué et parcouru, cela lui facilite la vie et amène les gens pour apprendre la base de code plus rapidement. Donc, pour cette raison, il vous oblige à assumer le coût initial de la construction de la bibliothèque sur votre machine.

Je ne dis pas que sa décision est justifiée, je souligne simplement que a) la question présente un côté de l'histoire et b) il peut y avoir des motifs plausibles.

Ce genre de test serait mieux fait. La chose est cependant, cela devrait être fait par des testeurs, pas par des développeurs . En ce sens, ce n'est ni votre travail ni celui de développeur de bibliothèque.

_{D'après ce que vous décrivez, il semble qu'il n'y ait pas de testeurs dans le projet - si tel est le cas, c'est un problème de gestion, et assez grave.}

... fait gagner du temps car ils peuvent lire le code source des bibliothèques pour déterminer si les fonctionnalités requises sont disponibles

Raisonnement assez boiteux. Lorsque la bibliothèque de versions la plus récente ne parvient pas à se compiler avec le projet de version le plus récent, il peut y avoir plusieurs raisons à cela - le simple fait de forer dans le code source de la lib peut être une perte de temps.

• Que faire si la bibliothèque est OK et que l'échec de la construction a été causé par le bogue dans le code du projet? Ou, que se passe-t-il si l'échec de la construction a été causé par un changement temporaire incompatible qui est censé être corrigé un jour ou deux plus tard? Que faire si un échec de build indique un problème d'intégration compliqué qui prendra une semaine ou un mois à résoudre? Pour un problème d'intégration, l'utilisation d'une bibliothèque de versions antérieures constituerait-elle une solution de contournement ou non?
   
  Quelle qu'en soit la raison, faire une analyse préliminaire de l'échec signifierait perdre du temps au développeur sur un travail censé être effectué par des testeurs.

Une autre chose au-dessus du raisonnement manque est les pertes de productivité inévitables (et assez douloureuses selon mon expérience) qui s'ensuivent quand il faut interrompre le flux en basculant entre les activités de développement et d'AQ.

Quand il y a des testeurs dans l'équipe, ces choses sont vraiment simples et peuvent être manipulées beaucoup plus facilement. Ce que votre développeur «senior» vous lance est essentiellement une ébauche de test.

À chaque modification apportée au projet ou à la bibliothèque, assurez-vous que la génération est réussie.

Les étapes pour procéder à partir de là sont des activités typiques d'AQ: clarifier les détails des exigences, concevoir un scénario de test formalisé, négocier la façon de gérer les échecs de test.

• Du point de vue SQA , il s'agit d'une tâche assez courante de conception, de configuration et de maintenance d'une procédure de test de régression assez simple qui pourrait être hautement automatisée - probablement au point que seule une activité manuelle serait de créer et de maintenir des tickets dans le suivi des problèmes et la vérification des corrections.

Ce que le Sr Dev suggère n'a au mieux que peu de sens. C'est agréable de pouvoir parcourir les sources, mais il existe de meilleures façons de le faire.

Quel référentiel d'artefacts utilisez-vous? Vous devriez pouvoir déployer un bocal source pour chaque version à vivre à côté de la bibliothèque compilée. La plupart des IDE vous permettront ensuite de l'attacher à la bibliothèque compilée pour la navigation source. Eclipse avec le plugin Maven le fera automatiquement.

Si vous avez besoin du code le plus récent, vous pouvez simplement déployer des instantanés de version.

Cela devrait simplement se produire dans votre script de construction:

1. vérifier si une nouvelle version est disponible. sauter 2 sinon.
2. téléchargez-le et compilez-le et exécutez les outils dont vous disposez pour générer localement une référence d'API à partir du code source. afficher un journal des modifications.
3. construisez votre application

Je ne vois pas pourquoi ni comment c'est un problème. De plus, lorsque quelque chose manque dans la référence, vous pouvez l'ajouter aux sources et pousser les modifications. Bien sûr, cela peut sembler un peu effrayant que la bibliothèque puisse changer sous vos pieds, mais si les responsables de la bibliothèque font leur travail correctement, c'est une bonne chose.