Fusion d'équipes avec différentes préférences de framework frontal
Mon entreprise vient de fusionner et ma petite équipe s'est donc agrandie. De notre côté, nous utilisons React depuis plusieurs années, et je crois fermement que c'est le choix supérieur à tous égards à Angular, qu'ils utilisent historiquement. Nous avons tous les deux nos propres modèles qui ont été développés au cours des dernières années pour divers projets communs.
Étant donné que le produit final des deux peut être conçu pour ressembler et fonctionner de manière presque identique, est-il conseillé de laisser les deux développeurs utiliser ce qui leur convient le mieux pour de nouveaux projets? Dans ma tête, si tout le monde s'en tient à un style et à des protocoles de données prédéfinis, les utilisateurs finaux ne feront pas la différence et tout le monde est content.
En plus de la complexité, si nous adoptons cette approche, les nouveaux développeurs juniors devraient-ils être poussés de toute façon à essayer de pousser vers un cadre majoritaire?
Cette consolidation est préférable lorsque les chefs techniques sont déplacés. Ensuite, une comparaison active peut être effectuée avec différentes piles technologiques. Le développement consiste en partie en des danses rituelles incompréhensibles dans le code. Les gens doivent avoir la chance d'essayer une autre approche sur un terrain vert.
Si vous commencez trop tôt pour consolider, vous dépenserez beaucoup d'efforts supplémentaires pour moins de qualité en donnant un mauvais goût aux développeurs.
Envisagez une solution hybride de deux systèmes parallèles permettant une transition plus détendue et essayez de copier une fonction dans l'autre technologie, avec une petite équipe mixte.
Si la question concernait les systèmes d'exploitation, vous auriez le même problème. Autrement dit, si un groupe utilise Linux et l'autre FreeBSD, comment décidez-vous?
Le problème se produit car il n'est pas ancré dans les fondamentaux. Au lieu de cela, il est basé sur les caprices de la préférence des produits. Si le logiciel a été écrit en interne et est devenu le cœur de l'entreprise, alors il est basé sur l'informatique fondamentale et les préférences personnelles - et le choix tout à fait - sont éliminés.
Le débat sur le meilleur cadre est tout simplement trop fondé sur l'opinion et ne mènera à rien.
Ce que vous pourriez, c'est essayer de le pondérer plus objectivement. Pour cela, vous pouvez regarder la fonctionnalité qui fournit le cadre mais aussi ce qui existe autour du cadre et ce dont vous avez besoin.
Notez que je ne connais que Angular, je vais fournir ici quelques exemples de questions qui ne sont là que pour vous donner un exemple de ce que vous pourriez analyser pour aider à la décision à prendre:
- Angular Material fournit tout ce dont vous avez besoin de manière simple sur les composants alors qu'il y a plus de travail autour des dépendances pour React? +1 pour Angular.
- Vous avez besoin d'une bibliothèque pour dessiner des graphiques spécifiques et des bibliothèques dans Angular ne vous en fournit qu'une partie et vous aurez besoin d'un développement spécifique pour l'autre pendant que vous avez une bibliothèque qui gère tout in React? +1 pour React.
- Le système de routage d'Angular, avec plusieurs prises, a un grand intérêt pour vos besoins et React n'a rien de mieux pour cela (je ne sais absolument pas si c'est vrai ou non) +1 pour Angular.
- Le modèle de front-end pour une équipe semble être capable de gérer dès le départ plus ce dont vous avez besoin techniquement +1 pour cette équipe.