Pourquoi une équipe de développement insisterait-elle pour que l'utilisation d'une solution unique pour plusieurs projets dans Visual Studio "augmente la complexité de l'interdépendance"?
J'aide à gérer une équipe externe qui commence à développer de nouvelles versions de certains produits existants. Historiquement, cette équipe a toujours utilisé un modèle d'un projet unique dans une solution unique pour environ 30 modules dans Visual Studio qui vont ensemble pour produire une build déployable.
Cela a un impact négatif sur la fiabilité et la qualité de la construction, car ils ne nous envoient pas toujours le code source le plus à jour. Nous essayons de les presser pour unifier tout le code référencé dans une seule solution, mais nous obtenons une certaine résistance - en particulier, ils continuent de parler d'interdépendance entre les modules (lire "projets" dans Visual Studio) augmentée si tout est placé dans un seul fichier de solution. Aucun du code des solutions distinctes n'est utilisé ailleurs.
J'insiste sur le fait que cela n'a aucun sens et que de bons modèles de développement éviteront un tel problème.
L'équipe en question effectue également des corrections de bogues et le développement de nouvelles fonctionnalités sur un produit existant, dont l'expérience a été pour le moins lourde et souffre exactement du même problème de répartition sur plusieurs solutions. On nous a refusé l'accès à leur contrôle de source ( TFS ), et l'approche que nous adoptons pour unifier la base de code consiste à essayer et au moins à réduire la nombre de mises à jour manquantes et plus de régressions occasionnelles (oui, les bogues corrigés sont réintroduits dans le produit) en disant "envoyez-nous un Zip de tout le dossier de la solution afin que nous puissions décompresser, l'ouvrir dans Visual Studio et appuyer sur F5 pour les tests ". En termes de structure générale et de qualité, le code est assez pauvre et difficile à prendre en charge. Cette expérience est la raison pour laquelle je suis déterminé à obtenir les bons processus de travail le plus tôt possible dans le cycle de développement.
Y a-t-il quelque chose qui me manque? Y a-t-il jamais une bonne raison de séparer tout ce code? Pour mon argent, cela devrait être une raison si convaincante que ce serait de notoriété publique, mais je suis plus que disposé à admettre que je ne sais pas tout.
Vous n'avez pas besoin de leur dire comment structurer leurs projets. Au lieu de cela, il est impératif que vous puissiez créer le système à partir de la source en exécutant un seul script, sans obtenir aucune erreur. Si ces scripts exécutent Visual Studio ou Msbuild ou d'autres outils, et si ceux-ci sont appelés une fois, 50 ou 100 fois ne devraient pas avoir d'importance.
De cette façon, vous obtenez le même "test d'exhaustivité" du code que vous obtiendriez en mettant tout dans une seule solution. Bien sûr, ce script ne vous dit pas si l'équipe a vraiment extrait la dernière version de son contrôle de source, mais avoir le code entier dans une seule solution ne le vérifierait pas non plus.
En réponse à "l'interdépendance entre les modules est augmentée si tout est placé dans un seul fichier de solution" - c'est prouvable non-sens, puisque l'ajout de projets à une solution ne modifie aucune des dépendances entre les projets, les dépendances sont le résultat d'un fichier de projet en référençant un autre, qui est complètement indépendant de quelle solution fait référence à quel fichier de projet. Personne n'empêche cette équipe d'avoir les deux - une solution unique qui référence tous les projets, et aussi des solutions individuelles référençant chacune un seul projet.
Néanmoins, je suggère d'ajouter un script de construction. Cela présente des avantages même lorsqu'il n'y a qu'un seul fichier de solution. Par exemple, il permet d'exécuter une génération VS avec une configuration préférée, vous permet de copier les fichiers finaux pour le déploiement (et rien de plus) dans un dossier "deploy" et peut exécuter d'autres outils et étapes pour terminer la génération. Voir aussi F5 n'est pas un processus de construction! , et The Joel Test .
Cela dépend de la quantité de réassemblage des assemblys compilés. S'il n'y a pas de réutilisation des assemblages, alors il n'y a aucune vraie raison de garder les "modules" séparés. En fait, d'après mon expérience, c'est plus un obstacle.
Dans l'équipe de développement dont je fais partie, nous avons des bibliothèques indépendantes que nous avons écrites qui sont utilisées dans plusieurs produits en tant que solution distincte, ce qui, dans ce cas, est logique, sinon nous aurions à compiler l'application A pour maintenir l'application B à jour, qui pourraient être nécessaires pour maintenir la demande C à jour.
Chaque produit est conservé dans sa propre solution, même si plusieurs projets le composent. De cette façon, nous n'avons qu'à construire la solution Library pour garder son code partagé à jour dans tous les produits développés.
Chaque société de logiciels pour laquelle j'ai travaillé avait une équipe de développement de base qui fournissait la direction générale couvrant les cas d'utilisation fondamentaux des produits de la société.
Les développeurs de branche qui utilisent le référentiel principal sont chargés de découvrir les améliorations et de soumettre les demandes d'extraction à la branche principale pour examen. C'est généralement ainsi que l'on devient développeur principal, en montrant qu'on peut apporter de meilleures contributions que simplement attiser les flammes d'un conflit architectural.
Il est probable que votre entreprise ne dispose tout simplement pas des ressources nécessaires pour "unifier immédiatement tout le code référencé en une seule solution". Leur suggérer de le faire sans comprendre leurs contraintes budgétaires est (à tout le moins) susceptible d'empêcher quelqu'un de devenir ingénieur principal.
Formulez donc votre vision grandiose en quelques demandes d'attraction dévastatrices pour le cœur, et préparez-vous à vous défendre en révision!
Il y a un noyau de vérité dans l'affirmation "Utiliser une seule solution pour plusieurs projets augmente la complexité de l'interdépendance".
Une solution unique facilite le référencement d'un projet à partir d'un autre projet (c'est-à-dire la réutilisation du code d'un projet alias "introduisant une complexité d'interdépendance"):
- au lieu de parcourir l'intégralité de votre système de fichiers/cache d'assembly global pour l'assembly référencé, vous pouvez sélectionner le projet à partir d'un ensemble limité de projets pertinents dans la solution; et,
- lors de la lecture du code source, il est beaucoup plus facile de passer à un projet référencé dans la solution qu'à un assembly arbitraire (binaire).
Ainsi, entre les mains d'une équipe indisciplinée utilisant plusieurs projets dans une seule solution peut conduire à de nombreuses dépendances imprudemment introduites. Cependant, une équipe peut mieux essayer d'apprendre la discipline nécessaire pour gérer soigneusement les dépendances, puis utiliser la facilité de réutilisation qu'offrent les solutions.