Comment maintenir la cohérence dans l'architecture des applications au fur et à mesure que l'équipe grandit?


49

En tant que développeur unique dans une start-up, j'ai eu le luxe de pouvoir prendre de nombreuses décisions dans l'architecture et les frameworks de notre application.

Quatre ans plus tard et une acquisition plus tard, j'ai une équipe de cinq personnes et souvent, on se croirait dans le Far West. Les personnes qui prennent la décision de conception leur plaisent: entiers et énumérations pour les types de base de données à un endroit et chaî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 adhérer à la méthodologie "si cela fonctionne, cela fonctionne".

Je suppose qu’une grande partie de ma question est la suivante: est-il irréaliste de ma part d’attendre de telles normes? Je lutte avec l'idée de devenir un dictateur qui étouffe la créativité, mais faire ce qu'ils veulent ne semble pas être évolutif.


8
Pouvez-vous nous en dire le plus possible sur votre processus SDLC existant? Êtes-vous Waterfall, Agile, etc.? Utilisez-vous TFS ou la gestion des tâches? Effectuez-vous des revues de code ou utilisez-vous FxCop ou d’autres formes de validation de code? Produisez-vous une documentation de conception? Avez-vous un rôle d'architecte désigné?
John Wu


1
@gnat: Pas un grand doublon, si les réponses sont une indication.
Robert Harvey

2
Pour être juste, ces normes auraient dû être établies très tôt et fondées sur un document de "meilleures pratiques" largement accepté, afin que personne ne puisse se plaindre de favoritisme ou d'élitisme. Si une personne vous oppose durement, vous devrez vous demander si un cow-boy vaut la peine pour un environnement sain pour le reste de l'équipe et remplacez-le, ils partiront bientôt, de toute façon, ils le font toujours. Ensuite, je pense que tous les conseils donnés ci-dessous concernant l’utilisation d’une révision de code stricte avant l’archivage et l’ajout d’un composant d’architecture feront des merveilles.
Patrick Hughes

