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éfaste 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 le nombre de mises à jour manquantes et plus de régressions occasionnelles (oui, des bogues corrigés -introduit dans le produit) en disant "envoyez-nous un ZIP du dossier de solution entier afin que nous puissions décompresser, ouvrez-le dans Visual Studio et appuyez surF5 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 augmentée si tout est placé dans un seul fichier de solution" - cela n'a aucun sens, car l'ajout de projets à une solution ne change aucune des dépendances entre les projets, les dépendances sont le résultat d'un projet fichier référençant un autre, qui est complètement indépendant de quelle solution 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 chacune référençant 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 build 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 build. 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 entreprise de logiciels pour laquelle j'ai travaillé avait une équipe de développement principale qui fournissait la direction générale couvrant les cas d'utilisation fondamentaux des produits de l'entreprise.

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 tous les codes référencés 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 grande vision en quelques demandes d'attraction dévastatrices au cœur et préparez-vous à vous défendre en révision!

Il y a un noyau de vérité dans l'affirmation "L'utilisation d'une solution unique 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 "introduction de la 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 dans 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 assemblage 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.