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»?


26

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.


5
Si l'équipe est externe, il sera difficile d'essayer de changer quoi que ce soit. Au lieu de vous concentrer sur le problème, vous essayez de pousser votre idée. Le problème est "ils ne nous envoient pas toujours le code à jour", ont-ils résolu ce problème, comme ils le préfèrent. Ne peuvent-ils pas vous accorder l'accès au système de contrôle de version?
RMalke

9
Cela ressemble à un non-sens. Les projets ne seront ni plus ni moins dépendants les uns des autres que ce soit dans une ou trente solutions. La raison pour laquelle le code est conservé dans des solutions distinctes est que la bibliothèque résultante est utilisée par plusieurs versions déployables distinctes. Cela ne vous ressemble pas.
David Arno

3
Il semble que vous ayez beaucoup de problèmes non techniques qui sont mieux résolus par des modifications de votre contrat et de vos énoncés de travail.
Ross Patterson

9
La création d'une solution unique ne signifie pas nécessairement qu'ils doivent abandonner les solutions individuelles, car un projet peut exister dans plusieurs solutions.
Erik Eidt

6
Je ne sais pas pourquoi vous vous interrogez sur les solutions techniques à quelque chose qui est essentiellement un problème de personnes. Renvoyez ces personnes et embauchez des personnes dont le niveau de compétence est médiocre. Cela signifie que vous paierez plus, mais cela en vaut vraiment la peine en informatique en termes de coût total de possession réduit. Plus vous tenez longtemps, plus vous souffrirez.
Brad Thomas

Réponses:


54

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 .


Oui, je suis d'accord que F5 n'est pas un processus de construction, mais nous voulons tester leur code au sein de l'équipe de développement avant de passer à notre processus d'assurance qualité pour des tests de bout en bout, en raison des régressions et des échecs de mise à jour. Comme je l'ai dit, nous n'avons pas accès à leur TFS, nous devons donc importer leurs modifications dans notre propre base de code, puis les archiver dans TFS. À l'heure actuelle, ce processus est si pauvre que l'exécution de la création automatique lors de l'enregistrement est une perte de temps totale! Nous avons la création automatique sur le reste de notre parc de produits et cela fonctionne très bien pour nous.
DrMistry

Je voulais juste ajouter que les trucs "The Joel Test" sont excellents et je recommanderais de bien les regarder. Merci beaucoup!
DrMistry

3

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.


Aucun des projets scindés n'est utilisé ailleurs, c'est frustrant. Ils sont tous utilisés dans ce seul produit et nulle part ailleurs!
DrMistry

1

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!


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.