1
C'est le Saint Graal de l'ingénierie logicielle (mis à part l'autre Saint Graal, qui décrit précisément les besoins).
pmf

Réponses:


55

Qu'est-ce qui vous rend si spécial?

Mon processeur dit que ça marche et je veux rentrer à la maison. Pourquoi tu me déranges?

Vous pouvez gérer cette attitude en obligeant tout le monde à émettre des demandes d'attraction. Mais maintenant, les délais sont imminents. Un mauvais code presse sur les portes de votre château immaculé et vous cédez enfin à la pression. Ou vous ne gagnez que si tout le monde part et que personne n'utilise votre château immaculé.

De nombreux outils aident à résoudre ce problème. Contrôle de la source, revues de code, normes de codage, etc., mais le cœur du problème, ce sont vos opinions subjectives sur ce qui est le mieux à considérer comme pertinent. Pour cela, vous devez gagner et maintenir leur respect. Faites cela et c'est beaucoup plus facile. Si vous ne le faites pas, 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 je me sois décidé à le faire. Me dire que cela a été enterré dans la documentation pendant 2 ans ne me permet pas de le faire.

Pour une raison quelconque, vous avez des choses qui vous tiennent à cœur. Si vous en tenez à vous et faites en sorte que ces informations soient clairement communiquées avant, pendant et immédiatement après le codage de chaque module.

Le harcèlement criminel est une pratique merveilleuse. Investissez dans les outils et les pratiques dont vous avez besoin pour pouvoir réviser le code quelques minutes après sa rédaction. Programme de paires et l'outil est simplement une chaise d'invité.

Pourquoi? Chaque seconde qui s'écoule après que j'écris du code augmente de manière exponentielle le coût pour le changer. 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 tiennent à 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 enfreignent pour que je puisse déterminer quelle règle 102 devrait être la mienne.

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 d’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 être évolutif.

Alors ne dictez pas! Faites-en une expérience positive. Ce n'est pas une absurdité hippie du nouvel âge. C'est la psychologie de base. Vous essayez de modifier le comportement humain. Aléatoire et positif est le plus important (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 lorsque vous diffusez la sagesse et vous pouvez être décontracté à 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 du leadership. Ce dont vous avez besoin n'est pas le contrôle. C'est de l'influence. Cela fonctionne mieux et demande 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? Pas seulement en tant que leader, mais en faisant en sorte que les autres soient également des leaders. Une fois que votre vision a été intégrée à l'équipe, elle peut travailler pendant votre absence en imitant simplement ce que vous avez fait. Encadrez les débutants et encouragez-les à agir et à influencer les autres.

Je sais que c'est dur. Nous ne sommes pas entrés dans cette profession parce que nous sommes doués pour traiter avec les gens. Nous communiquons mieux avec le code. C'est très bien. Faites-le vite et souvent. Montre moi pourquoi le tien est meilleur. Écoute si je dis que non. Faites ceci pendant que j'y réfléchis encore. J'aime coder. Il y a peu de gens sur la planète à qui je puisse en parler. Soyez l'un d'entre eux.


4
Ce que vous entendez par "harcèlement criminel" est assez évident ... Mais Google ne me donne rien d'autre que des lois pénales du monde entier.
Jeremy

3
ajouter «normes de codage» à la liste
BЈовић

5
Comme il semble que je suis en train d’introduire le terme, je vais donner l’étymologie de «code stalking». J'avais vérifié dans du code qui utilisait une fabrique abstraite pour obtenir ses horodatages. Un développeur pair essayait de fusionner (archiver le code) et faisait défiler les modifications de code depuis son extraction. Elle a remarqué mon usine et a pensé que c'était curieux. Elle ne savait pas pourquoi je faisais ça. Alors elle a marché et m'a demandé. Quand je semblais confuse, elle dit: "Oh, je ne faisais que te suivre avec un code" Facebook change notre vocabulaire.
candied_orange

1
Vrai! " Donnez-moi le pouvoir d'imposer ma propre vision en m'aidant à voir la vôtre et nous nous entendrons très bien. " J'aime mélanger poésie, code et philosophie!
Pedro Lobito

@candied_orange: Je suis un peu déconcerté par tout le truc du "harcèlement moral". Étiez-vous en train de la punir? Dans le contexte de votre réponse, il semblerait qu’elle vous traquerait du code.
Robert Harvey

23

Tout d’abord, demandez aux gens de maintenir des choses qu’ils n’ont pas écrites. Il est très facile pour un développeur de prendre l'habitude d'utiliser des frameworks et des techniques auxquels il est habitué. C'est choquant de devoir basculer entre les frameworks et les méthodologies. Si une personne est forcée de sortir de son propre coin de code et d’expérimenter cette expérience souvent, cela suscitera des plaintes et, espérons-le, des discussions productives pouvant amener les gens à vouloir normaliser quelque chose.

Ensuite, extraire les demandes et les révisions de code. N'autorisez jamais la fusion de code dans vos principales branches sans une révision préalable du code. Tout le monde peut le faire. Encore une fois, quand quelqu'un voit quelque chose de différent de ce qu'il aurait pu faire, cela peut stimuler la discussion et le travail d'équipe pour 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 associé.

Enfin, discutez de la conception. Ils peuvent être formels ou informels, mais les ont. Laissez ceux qui veulent participer le faire. Discutez des cadres que vous souhaitez utiliser, des avantages et des inconvénients de l’énumération par rapport à l’intérêt, etc. Prenez ensuite une décision et documentez-la quelque part (comme un document de normalisation). Vous avez alors quelque chose à signaler lorsque des problèmes surviennent. En outre, n’ayez pas peur de revenir sur une décision en matière de normes. La technologie évolue (rapidement) et vos besoins en équipe et en entreprise aussi.

Aidez les gens à voir ce que vous voyez et à sentir qu'ils ont un intérêt dans la qualité du code. Puis, lancez doucement les discussions en vue de trouver une norme lorsque des divergences d’opinion apparaissent.


La bonne chose à propos de cette méthode est que le manager ne fait pas qu'imposer ses préférences, il donne la possibilité à l'équipe de décider et de lui donner le pouvoir de la faire respecter.
Robin Bennett

6

Effectuez des révisions de code à chaque fois que quelqu'un souhaite fusionner du code dans la branche principale / le coffre et maintenez les utilisateurs conformes à ces normes lors de la révision du code.

Et je ne veux pas dire que vous seul devriez effectuer les revues de code. Tout le monde devrait revoir le code de tous les autres. Cela diffuse des informations sur le système au sein de l’équipe mais crée également une situation dans laquelle Carol examine le code de Bob et dit: «Je vois que vous avez utilisé un entier ici. J’utilise toujours un enum. Ils découvrent les divergences que vous avez constatées et, s’ils s’y intéressent, ils se rendront compte que tout le monde doit s'entendre sur la même page.

Les normes acceptées et convenues apparaîtront. Vous pourrez alors les documenter et vous assurer que les personnes les respectent. Cela inclurait des choses comme "énums dans la base de données pour ...", etc. Vous pouvez également inclure la documentation des frameworks à utiliser, etc.


Je suppose qu’une grande partie de ma question est la suivante: il est irréaliste d’attendre de telles normes. Je me bats avec l'idée de me présenter comme un dictateur qui étouffe la créativité, mais faire ce qu'ils veulent ne semble pas évolutif
Deekor

3
@ Matthew, même si je suis généralement d'accord avec vous, je procéderais dans l'ordre inverse. Les revues de conception d'abord, et les directives émergent de / pendant les revues de conception. Si vous demandez à l'architecte / au responsable de tout noter dès le départ, le fardeau revient à l'intervenant .
Nick Alexeev

@ Deekor: Vous devez choisir vos batailles. Déterminez ce sur quoi vous devez mettre les pieds et documentez-le. Vous n'êtes pas obligé de tout
Robert Harvey

2
@Deekor, vous pouvez appliquer les normes et les pratiques de codage courantes sans "étouffer la créativité". C'est un argument fallacieux quand même. Les normes de codage communes mènent à un logiciel facile à entretenir. Le codage gratuit mène à des cauchemars.
Matthew

1
@ Nick Alexeev, je suis d'accord; va éditer.
Matthew

1

Dans la mesure du possible, vous pouvez écrire des outils / scripts pour analyser automatiquement vos projets et déterminer les normes, outils et approches utilisés par le projet. Vous pouvez le faire en exécutant un outil personnalisé dans le cadre d'une génération de CI.

Faites en sorte que la sortie des outils soit écrite dans un document de "scorecard", par exemple une feuille Google avec une ligne par unité (par exemple, par "application", projet ou API, etc.), avec des colonnes pour les différentes mesures / normes suivies. Cela donnera aux gens une visibilité sur les normes en vigueur, leur degré d'adoption, etc., et donnera un peu d'ordre au chaos.

Vous pouvez aussi avoir des colonnes mises à jour manuellement, mais bonne chance pour les tenir à jour: D


0

En plus des réponses fournies, je vous dis que vous devriez informer votre équipe de ce que vous attendez d'eux en tant que professionnels du développement logiciel, à partir du moment où ils passent une interview pour rejoindre l'entreprise.

1 - Créer et suivre les conventions de code

C'est l'une des mesures les plus fondamentales mais les plus bénéfiques que vous puissiez adopter pour améliorer la qualité du code. En conséquence des conventions suivantes, le code source sera uniforme dans l’ensemble de la base de code, ce qui réduira l’effort cognitif lié à la recherche et à la lecture de fichiers de code.

2 - Implémenter des architectures logicielles claires

La base de code d'un projet de logiciel qui ne suit pas un style architectural clair, quel qu'il soit, se détériore au fur et à mesure que de nouveaux codes non structurés y sont ajoutés, devenant de plus en plus difficiles à modifier. D'où l'importance de mettre du temps pour la conception et la conservation d'une architecture logicielle adéquate.

3 - Moins c'est mieux: langages, cadres et outils

Chaque langage, cadre et outil supplémentaires 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 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 de système

Le moyen le plus efficace de créer un environnement de connaissances partagé consiste à impliquer l'équipe dans toutes les décisions de conception de 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 tout le monde
  • Crée un sentiment de responsabilité collective et de confiance

5 - La règle du tout-en-un

Je suis d’avis que les efforts pour refactoriser une conception de système devraient être menés à bien (tout compris), au lieu d’être partiellement achevés. Il existe 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 d'architecture localement lorsqu'ils le souhaitent.

À ce stade, si vous avez mis en œuvre avec succès les suggestions précédentes, votre équipe jugera probablement que le comportement de ce développeur malhonnête est non professionnel et irresponsable.


J'ai récemment écrit un billet de blog sur ce sujet. Vous pouvez y trouver des informations détaillées à ce sujet: https://thomasvilhena.com/2019/11/system-design-coherence

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.