Comment conserver les mêmes fragments de code sur plusieurs projets [fermé]

Je suis un développeur indépendant travaillant sur plusieurs projets Android. J'ai du mal à conserver la même fonctionnalité sur différents projets. Par exemple, trois de mes applications utilisent les mêmes 2 classes; comme ce sont des projets différents, quand j'ai besoin de changer ces classes, je dois le faire trois fois. Existe-t-il une solution simple à ce type de problème commun?

Séparez le code partagé dans une bibliothèque et incluez la bibliothèque dans les projets.

En tant que développeur Android, vous utilisez probablement Java. Pensez à utiliser un outil de gestion des dépendances comme Maven ou Ivy .

Un effet secondaire est que cela aidera à maintenir la séparation des préoccupations en renforçant la modularité. Le coût est que cela peut prendre un certain travail pour se séparer; l'avantage est une meilleure maintenabilité future. De plus, si jamais vous le décidez, vous pouvez libérer la bibliothèque séparément (commercialement ou en open source) de vos applications.

Contrôle de version. Git. Sous-modules Git.

Mettez vos projets sous contrôle de version, en utilisant un dvcs comme git ou mercurial etc. Mettez le code partagé dans un sous-module dans git. Utilisez le sous-module dans les projets qui en ont besoin. Lorsque vous mettez à jour le sous-module, vous pouvez extraire les modifications apportées à d'autres projets avec une seule commande.

Personne d'autre n'a encore mentionné l'épée à double tranchant, alors j'ajouterai mes 2 cents. Si vous avez plusieurs projets et qu'ils partagent tous du code réutilisable, conformément aux bonnes pratiques / principes de programmation (DRY par exemple), vous devez placer le code dans un emplacement global et le structurer de manière à ce qu'il puisse être partagé par tous. vos projets sans aucune modification. En d'autres termes, définissez les interfaces comme étant génériques et suffisamment communes pour convenir à tout le monde.

Il y a peu d'options pour ce faire: 1) Créez un projet de base dont d'autres dépendent. Ce projet peut créer une distribution binaire que d'autres projets consomment. 2) Tirez un modèle open-source au sein de votre organisation. Le code commun doit être sa propre branche de code et les autres projets doivent intégrer le code de la même manière que vous prendriez le code source de n'importe quel OSS en ligne.

Voici maintenant où l'épée entre en jeu ...

Placer du code dans un lieu commun dont dépendent d'autres projets / personnes peut devenir assez coûteux. Disons que vous avez un morceau de code et que 4 autres projets en dépendent. Un de vos clients qui utilise le projet A trouve un bogue et vous devez apporter une correction. Vous précipitez le correctif et ce client est heureux. Mais vous venez de modifier du code dont dépendent 3 autres projets. Avez-vous retesté tous ces éléments pour vous assurer qu'aucune condition de bord n'a été introduite?

Le code commun doit également être conçu avec beaucoup plus de soin et les interfaces des modules doivent être bien mieux conçues car ce code doit accueillir non pas un mais 4 clients et chacun d'entre eux pourrait simplement utiliser ce code avec une différence si légère.

Si vos projets sont sur des cycles de publication différents, vous devez être encore plus prudent dans la gestion du code commun. Vous ne pouvez pas simplement apporter des modifications dans le code commun car le projet B a besoin de nouvelles fonctionnalités, si vous êtes à 3 jours de couper l'image finale pour le projet C.

Je ne dis pas qu'une bibliothèque commune n'est pas la bonne solution. Je suis un fervent partisan de DRY et j'ai déjà créé et pris en charge du code commun et je continue de le faire. Je voulais juste dire que le simple fait de rendre le code commun aura ses propres dépenses.

