Traiter avec des collègues lors du développement, besoin de conseils [clôturé]

J'ai développé notre architecture de projet actuelle et j'ai commencé à la développer par moi-même (en atteignant quelque chose comme, revision 40) .

Nous développons un cadre de routage de métro simple et ma conception semblait extrêmement bien faite - plusieurs modèles principaux, les vues correspondantes, la logique principale et les structures de données ont été modélisés "comme ils devraient être" et entièrement séparés du rendu, une partie algorithmique a également été mise en œuvre en dehors des modèles principaux et avait un nombre mineur de points d'intersection.

J'appellerais cette conception évolutive, personnalisable, facile à implémenter, interagissant principalement sur la base de l '"interaction boîte noire" et, enfin, très agréable.

Maintenant, ce qui a été fait:

• J'ai commencé quelques implémentations des interfaces correspondantes, porté quelques bibliothèques pratiques et écrit des talons d'implémentation pour certaines parties d'application.
• J'avais le document décrivant le style de codage et des exemples de cette utilisation du style de codage (mon propre code écrit).
• J'ai forcé l'utilisation de C++techniques de développement plus ou moins modernes , y compris le no-deletecode (enveloppé via des pointeurs intelligents), etc.
• J'ai documenté le but des implémentations d'interfaces concrètes et comment elles devraient être utilisées.
• Des tests unitaires (principalement des tests d'intégration, car il n'y avait pas beaucoup de code "réel") et un ensemble de simulations pour toutes les abstractions de base.

J'étais absent pendant 12 jours .

Qu'avons-nous maintenant (le projet a été développé par 4 autres membres de l'équipe):

• 3 styles de codage différents dans tout le projet (je suppose que deux d'entre eux ont accepté d'utiliser le même style :) , il en va de même pour la dénomination de nos abstractions (par exemple CommonPathData.h, SubwaySchemeStructures.h) , qui sont essentiellement des en-têtes déclarant certaines structures de données.
• Manque absolu de documentation pour les pièces récemment implémentées.
• Ce que je pourrais récemment appeler un single-purpose-abstractiongère désormais au moins 2 types d'événements différents, a un couplage étroit avec d'autres parties et ainsi de suite.
• La moitié des interfaces utilisées contiennent désormais des variables membres (sic!).
• Utilisation du pointeur brut presque partout.
• Tests unitaires désactivés, car " (Rev.57) They are unnecessary for this project".
• ... (ce n'est probablement pas tout) .

L'histoire des commits montre que ma conception a été interprétée comme une surpuissance et les gens ont commencé à la combiner avec des vélos personnels et des roues réimplémentées, puis ont eu des problèmes d' intégration des morceaux de code.

Maintenant - le projet ne fait encore qu'une petite partie de ce qu'il doit faire, nous avons de graves problèmes d'intégration, je suppose que certaines fuites de mémoire.

Y a-t-il quelque chose à faire dans ce cas?

Je me rends compte que tous mes efforts n'ont eu aucun avantage, mais le délai est assez proche et nous devons faire quelque chose. Quelqu'un avait-il une situation similaire?

Fondamentalement, je pensais qu'un bon début (enfin, j'ai fait tout ce que je pouvais) pour le projet conduirait probablement à quelque chose de bien, cependant, je comprends que je me trompe.

Remanier sans pitié pour sortir du pétrin!

Prenez le style de codage qui représente la majeure partie du style utilisable et utilisez-le pour ce projet.

Le pire, c'est que vous devez revenir à la révision 40, et vos programmeurs ont eu une session de formation de 12 jours, ce qui leur a permis de mieux comprendre le sujet.

Si vos programmeurs ont beaucoup à apprendre sur le codage propre, les douze jours sont les moindres délais que vous aurez.

En paraphrasant votre question - "Je suis parti pendant quelques semaines et je ne suis pas d'accord avec ce que mon équipe a fait quand je suis parti, comment puis-je leur faire faire ce que je veux quand je ne suis pas ici?"

Je vous suggère que ce n'est pas un problème technique, c'est un problème de gestion. Mon point de vue (veuillez me pardonner si je me trompe) est que vous dictez la solution technique à une armée de sbires qui, pour une raison quelconque, ne peut pas ou n'est pas d'accord avec ou comprend votre solution.

