Il semble qu'il s'agisse davantage de collaboration sur un projet. Je suggère 1) Un programme pour les interfaces, qui assurera dans une large mesure l'avancement global de votre projet. Le principe est également relativement simple, c'est-à-dire que le projet B n'a pas besoin d'implémenter d'abord l'implémentation spécifique, mais décide avec les deux équipes de développement du projet A quelles interfaces sont stables et lesquelles sont instables. Les API instables doivent être réservées pour une utilisation ultérieure. Implémentation, de sorte que même si ProjectB est mis à jour fréquemment, cela n'affectera pas le codage de ProjectA. Si tous les besoins ultérieurs ne peuvent pas être pleinement pris en compte en raison des capacités des concepteurs et des architectes, nous devrions faire de notre mieux pour que ProjectB puisse le faire sous. le principe du brainstorming. Fournir l’interface la plus complète possible. 2) Je ne suis pas sûr des normes de gestion de projet internes de votre entreprise. Par exemple, si vous avez effectué suffisamment de tests unitaires pour ProjectB pour garantir une intégration fluide avec ProjectA. Si ce n'est pas le cas avant, je vous suggère de le faire sur les nœuds clés, ou Nous devons faire quelques tests unitaires de base pour ProjectB. D'innombrables leçons douloureuses nous disent que pour un langage faiblement typé comme Python, il y aura certainement des problèmes s'il n'y a pas assez d'UT. 3) Lorsque 1 et 2 sont résolus, vous pouvez choisir n'importe quelle manière de publier ProjectB, qu'il s'agisse de la synchronisation rsync, de la version Docker ou de la mise à jour svn. Après chaque version, vous pouvez effectuer un test d'intégration et voir la qualité du code. 4) Si la planification actuelle de ProjectB est très mauvaise, il n'y a pas d'API stable et elle change souvent. Si cela est déjà un fait établi, il est recommandé d'encapsuler l'interface de ProjectB et de fournir une encapsulation orientée logique. , c'est-à-dire que dans ProjectB Ajoutez une couche intermédiaire entre ProjectA et ProjectA ProjectA ne doit pas exploiter directement ProjectB, mais exploiter la couche intermédiaire pour assurer la stabilité du code de A/B
Lorsqu'il est emballé sous forme de module, il est installé directement dans le chemin du projet, de sorte que vous n'avez pas besoin de le réinstaller lors de la modification du projet B
Installez ProjectB en mode développement dans l'environnement de ProjectA Vous pourrez directement mettre à jour le code de ProjectB dans le futur sans le réinstaller.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Il semble qu'il s'agisse davantage de collaboration sur un projet. Je suggère
.1) Un programme pour les interfaces, qui assurera dans une large mesure l'avancement global de votre projet. Le principe est également relativement simple, c'est-à-dire que le projet B n'a pas besoin d'implémenter d'abord l'implémentation spécifique, mais décide avec les deux équipes de développement du projet A quelles interfaces sont stables et lesquelles sont instables. Les API instables doivent être réservées pour une utilisation ultérieure. Implémentation, de sorte que même si ProjectB est mis à jour fréquemment, cela n'affectera pas le codage de ProjectA. Si tous les besoins ultérieurs ne peuvent pas être pleinement pris en compte en raison des capacités des concepteurs et des architectes, nous devrions faire de notre mieux pour que ProjectB puisse le faire sous. le principe du brainstorming. Fournir l’interface la plus complète possible.
2) Je ne suis pas sûr des normes de gestion de projet internes de votre entreprise. Par exemple, si vous avez effectué suffisamment de tests unitaires pour ProjectB pour garantir une intégration fluide avec ProjectA. Si ce n'est pas le cas avant, je vous suggère de le faire sur les nœuds clés, ou Nous devons faire quelques tests unitaires de base pour ProjectB. D'innombrables leçons douloureuses nous disent que pour un langage faiblement typé comme Python, il y aura certainement des problèmes s'il n'y a pas assez d'UT.
3) Lorsque 1 et 2 sont résolus, vous pouvez choisir n'importe quelle manière de publier ProjectB, qu'il s'agisse de la synchronisation rsync, de la version Docker ou de la mise à jour svn. Après chaque version, vous pouvez effectuer un test d'intégration et voir la qualité du code.
4) Si la planification actuelle de ProjectB est très mauvaise, il n'y a pas d'API stable et elle change souvent. Si cela est déjà un fait établi, il est recommandé d'encapsuler l'interface de ProjectB et de fournir une encapsulation orientée logique. , c'est-à-dire que dans ProjectB Ajoutez une couche intermédiaire entre ProjectA et ProjectA ProjectA ne doit pas exploiter directement ProjectB, mais exploiter la couche intermédiaire pour assurer la stabilité du code de A/B
Lorsqu'il est emballé sous forme de module, il est installé directement dans le chemin du projet, de sorte que vous n'avez pas besoin de le réinstaller lors de la modification du projet B
Installez ProjectB en mode développement dans l'environnement de ProjectA Vous pourrez directement mettre à jour le code de ProjectB dans le futur sans le réinstaller.