Espaces de noms associés à l'explication du contrôle TFS/Source

Question

En tant que société ISV, nous nous heurtons lentement à la question de «structurer votre code». Nous développons principalement en utilisant Visual Studio 2008 et 2010 RC. Langues C# et vb.net. Nous avons notre propre Team Foundation Server et bien sûr nous utilisons le contrôle de la source. Lorsque nous avons commencé à développer sur la base du .NET Framework, nous avons également commencé à utiliser Namespaces de manière primitive. Avec le temps nous sommes devenus plus matures, je veux dire que nous avons appris à utiliser les espaces de noms et nous avons structuré le code de plus en plus, mais seulement dans la portée de la solution. Nous avons maintenant environ 100 projets et solutions différents dans notre Source Safe. Nous avons réalisé que beaucoup de nos propres classes sont codées très redondantes, je veux dire, un Write2Log, GetExtensionFromFilename ou une fonction similaire peut être trouvé entre une et 20 fois dans tous ces projets et solutions.

Donc, mon idée est:

Création d'un seul type de dossier racine dans le contrôle source et démarrer une structure propre hiérarchie-namespace ci-dessous de cette racine, Appelons-CompanyName. Une classe Write2Log serait alors trouvée dans CompanyName.System.Logging. Chaque fois que nous créons une nouvelle solution ou un nouveau projet et que nous avons besoin d'une fonction de journalisation, nous nommons cette solution et la plaçons en conséquence sous le dossier racine de CompanyName. Pour avoir la fonctionnalité de journalisation, nous importons (ajoutons) le projet existant dans la solution . Ces 20 projets/solutions avec la classe write2log peuvent ensuite être conservés en un seul endroit.

À mes questions: - est-ce une bonne idée, la philosophie des espaces de noms et le contrôle de la source? - Il doit y avoir un bon livre expliquant les espaces de noms combinés avec le contrôle de la source, oui? des astuces/conseils/astuces? - Comment gérez-vous vos 50+ projets?

Answer 1

Voici comment nous le faisons (nous sommes aussi un éditeur de logiciels, et nous utilisons TFS):

Nous avons un cadre en interne que tous nos produits utilisent. Le framework inclut des classes de base pour notre couche d'accès aux données, des services tels que la journalisation, les fonctionnalités utilitaires, les contrôles d'interface utilisateur, etc.

Donc, nous avons un projet d'équipe pour notre cadre: Framework \ v1.0 \ Main \ Framework

(notez la répétition du "cadre", fait un peu bizarre, mais il est important)

Ensuite, nous avons un projet d'équipe pour chaque produit, et nous bifurquons la framwork dans le projet d'équipe:

ProductName \ v1.0 \ Main \ ProductName

ProductName \ v1.0 \ Main \ Framework (ramifié de \ Framew ORK \ v1.0 \ Framework principal \, nous faisons cette branche en lecture seule)

tout code sous "\ Main \ ProductName" peut faire référence à un code sous \ Main \ Framework

De plus, si nous avons besoin Pour créer des branches de travail de notre produit, nous nous branchons simplement sur "Main" comme suit:

ProductName \ v1.0 \ WIP \ MyBranch \ (ramifié de Main, où MyBranch == Main)

Cela nous donne 2 caractéristiques vraiment cool:

1. Je peux créer des branches sans déconner mes références aussi longtemps que je garde tout en dessous de "Main" ensemble. Cela est dû au fait que VS utilisera des chemins relatifs aux références, et tant que je garde tout ensemble sous Main (et que je ne mentionne rien de principal, les chemins relatifs restent intacts.)

2. Si je mets à jour le " réel "framework (sous \ Framework \ v1.0)), je peux choisir pour chaque produit quand je veux fusionner ces mises à jour du framework dans la base de code du produit.

(qui est vraiment utile si vous utilisez des bibliothèques partagées, car il découple les versions internes de votre cadre commun de versions externes de vos produits). Si vous ne faites que passer aux bibliothèques partagées, l'un des problèmes que vous allez rencontrer est celui des "collisions", où une modification de votre code partagé impose des modifications à votre code de produit afin de rester compatible. En branchant votre code partagé, vous pouvez mettre à jour votre infrastructure sans affecter immédiatement tous vos produits en même temps.