Si 12 jours suffisent pour endommager votre conception, il doit y avoir une raison. Le design est-il fragile? est-il trop conçu? ou est-ce que l'équipe l'a fait par dépit? Quels sont vos délais et livraisons? Serré? essayaient-ils simplement d'en rencontrer un?

Un cas où j'ai vu cela, l'avance technique était tellement en avance sur le jeu que le développeur moyen (moi) ne pouvait pas suivre. Le responsable technique n'a pas réussi à concevoir un code commercialement viable, car il était le seul à pouvoir le maintenir. Si un développeur diplômé ne peut pas le maintenir, c'est trop complexe pour le monde commercial. Dans tous les autres cas, c'était simplement un manque de compétences en gestion des personnes du côté de la gestion.

La dynamique d'équipe est brisée. Vous pouvez (comme suggéré par d'autres) passer du temps à remanier le gâchis et devoir tout recommencer la prochaine fois que vous prendrez un congé. Vous devrez peut-être perfectionner les membres de votre équipe, mais je pense que vous devez d'abord corriger la dynamique de l'équipe, car ils semblent avoir suffisamment de compétences pour faire le travail, peu importe à quel point vous pensez que c'est laid.

Paire.

Ce que vous décrivez, c'est beaucoup de le faire correctement, techniquement, en solo . Oui, vous avez essayé de documenter, essayé d'imposer des normes - mais vous (apparemment) n'avez pas réussi à communiquer.

Eh bien, votre équipe vient de vous communiquer, de façon plutôt retentissante. Ils ont dit: "Hé, Yippie - tu ne communiques pas!" La forme de communication la plus puissante que je connaisse est le jumelage. Paire. Jusqu'à ce qu'ils l'obtiennent ou jusqu'à ce qu'ils vous persuadent de le faire différemment.

Comme Brooks nous le disait depuis une trentaine d'années, l'intégrité conceptuelle est la partie la plus importante de tout projet. Pour tout sous-système non trivial et complet, il devrait y avoir exactement une personne, responsable de sa conception et habilitée à diriger sa mise en œuvre. Quelque chose s'est mal passé avec cette partie de votre projet. Quoi qu'il en soit, la seule solution est de revenir au code dans le référentiel qui existait avant que cela ne se produise. Une perte de 12 jours n'est rien comparé aux dépenses d'entretien d'un design cassé. Je penserais également aux moyens de soustraire les personnes impliquées dans ce projet à d'autres travaux sur le projet, car elles se sont révélées incompétentes.

Une chose que je ferais pour commencer est d'obtenir un bon outil de révision de code, en l'utilisant pour marquer le mauvais code et documenter pourquoi il est mauvais et (conceptuellement) comment il devrait être fait. Maintenant, pour ce que j'ai compris, il y a beaucoup de mauvaises choses faites et donc ce serait beaucoup de travail à revoir; en supposant que vous êtes le seul à voir quelque chose de mal avec le code, il peut ne pas être possible de tout revoir vous-même. Mais vous pouvez marquer les pires infractions et les transformer en entrées dans votre système de suivi des problèmes, attribuées à la personne qui a écrit le code correspondant.

La meilleure incitation à écrire du code de qualité est de savoir que si vous ne le faites pas, cela vous hantera à l'avenir. Vos collègues ne semblent pas s'en soucier, alors le meilleur remède est de leur faire refactoriser eux-mêmes les mauvaises pièces et d'apprendre.

Avec le temps, vous pouvez revoir les autres parties du code qui posent problème et à nouveau réaffecter au (mauvais) auteur d'origine. Après un certain temps, ils se rendront compte des avantages de faire du bon travail la première fois.

Je suppose que vous ne considérez pas une restauration de votre version d'origine comme une option - en d'autres termes, malgré le mauvais code que vos collègues ont écrit, ils ont ajouté des fonctionnalités et la valeur nette de la version actuelle est supérieure à celle d'origine. Je suppose également que même si ce n'est pas le cas, vous n'avez pas de capital politique pour faire cette restauration et leur faire réécrire le code (car très peu de personnes sur la planète ont un tel capital). Telles et bien d'autres sont les complexités de juger une situation que je ne vis pas moi-même, mais j'espère que mes deux cents ont aidé.

Une chose que je n'ai pas vue mentionnée mais qui est apparue récemment où je travaille sont les problèmes des "silos de développeurs" et des "achats".