Si vous êtes le seul à réutiliser ce code, ce n'est pas aussi mauvais. Si vous avez une équipe d'ingénieurs et qu'ils commencent à utiliser le code commun, les dépenses augmentent encore plus. Si d'autres sont impliqués, attendez-vous à ce que le placement de code dans une bibliothèque commune prenne 3 fois plus de temps qu'il le faudrait pour arriver à un point où vous pensez qu'il est "complet". Vous devrez a) rendre la bibliothèque plus robuste pour vous protéger contre toutes sortes de conditions de périphérie et d'utilisation non valide, b) fournir de la documentation pour que d'autres puissent utiliser la bibliothèque et c) aider d'autres personnes à déboguer lorsqu'elles utilisent la bibliothèque d'une manière que vous n'ont pas anticipé et votre documentation ne couvre pas leur cas d'utilisation spécifique.

Quelques suggestions que je peux vous proposer:

1. Avoir du code commun couvert par des tests unitaires automatisés peut aller très loin et vous donner une idée que lorsque vous apportez une modification, vous ne vous contentez pas de casser un autre projet.
2. Je ne placerais que des fonctionnalités très stables dans du code commun. Si vous avez écrit un cours l'année dernière pour faire de la gestion des minuteurs et que vous ne l'avez pas changé en 9 mois et que vous avez maintenant 3 autres projets qui ont besoin de minuteurs, alors c'est sûr que c'est un bon candidat. Mais si vous venez d'écrire quelque chose la semaine dernière, eh bien ... vous n'avez pas beaucoup d'options (et je déteste le copier / coller du code probablement plus que le gars suivant) mais je réfléchirais à deux fois avant de le rendre commun.
3. Si un morceau de code est trivial mais que vous l'avez utilisé à plusieurs endroits, il vaut peut-être mieux mordre la balle, laisser DRY tranquille et laisser plusieurs copies vivre.
4. Parfois, il est avantageux de ne pas simplement mettre du code commun dans un emplacement commun et que tout le monde y fasse référence. Mais considérez plutôt le code commun comme son propre libérable avec les versions, les dates de sortie et tout. De cette façon, le projet C peut dire: «J'utilise la bibliothèque commune v1.3» et si le projet D a besoin de nouvelles fonctionnalités, vous laissez la v1.3 seule, libérez la v1.4 et le projet C n'est pas affecté. Gardez à l'esprit qu'il est BEAUCOUP BEAUCOUP plus cher de traiter le code commun comme son propre produit plutôt que de simplement le faire archiver dans un emplacement commun.

Il s'agit d'une solution idéale et peut nécessiter des efforts pour fonctionner.

Le principe DRY stipule qu'il devrait y avoir une seule source de vérité faisant autorité. Cela dicte l'utilisation d'un référentiel source unique pour toute la logique du programme, sans duplication; des fichiers organisés pour favoriser le partage et la réutilisation des documents.

Les exigences pragmatiques de la communication dans un environnement distribué et multi-équipes suggèrent qu'il devrait y avoir plusieurs référentiels indépendants, un pour chaque projet ou collaboration.

J'aborderais ce problème en me soumettant à l'inévitable: vous devrez adopter les deux approches simultanément, et nous utiliserons les scripts et l'automatisation pour atténuer le fait que les approches sont contradictoires.

:-)

Le référentiel unifié sera votre unique source faisant autorité. Le processus de génération pour chaque projet copiera tous les fichiers utilisés par ce projet (et seulement ces fichiers) dans un emplacement intermédiaire, puis sera construit à partir de cet emplacement intermédiaire. (Unison ou un outil similaire peut être utilisé pour déplacer des deltas au lieu de fichiers entiers).

Ces emplacements intermédiaires peuvent être utilisés comme copies de travail locales pour l'ensemble des référentiels secondaires, dérivés ou en aval. Les scripts de hook post-commit sur le référentiel faisant autorité met à jour tous les emplacements intermédiaires et, pour chacun d'eux, vérifient s'ils ont changé et effectuent le même commit dans le référentiel secondaire correspondant si un changement est détecté.

De cette façon, les plusieurs référentiels secondaires sont synchronisés avec le référentiel source unique faisant autorité, et le processus de génération garantit que les référentiels secondaires contiennent tous les documents (éventuellement partagés) et autres fichiers nécessaires au succès de la génération. Enfin et surtout, le processus de développement et de génération garantit que les fichiers sont modifiés en un seul endroit et un seul endroit, et que toutes les copies sont conservées de manière cohérente et à jour.