Gestion de base de code pour les applications connexes développées séquentiellement

Question

J'ai travaillé sur une série d'applications avec des fonctionnalités connexes, chaque application étant livrée pour un client différent. Les applications ont des fonctionnalités importantes en commun, mais certaines fonctionnalités spécifiques aux besoins de chaque client ne peuvent être fournies à aucune autre. Parce que toutes les versions appartenant à nos clients (A1, B2, A3) ont été financées et développées séparément et successivement dans chaque cas, nous avons simplement pris un instantané de la source des clients précédents le mettre dans un nouveau référentiel SVN et commencé à faire des changements à partir de là. Nous avons réussi jusqu'à présent mais avec plus de clients attendus à l'avenir et nous prévoyons de transférer certaines des améliorations de l'application du client A3 dans une nouvelle version pour A1. Notre configuration actuelle ne sera pas gérable avec notre processus actuel .

Ce que je cherche, c'est de savoir comment ce genre de chose a été fait ailleurs et quelle serait la meilleure façon de procéder. Je vais décrire mes pensées sur la façon dont nous procédons avec les préoccupations que j'ai à ce sujet et je suis à la recherche de commentaires à ce sujet.

Nous prévoyons que nos clients soient divisés en deux groupes principaux en fonction de certaines différences de capacités de haut niveau. Mon préfixage de nos identifiants clients avec A et B reflète cela; Les versions A1 et A3 du logiciel ont nettement plus de points communs que celles de B2. À l'heure actuelle, nous ne nous attendons pas à ce qu'il y ait une catégorie C à ajouter, mais nous ne pouvons pas exclure que cela change dans plusieurs années.

Notre idée de base est de diviser les parties communes de la fonctionnalité (à la fois backend et gagner des classes de forme) en bibliothèques de base communes pour les clients de type A et B; et ensuite hériter des classes communes et implémenter des fonctionnalités spécifiques au client pour chaque version dans une solution séparée. Nous pourrions également avoir une bibliothèque commune de premier niveau pour les choses partagées avec A et B, bien qu'il y ait suffisamment de différences entre A et B, car je crains que nous finissions par surcharger suffisamment de méthodes pour ne faire qu'ajouter de la complexité à la situation.

La raison pour laquelle je pense que je dois mettre chaque client application dans une solution séparée au lieu d'avoir une solution unique et juste sélectionner quelle application pour exécuter les clients est de plusieurs fois:

La première est que, en raison de client spécifique nous de NDA Il est probable que de nouveaux développeurs ne puissent pas accéder aux applications précédemment car, sans avoir été chargés de travailler sur l'application du client X, ils ne peuvent pas répondre au besoin imposé par l'externe de connaître l'approbation NDA. La seconde est que, parce que nous travaillons directement sur l'argent d'un client spécifique, nous ne pouvons pas modifier la fonctionnalité des bibliothèques communes (par ex. Déplacer quelque chose du client vers la version principale ou vice). application pour continuer à travailler avec le nouveau noyau. Cette contrainte est en grande partie la raison pour laquelle nous avons d'abord utilisé le concept de base de code géré de manière indépendante et que la validation de la «correction» de la division des fonctionnalités communes et spécifiques au client est un défi au niveau contractuel.

La troisième est liée à la seconde. Pour des raisons de sécurité si le client X ne peut pas avoir la caractéristique Y, l'application de X ne peut pas avoir de méthode pour implémenter Y dans la bibliothèque commune même si l'application de X n'a ​​aucun moyen d'appeler la méthode. ingénierie écrire leur propre front-end qui se trouve au-dessus de la bibliothèque commune.

Edit: Cette question semble to've la plupart du temps mort, mais je l'ai fait obtenir une quantité décente de discussion sur another site.

Answer 1

Je n'ai pas été tout à fait cette situation, mais nous espérons que cela sera utile.

Je pense que vous êtes sur la bonne voie pour garder les clients dans des solutions distinctes; Répéter le code pourrait être un travail supplémentaire au moment du développement au départ - mais il est encore pitoyable à côté du volume de deuil que vous pouvez obtenir lorsque la gestion des dépendances s'égare - et les frais généraux de devoir les gérer en premier lieu. Je garderais le Stable Abstractions Principle et Stable Dependencies Principle à l'esprit: fermez autant de code commun et de bas niveau dans des bibliothèques qui ne changeront pas trop et que les paquets les plus volumineux (et politiquement sensibles) peuvent référencer.

Pour moi, il y a une distinction importante entre le code « bibliothèque » qui offre une faible niveau « codage » ou des services de niveau système (enregistrement de fichiers, accès confog, etc.) et pur code logique métier/modules. Donc j'aurais pensé qu'un peu de réutilisation raisonnable était acceptable.

Egalement en ligne avec SAP et SDP est l'approche d'abstraction des implémentations autant que possible: l'inversion de dépendance et le modèle de stratégie seront utiles ici. Bien que ce que vous faites ne soit pas une application multi-locataires, je pense que vous pourriez trouver quelques problèmes communs - et j'espère que vous trouverez des solutions ou des approches utiles. Toutes les suggestions que j'ai faites ici semblent être au niveau du code/architecture/pattern - je suis conscient que je ne me suis pas beaucoup porté volontaire sur le côté pratique de la gestion du code/QA/Release - désolé.