Au début de mon projet actuel, j'ai fini par concevoir une bibliothèque de base par moi-même. (Tout comme vous l'avez fait jusqu'à la rév. 40). Ensuite, quand je l'ai fait, j'ai présenté au reste de l'équipe et dit à tout le monde qu'ils pouvaient commencer à l'utiliser. Ce qui s'est passé au cours des mois suivants, c'est que les gens ont continué à mettre en œuvre les mêmes choses qui étaient déjà dans cette bibliothèque à d'autres endroits. Le CTO (qui code activement) souligne qu'il n'y a jamais eu d'adhésion du reste de l'équipe sur l'architecture / la conception / les interfaces publiques de la bibliothèque.

Eh bien, nous venons de passer par une réécriture majeure de cette bibliothèque qui a sans doute amélioré la conception globale pour mieux s'adapter à ce que nous faisons actuellement, mais encore une fois, un développeur a pris la bibliothèque comme leur seul projet, y a travaillé pendant plusieurs semaines et puis vient de le présenter. "Voila! Le voici! N'est-ce pas joli?"

Maintenant que je dois utiliser la nouvelle version et le même problème est là - je déteste la façon dont il l'a fait. Et il a omis ce qui était nécessaire parce qu'il n'a collaboré avec personne d'autre pendant qu'il y travaillait. Encore une fois, je commence à implémenter les mêmes choses dans d'autres endroits et à travailler pour ce que je dois faire.

Pour faire court - Si vous voulez que la qualité du code augmente et soit cohérente, je vous suggère de rassembler toute l'équipe pour établir des normes, des styles, etc. En outre, chaque fois que quelqu'un va construire une pièce fondamentale ou fondamentale de votre application, je suggérerais que la personne responsable dirige toute l'équipe dans la conception des cours, etc. afin qu'en fin de compte, toute l'équipe doive adhérer à l'architecture globale de l'application. De plus, s'ils savent comment fonctionne le code des autres membres de l'équipe, ils seront moins susceptibles de le réimplémenter d'une manière qui fonctionne pour eux.

Êtes-vous le développeur principal (ou l'un des développeurs principaux) de cette équipe? Si c'est le cas, il semble que vous deviez organiser des séminaires de formation sur les meilleures pratiques. Vous devriez probablement revenir sur une grande partie du travail effectué, tenir une réunion avec votre équipe et expliquer la bonne façon de mettre en œuvre les fonctionnalités requises de manière à maintenir la conception existante.

Étant donné que vous êtes confronté à un délai serré, vous devrez peut-être expédier le code tel quel et refactoriser (réécrire?) Après votre publication.

Il semble également que vous deviez définir et appliquer certaines pratiques de code courantes. Avez-vous un processus de révision de code en place dans votre travail? Si ce n'est pas le cas, il semble que le moment soit venu d'en implémenter un. Les révisions de code sont d'ailleurs un excellent moyen d'enseigner les meilleures pratiques aux nouveaux développeurs.

ÉDITER:

J'ai rencontré récemment une situation similaire. La direction de mon entreprise a insisté pour que nous utilisions des développeurs de contrats pour écrire une grande partie de notre application. Le code qu'ils ont produit était horrible (pour le dire gentiment), mais nous avons été obligés de l'utiliser. À ce jour, j'ai réécrit 80% du code que les entrepreneurs ont écrit pour nous. Il était plein de bugs et impossible à étendre avec de nouvelles fonctionnalités. Dans quelques mois, mon équipe aura tout réécrit, rendant ainsi l'argent investi dans le développement des contrats un gaspillage.

Un mauvais code coûte vraiment de l'argent, c'est quelque chose dont vous voudrez peut-être parler à vos gestionnaires, car vous aurez probablement besoin de leur aide pour implémenter et appliquer des normes de codage.

Vous avez fait un effort, mais le fait est que personne n'est responsable . "Mais je préfère mon style de codage", pas de merde. J'aimerais travailler sur mes projets personnels toute la journée et être toujours payé.

J'espère que vous pourrez présenter cela aux pouvoirs en place et leur montrer ce qui aurait pu être fait en opposition au Wild West Show qui a duré deux semaines. On dirait que vous allez devoir sortir quelque chose, mais continuez de suivre le problème du manque de contrôles et de cohérence.

Concentrez-vous sur les quelques-uns qui ont accompagné votre plan et faites tout ce que vous pouvez pour les aider à réparer ce gâchis et à les intégrer à votre équipe dans les projets futurs. Vous devrez peut-être simplement rejeter le reste s'ils ne peuvent pas le faire.