Conseils pour travailler dans une grande bibliothèque?

Question

Je travaille actuellement sur une bibliothèque assez volumineuse (5M lignes de code, en C++ sous VS2005, 1 solution et près de 100 projets). Même si nous distribuons la compilation, et utilisons la liaison incrémentale, la recompilation et la reliaison après de petites modifications de source prend entre quelques minutes (habituellement au moins 3) et près d'une heure. Cela signifie que nos cycles de modification de code/build/debug tendent à être vraiment longs (à mon goût!), Et il est assez facile de perdre le 'flow' durant une build: il n'y a généralement pas beaucoup de temps pour faire quelque chose d'utile (peut-être faire un peu d'email, sinon lire un article en ligne ou quelques pages d'un livre).

Lorsque vous rédigez un nouveau code ou faire refactoring majeur, je tente de compiler un fichier à la fois seulement. Cependant, lors du débogage par exemple, ça m'énerve vraiment! Je me demande comment je pourrais optimiser mon temps? Je suppose que je ne suis pas le seul dans cette situation: que faire/ faire?

Answer 1

Je ne sais pas beaucoup sur le développement à ce niveau, mais ... il semble que ce serait une bonne idée de séparer en plusieurs solutions. Vous pourriez avoir une dernière étape «pré-expédition» qui les consolide tous en un seul .dll si vous/vos clients insistent vraiment.

Comparez, par exemple, le .NET Framework où nous avons beaucoup de différents ensembles (système, System.Drawing, System.Windows.Forms, System.XML ...). Vraisemblablement, tous ces éléments pourraient être dans des solutions différentes, référençant les résultats de construction des uns et des autres (par opposition à tous dans une seule solution, se référant mutuellement comme des projets).

Answer 2

@Domenic: en effet, ce serait une bonne chose ... Cependant, toute une équipe y travaille depuis un certain temps, et jusqu'à ce qu'ils réussissent, nous sommes coincés avec un seul .dll et quelque chose de tout à fait monolithique :-(

Answer 3

étape par étape ...

La seule solution est de commencer à isoler des blocs de code. Si vous n'avez pas trop de fuite de mise en œuvre (voir ci-dessous **), puis commencer à construire fachades qui isolent les classes derrière . Déplacer les clases à un autre projet et faire la fachade charger les dll au démarrage et rediriger les appels vers les méthodes d'usine.

Concentrez-vous sur la recherche de zones/bibliothèques relativement stables et scindez-les en DLL de bibliothèque isolées. Construire et les versions séparément vous aidera à éviter les douleurs d'intégration.

Je suis sur cette situation sur le passé et la seule façon est de prendre la tâche avec patience.

Par ailleurs, un bon effet secondaire du code de fractionnement est que les interfaces sont devenues plus propre et la taille de la DLL de sortie est plus petit !!. Dans notre projet, suffoquer/réorganiser le code autour et réduire le nombre d'inclusions gratuites a réduit la production finale de 30%.

bonne chance! ** -> un consommateur appelant obj-> GetMemberZ() -> GetMemberYT-> GiveMeTheData (param1, param2)