Comment conserver la cohérence de l'architecture de l'application au fur et à mesure que l'équipe grandit?
En tant que développeur unique d'une startup, j'ai eu le luxe de pouvoir prendre beaucoup de décisions dans l'architecture et les frameworks de notre application.
Avance rapide de 4 ans et d'une acquisition plus tard, j'ai une équipe de 5 personnes et j'ai souvent l'impression de vivre dans le Far West. Les gens qui prennent n'importe quelle décision de conception leur plaisent: entier et énumère les types de bases de données à un endroit et en enchaîne un autre, ce cadre pour un problème, puis un cadre différent pour le même problème ailleurs, etc.
Comment puis-je appliquer la cohérence? Cela me semble important, mais les membres de mon équipe semblent souscrire à la méthodologie "si ça marche, ça marche".
Je suppose qu'une grande partie de ma question est: est-il irréaliste de ma part de m'attendre à des normes comme celle-ci? J'ai du mal à me faire passer pour un dictateur qui étouffe la créativité, mais faire ce qu'ils veulent ne semble pas évolutif.
Qu'est-ce qui vous rend si spécial?
Mon processeur dit que cela fonctionne et je veux rentrer chez moi. Pourquoi tu me déranges?
Vous pouvez gérer cette attitude en forçant tout le monde à émettre des demandes d'extraction. Mais maintenant, les délais approchent. Un mauvais code appuie sur les portes de votre château immaculé et vous cédez enfin à la pression. Ou vous gagnez seulement pour trouver tout le monde part et personne n'utilise votre château vierge.
Il existe de nombreux outils pour résoudre ce problème. Contrôle des sources, revues de code, normes de codage, etc. mais le cœur et l'âme du problème sont vos opinions subjectives sur ce qui est le mieux doivent être considérées comme pertinentes. Pour cela, vous devez gagner et maintenir leur respect. Faites cela et c'est beaucoup plus facile. Ne le faites pas et aucun outil ou pratique ne vous sauvera.
La meilleure façon de le faire est de communiquer tôt. Ne me dites pas "nous n'utilisons pas de chaînes pour nos types de base de données dans cette boutique" 6 mois après que j'aie décidé de l'idée. Me dire qu'il a été enterré dans la documentation pendant 2 ans ne justifie pas de me laisser faire ça.
Pour quelque raison que ce soit, vous vous souciez de choses. Si vous vous souciez d'eux et faites un point, communiquez clairement ces éléments avant, pendant et immédiatement après le codage de chaque module.
Le traque de code est une pratique merveilleuse. Investissez dans les outils et les pratiques dont vous avez besoin pour pouvoir consulter le code quelques minutes après sa rédaction. Programme de paire et l'outil est simplement une chaise d'invité.
Pourquoi? Chaque seconde qui s'écoule après avoir écrit du code augmente de façon exponentielle le coût de sa modification. C'est parce que ma mémoire du code a une demi-vie. Je commence à l'oublier au moment où ma vessie demande une pause.
Réduisez les choses qui vous intéressent à leurs principes sous-jacents. Plutôt que de me frapper avec une liste de 101 règles à suivre, donnez-moi les 10 principes qu'elles violent afin que je puisse déterminer quelle règle 102 devrait être seule.
Donnez-moi le pouvoir d'imposer ma propre vision en m'aidant à voir la vôtre et nous nous entendrons très bien.
est-il irréaliste de ma part de m'attendre à des normes comme celle-ci? Je lutte avec l'idée de devenir un dictateur qui étouffe la créativité, mais faire ce qu'ils veulent ne semble pas évolutif.
Alors ne dictez pas! Faites-en une expérience positive. Ce n'est pas un non-sens hippie du nouvel âge. C'est la psychologie de base. Vous essayez de modifier le comportement humain. Aléatoire et positif est le plus fortifiant (il suffit de demander à Las Vegas). Si vous devenez négatif, vous devez être cohérent avec votre renforcement. C'est une douleur impossible à obtenir. Soyez positif en diffusant la sagesse et vous pouvez être désinvolte à ce sujet.
Je sais d'où tu viens parce que j'y suis allé. Vous aviez le contrôle et maintenant c'est parti. Tu veux le récupérer. Eh bien, surmontez-le. Maintenant, vous avez une équipe. Ils n'ont pas besoin d'être contrôlés. Ce dont ils ont besoin, c'est de leadership. Ce dont vous avez besoin n'est pas le contrôle. C'est l'influence. Cela fonctionne mieux et c'est beaucoup moins de travail. Maîtrisez cela et détendez-vous. Cela devrait être amusant.
Faites-le bien et vous pouvez partir en vacances et cela fonctionnera toujours. Comment? Non seulement en étant un leader, mais en incitant également les autres à être des leaders. Une fois que vous avez inculqué votre vision dans l'équipe, ils peuvent travailler pendant que vous êtes parti en imitant simplement ce que vous avez fait. Encadrez les débutants et encouragez-les à intensifier et à influencer les autres également.
Je sais que c'est dur. Nous ne sommes pas entrés dans cette profession parce que nous sommes bons pour traiter avec les gens. Nous communiquons mieux avec le code. C'est très bien. Faites-le rapidement et souvent. Montrez-moi pourquoi le vôtre est meilleur. Écoutez si je dis que ce n'est pas le cas. Faites-le pendant que j'y pense encore. J'adore coder. Il y a peu de personnes sur la planète à qui je peux en parler. Soyez l'un d'eux.
Tout d'abord, amenez les gens à maintenir des choses qu'ils n'ont pas écrites. Il est très facile pour un développeur de prendre l'habitude d'utiliser les frameworks et les techniques auxquels il est habitué. C'est choquant de devoir basculer entre les cadres et les méthodologies. Si quelqu'un est forcé de sortir de son propre coin du code et d'en faire l'expérience souvent, cela incitera certaines personnes à se plaindre et, espérons-le, une discussion productive qui peut amener les gens à vouloir normaliser quelque chose.
Ensuite, tirez les demandes et les révisions de code. Ne laissez jamais le code être fusionné avec vos branches principales sans un examen préalable du code. Tout le monde peut le faire. Encore une fois, lorsque quelqu'un voit quelque chose de différent de ce qu'il aurait fait, il peut inciter la discussion et le travail d'équipe à trouver une meilleure solution. Cela fait également de chacun un gardien de la base de code, ce qui (espérons-le) amène les gens à s'en soucier et à l'état du code qui y est intégré.
Enfin, discutez de la conception. Ils peuvent être formels ou informels, mais en ont. Que ceux qui veulent participer le fassent. Discutez des cadres que vous souhaitez utiliser, les avantages et les inconvénients des énumérations par rapport aux valeurs, etc. Ensuite, prenez une décision et documentez-la quelque part (comme un document de normes). Ensuite, vous avez quelque chose à signaler lorsque des problèmes surviennent. N'ayez pas peur de revoir une décision sur les normes. La technologie change (rapidement) et vos besoins en tant qu'équipe et en tant qu'entreprise peuvent également évoluer.
Aidez les gens à voir ce que vous voyez et à sentir qu'ils ont un intérêt dans la qualité du code. Ensuite, amorcez doucement les discussions en vue de trouver une norme lorsque des divergences d'opinion surgissent.
Effectuez des révisions de code chaque fois que quelqu'un souhaite fusionner du code dans la branche principale/tronc et contraindre les utilisateurs à ces normes lors de la révision du code.
Et je ne veux pas dire que vous seul devez effectuer les révisions de code. Tout le monde devrait revoir le code de tout le monde. Cela diffuse des connaissances sur le système à travers l'équipe, mais crée également une situation où Carol examine le code de Bob et dit: "Je vois que vous avez utilisé un entier là-bas. J'utilise toujours une énumération." Ils découvrent les écarts que vous avez vus et, en supposant qu'ils s'en soucient, ils se rendront compte que tout le monde doit être sur la même longueur d'onde.
Les normes acceptées et convenues émergeront, à quel point vous les documenterez et vous assurerez que les gens les suivent. Cela inclurait des choses comme "enums dans la base de données pour ...", etc. Vous pouvez également inclure la documentation des frameworks à utiliser, etc.
Dans la mesure du possible, vous pouvez écrire des outils/scripts pour analyser automatiquement vos projets et déterminer les normes, outils et approches que le projet utilise. Vous pouvez le faire en exécutant un outil personnalisé dans le cadre d'une génération CI.
Faites écrire la sortie des outils dans un document `` tableau de bord '', par ex. une feuille google avec une ligne par unité (par exemple par `` application '' ou projet ou api ou autre), avec des colonnes pour les différentes métriques/normes suivies. Cela donnera aux gens une visibilité sur les normes existantes, leur niveau d'adoption, etc. et donnera un peu d'ordre au chaos.
Vous pouvez également avoir des colonnes mises à jour manuellement, mais bonne chance pour les garder à jour: D
En plus des réponses fournies, je dis que vous devriez éduquer votre équipe sur ce que vous attendez d'eux en tant que professionnels du développement logiciel, à partir du moment où ils interviewent pour rejoindre l'entreprise.
1 - Créez et suivez les conventions de base de code
Il s'agit de l'une des mesures les plus élémentaires mais bénéfiques que vous pouvez adopter pour améliorer la qualité du code. À la suite des conventions suivantes, le code source sera uniforme dans toute la base de code, réduisant l'effort cognitif de recherche et de lecture des fichiers de code.
2 - Implémenter des architectures logicielles claires
La base de code d'un projet logiciel qui ne suit pas un style architectural clair, quel qu'il soit, se détériore progressivement à mesure que du nouveau code non structuré y est ajouté, devenant plus difficile à modifier. D'où l'importance de consacrer des heures à la conception et à la conservation d'une architecture logicielle adéquate.
3 - Moins c'est mieux: langues, cadres et outils
Chaque langage, cadre et outil supplémentaire que vous introduisez dans votre système entraîne des coûts de développement et d'exploitation supplémentaires. Vous devez toujours évaluer les coûts à long terme d'une décision technologique avant de la prendre pour résoudre un problème à court terme. Évitez les technologies redondantes et tirez le meilleur parti de votre pile actuelle.
4 - Impliquez votre équipe dans les décisions de conception du système
Le moyen le plus efficace de créer un environnement de connaissances partagé est d'impliquer l'équipe dans toutes les décisions de conception du système. Les avantages sont nombreux:
- Les individus se sentent valorisés et font partie de l'équipe
- Les décisions importantes sont contestées par toute l'équipe avant d'être prises
- Les forces et les faiblesses de la conception du système sont mieux comprises par tous
- Crée un sentiment de responsabilité collective et de confiance
5 - La règle du tout-inclus
Je suis d'avis que les efforts de refonte d'une conception de système devraient être menés à terme (tout compris), plutôt que d'être partiellement conclus. Il y a un grand risque d'érosion de la conception de votre système si les développeurs se sentent libres d'appliquer différents styles de codage et modèles architecturaux localement quand ils le jugent bon.
À ce stade, si vous avez mis en œuvre avec succès les suggestions précédentes, votre équipe évaluera probablement ce comportement de développeur voyou comme non professionnel et irresponsable.
J'ai récemment écrit un article de blog sur ce sujet, vous pouvez y trouver des informations détaillées sur ces sujets: https://thomasvilhena.com/2019/11/system-design-coherence