La situation normale ici serait que vous travailliez avec vos collègues et la direction pour faire valoir les avantages de la réécrire, faire participer vos collègues, fournir de la documentation, fournir des estimations de temps, répartir le travail et attaquer. De cette façon, vous obtenez l'approbation des responsables d'abord , discutez de divers problèmes en équipe et élaborez un plan pour les résoudre. Les collègues seront alors beaucoup plus susceptibles de participer au projet dans son ensemble, car ils ont eu leur mot à dire pour le faire avancer. Si des collègues vraiment ne veulent pas le faire à ce stade, alors il y a peu de débat à avoir, car a) ils ont eu amplement l'occasion de peser sur le processus et b) il a été approuvé par la direction en tant que projet convenu, donc votre position est claire.

Cependant, dans ce cas, il semble que vous venez de l'avoir fait seul (ou du moins en a fait la majeure partie), potentiellement aliéner un autre développeur qui comprend parfaitement l'ancien système, mais qui n'est pas nécessairement familier avec les nouvelles bibliothèques, outils, technologies, paradigmes de code et pratiques de développement que vous utilisez. Oui, il y a un bon argument pour dire qu'il aurait dû se perfectionner et rester avec son temps, mais dans la pratique, cela n'arrivera souvent pas.

Vous dites alors:

Tout ingénieur logiciel compétent regarderait le code et se rangerait immédiatement à mes côtés

... et me pardonnerait de le dire, mais cela semble plutôt ... Ces choses sont rarement aussi noires et blanches.

Cette partie en particulier me rend nerveux:

En portant une partie du code, j'ai trouvé beaucoup de bogues que j'ai corrigés en cours de route, cela aurait dû être évité mais ne pouvait pas l'être car il n'y a aucun moyen d'écrire des tests pour l'ancien code, ni de gestion / journalisation des erreurs appropriée. Tous les signes indiquent que le mouvement est une bonne idée.

S'il n'y a pas de gestion correcte des erreurs, pas de tests unitaires, etc. dans l'ancien code, alors comment pouvez-vous vérifier qu'il se comporte de la même manière? Comment pouvez-vous vérifier que les «bogues» que vous avez corrigés n'étaient pas réellement des cas secondaires et que personne ne comptait sur ce comportement? Comment pouvez-vous garantir absolument que vous n'apporterez pas de changements critiques et de rupture avec le nouveau code? La direction et les clients ne se soucient pas vraiment de la qualité du code, ils se soucient qu'il fonctionne. Si cela signifie que le déploiement prend plus de temps, mais que les clients sont satisfaits et ne partent pas, alors c'est un compromis intéressant en ce qui les concerne.

Pour répondre à la question directement ici, vous mettez la direction sur board en démontrant le gain de temps et en produisant la documentation et les ressources nécessaires pour habiliter l'autre développeur et le faire participer. Ce n'est pas rapide cependant - c'est long & dur. En réalité, à mon humble avis, vous auriez dû aborder la situation très différemment pour commencer.

Vous avez ici quelques problèmes liés à votre manque de compétences en communication. Je ne sais pas à quel point votre code est bon ou à quel point l'ancien code est mauvais, mais regardons ce que vous avez écrit ici.

1. Ne dépréciez pas les autres et ne venez pas d'un lieu d'arrogance

Ce que je dois faire, c'est expliquer que j'ai beaucoup plus d'expérience et que j'ai fait ce genre de travail dans le passé avec des résultats stellaires.

Arrêtez de regarder des choses comme celle-ci. Les appels à une autorité comme celui-ci ne gagneront personne. Il ne parle pas de la valeur de votre code, il ne met en évidence aucun avantage, il dit littéralement simplement "Je pense que je suis le meilleur dans ce domaine donc nous le faisons à ma façon". Tout cela fera chier vos coéquipiers. Pas ce que vous voulez quand vous n'avez pas leur adhésion.

2. Maîtrisez le jargon technique

Je suis également en train de m'embourber à devoir écrire beaucoup de «documentation» expliquant pourquoi cette nouvelle architecture est meilleure, mais c'est entièrement technique (en parlant de SOLID, tests unitaires, injection de dépendances, etc.) donc ça ne sert à rien car la direction ne le comprendra pas.

Il semble que votre autre coéquipier ne le comprend pas non plus, alors changez un peu la langue . Vous avez besoin de ce document non seulement pour obtenir l'adhésion de la direction, mais également celle de vos coéquipiers. Vous parlez beaucoup de choses comme SOLID mais votre non-programmeur moyen (ou même les programmeurs plus âgés) ne saura pas ce que c'est, alors utilisez le terme, expliquez ce que c'est et expliquez les avantages du framework. Ensuite, utilisez-le avec parcimonie. Faites cela avec toute la terminologie technique. Vous avez besoin de cette documentation pour l'adhésion de votre responsable

3. Ajoutez un point de vue de la gestion

Je suis un architecte logiciel accompli et c'était un jeu d'enfant. Le nouveau code est entièrement testable unitaire avec l'injection de dépendances et une journalisation complète, de sorte que tous les bogues et problèmes sont très faciles à localiser.

Des trucs comme ça sont bons. D'un point de vue technique. Ce que vous devez faire maintenant, c'est traduire cela en discours de gestion, qui consiste simplement à suivre les choses jusqu'à leur conclusion logique concernant les coûts et les retours . Ces coûts peuvent se résumer en argent ou en temps de travail (car ils vous paient pour votre temps) Par exemple:

"Je suis un architecte logiciel accompli et c'était un jeu d'enfant. Le nouveau code est entièrement unitaire testable avec l'injection de dépendances et la journalisation complète, de sorte que tous les bogues et problèmes sont très faciles à localiser, réduisant considérablement le nombre d'heures de travail nécessaires pour la correction des bogues et les travaux de maintenance, et donc réduisant les coûts impliqués dans ces à la fois, il est beaucoup plus facile pour les développeurs de trouver le code problématique et en détectant les problèmes avec le nouveau code dans les versions plus récentes avant qu'ils n'atteignent la prochaine étape du cycle de développement. "

Un certain nombre d'autres réponses ici donnent également de grandes pierres précieuses pour des exemples de cela. Travaillez-les là où vous pouvez et n'ayez pas peur d'en trouver d'autres.

4. Répondez aux préoccupations de votre coéquipier

Maintenant, abordons l'argument de votre coéquipier pour conserver le code d'origine: "Ça marche". D'accord, peut-être que cela ne fonctionne pas toujours , mais on s'y fie depuis quelques années maintenant. Vous pouvez proposer à la direction de faire fonctionner un système de test avec votre implémentation en même temps qu'un autre système exécutant le code d'origine. Peut-être même déclencher quelques cas de test, y compris certains dont vous vous attendez à casser le code d'origine. De cette façon, votre coéquipier n'a plus cet argument car vous avez prouvé à tout le monde que votre code aussi fonctionne, et même fonctionne mieux.

5 . Aborder les facteurs non mentionnés (mais toujours importants)

Ajoutons un autre argument que le coéquipier pourrait utiliser: «Nous connaissons tous le code original». C'est un peu plus difficile à abattre parce que c'est sans équivoque vrai, cela a un impact sur les coûts que la direction comprend et rien de ce que vous pouvez faire dans votre code ne peut complètement atténuer cela. Votre meilleure atténuation se trouve dans votre documentation , les mêmes éléments dans lesquels vous dites que vous vous enlisez.

Par conséquent, votre documentation doit atteindre deux objectifs:

1) Persuader la gestion des avantages de votre idée (j'en ai parlé plus tôt)

2) obtenir vos coéquipiers à jour (ou du moins autant que possible sans essai par tir) sur votre code.

Ce n'est que lorsque vous avez abordé ces 5 points que vous pouvez contourner le problème suivant:

Le problème est que la direction nous regarde tous les deux et ne sait pas qui croire.

Les clients et la direction ne se soucient pas de savoir si quelque chose est bien codé. Ils se soucient de savoir si cela fonctionne à un degré acceptable, ils se soucient de son coût et ils se soucient de savoir s'ils l'obtiennent à temps.

La meilleure façon de justifier vos décisions est de l'expliquer en termes d'homme heures et coûts.

Les mesures de gain de temps devraient parler d'elles-mêmes. Si vos modifications économisent par exemple 2 heures-homme par jour, cela représente 10 heures-homme par semaine ou 500 par an. En supposant un chiffre complètement arbitraire de 25 € par heure-homme de coûts de main-d'œuvre, cela représente 12500 € d'économies par an, ce qui peut être consacré à des tâches plus productives.

Si vos modifications signifient une réduction du temps passé à corriger défauts, c'est plus de temps que vous passez à créer de la valeur pour l'entreprise en termes de nouvelles fonctionnalités que les clients peuvent payer. Les clients ne paient pas pour les corrections de bogues, ils paient pour les fonctionnalités. Moins votre équipe passe de temps à corriger les bugs, moins l'entreprise gaspille d'argent, plus l'équipe gagne d'argent pour l'entreprise.

J'ai été dans une situation similaire à la vôtre plus d'une fois. Ce que vous semblez manquer, c'est dans un code si ancien et désordonné, il est vraiment difficile de dire ce qu'est un bogue et de quelles fonctionnalités les gens dépendent. Il est également très difficile de voir les cas de coin importants qui ont été corrigés. Votre "fauteur de troubles" est celui qui détient la plupart de ces connaissances.

Il est un peu tard maintenant, mais la meilleure chose à faire aurait été de l'impliquer dans les cas de test dès le début, et de demander lui à propos de chaque petite chose qui semble être un bug pour vous, et de chaque condition aux limites. Si vous aviez fait cela, il serait beaucoup plus convaincu que vous comprenez réellement ces choses. La connaissance des «dernières techniques» n'est pas plus importante que la connaissance du domaine. Vous avez besoin des deux pour écrire un logiciel robuste.

Vous n'avez aucun moyen de vérifier que le système se comporte comme l'ancien. L'écriture de tests qui s'exécutent sur l'ancien système est plus lente, mais vous permet d'être plus intentionnel sur le comportement que vous choisissez de préserver et la compatibilité descendante que vous choisissez de rompre.

Alors, impliquez-le dans ces choses maintenant, pour dans la mesure du possible. Plus vous obtiendrez d'informations de sa part, meilleur sera le résultat et meilleur sera votre allié.

Montrez, ne dites pas

C'est axiomatique pour l'écriture, mais en toute honnêteté, c'est aussi axiomatique pour le lieu de travail. Ne parlez pas [des théories] des améliorations que vous apportez, montrez comment ces améliorations sont [implémentées]. Le jargon est un excellent moyen de raccourcir une description autrement verbeuse de ce qu'est une structure particulière lorsque vous parlez à un autre expert du domaine, étant donné la présomption que d'autres experts du domaine comprennent ce que cela signifie, mais le jargon est aussi souvent quelque chose que les gens qui eux-mêmes ne font pas. vraiment comprendre de quoi ils parlent se cacher. C'est aussi un danger lorsqu'on parle à quelqu'un qui ne «parle» pas le même jargon, car il peut paraître prétentieusement ou intentionnellement obscurcissant, voire même comme une incapacité à comprendre les besoins du projet dans son ensemble (en particulier en ce qui concerne objectifs commerciaux plus larges) par rapport au point de vue d'un seul membre sur ce qui n'est en fait qu'un ensemble d'outils possibles pour travailler sur ce projet.

Si vous avez apporté des améliorations réelles et déterministes, alors elles sont également mesurable .

Cela va au-delà du simple développement logiciel, et c'est quelque chose sur lequel vous devriez toujours vous concentrer lorsque vous réalisez des projets sur le lieu de travail.

Lorsque vous présentez un projet, c'est bien de discuter de choses qui sont conceptuelles ou de projections basées sur ces concepts (mais vous devriez idéalement avoir des données de point de départ pour montrer pourquoi le statu quo pourrait être un problème qui doit être résolu, au lieu de simplement proposer des solutions à quelque chose qui n'est pas clairement un problème).

Lors de la défense d'un projet ct, vous voulez être en mesure de montrer qu'il y a des améliorations réelles qui sont ou ont été réalisées. Il s’agit du langage au niveau méta du projet / de l’entreprise lui-même, plutôt que de simples discours spécifiques à un outil technique qui ne parviennent pas à transmettre globalement l’importation des pratiques employées et des choix effectués.

Idéalement, vous avez des données, et les données les plus solides sont longitudinales avec comme par rapport à comme (aussi bien que possible)

La façon dont vous voulez aborder cela si vous aviez des données précédant vos modifications est dépend de vous. Idéalement, vous compareriez quelque chose qui maintient les choses en grande partie équitables et ne sera pas dû aux caprices du hasard.

En même temps, lorsque nous discutons des défauts, les défauts ne sont généralement pas touchés en quelque sorte de façon fiable et répétable, et tous les défauts ne sont pas égaux, donc ce sera toujours un problème lors de la comparaison entre avant et après.

Pour quelque chose comme ça, voici quelques éléments qui peuvent être utilisés mais doit avoir une certaine attention au fait que sans une période de temps suffisamment longue pour la signification statistique (et un moyen de déterminer ce qui constitue cela dans ce cas), vous jouez peu à peu avec des nombres:

• Délai entre le rapport initial du problème et la recherche de l'emplacement du problème dans le code source
• Délai entre la recherche du lieu du problème et la résolution du problème
• Temps moyen pour résoudre le bogue signalé
• Nombre moyen de bogues enregistrés par fenêtre de temps raisonnablement cadrée [semaine / mois / trimestre]
• Nombre moyen d'heures consacrées aux développeurs par raisonab fenêtre de temps encadrée pour travailler sur les bogues

Vous n’avez peut-être pas accès à tout cela, mais votre responsable ou le chef de projet peut le faire.

Parce que ce n’est pas Il n'y a pas quelque chose où les données vont être cohérentes, une autre approche que vous pouvez adopter est de trouver des incidents individuels comparables avant et après les améliorations (modalités de faute très similaires / etc.) et de créer des comparaisons d'études de cas. Suivez le processus de correction dans chaque cas, le temps nécessaire à chaque étape, etc.

Des actions similaires peuvent également être effectuées pour les modifications liées aux améliorations des fonctionnalités, si votre réarchitecture a réussi. Gardez à l'esprit que vous voudrez mettre en valeur les aspects qui réduisent les pannes à l'avance et donc un gain de temps à long terme. Si possible, montrez le nombre de pannes survenues lors d'un ajout de fonctionnalité antérieur ou d'un changement similaire, les coûts de temps moyens associés, puis montrez comment les coûts initiaux peut-être plus élevés de la nouvelle méthodologie sont rentables au fil du temps. Ne parlez pas seulement des théories associées. Montrez-les comme appliqués dans leur contexte.

Soulevez, ne poussez pas vers le bas

Je ne vais pas faire d'hypothèses sur la façon dont vous avez été communiquer avec les autres à ce sujet, mais il est assez clair que vous avez réussi à marcher sur au moins un ensemble d'orteils. Il ne s’agit pas de fautes , mais de trouver des moyens positifs d’aller de l’avant ou au moins d’atténuer la situation.

C'est peut-être le véritable problème sous-jacent que vous rencontrez actuellement va être confronté.

Il est facile de trouver des situations comme celle-ci extrêmement irritantes et stressantes. Bien que ce ne soit pas nécessairement juste, la meilleure façon de se démarquer est généralement de rester calme et de ne parler que de points positifs tournés vers l'avenir plutôt que de mauvaises paroles, en particulier en ce qui concerne les travaux précédents. Ne dénigrez pas le travail précédent, ne le dites pas comme étant obsolète, juste parlez des effets démontrables de vos améliorations.

Parfois, vous vous ferez des ennemis de faire du bon travail, et vous ne pouvez pas contrôler cela. Ce que vous pouvez faire, c'est essayer de sortir comme si vous l'aviez géré calmement et mûrement et que vous étiez le seul à tendre la main et à essayer de vous relever plutôt que celui qui se tenait là en train de faire un crétin.

La meilleure approche, dans la mesure du possible, consiste à recruter à l'avance des personnes susceptibles de créer des problèmes à vos côtés. Une fois que les choses ont commencé à se dégrader, cela devient délicat, voire impossible: le moment idéal est à l'avance. Montrez-leur , individuellement et de leur point de vue, comment cela va à la fois leur faciliter la vie et non leur rendre la vie plus difficile (encore une fois, faites attention au jargon, même si vous parlez à quelqu'un d'autre dans votre profession à ce sujet) et, espérons-le, impliquer certaines choses qu'ils pourraient même trouver passionnantes. Cela nécessite de les comprendre dans une certaine mesure. Découvrez quelles sont leurs préoccupations en réalité (en dehors d'un cadre de groupe) et atténuez-les et montrez en quoi cela constituera une amélioration pour eux , pas seulement pour l'entreprise / le projet .

Idéalement, il ne s'agit pas seulement de vous-même, c'est le genre de chose où, d'un point de vue éthique, nous souhaitons tous que tout le monde autour de nous ait une bonne expérience de travail et soit heureux.

Notez que ce n'est pas toujours possible. Mais au moins dans le cadre d'un groupe, la façon dont vous vous comportez est quelque chose sur laquelle vous avez un minimum de contrôle, c'est donc le moment de ne pas parler à quelqu'un d'autre, de ne pas dénigrer le travail de quelqu'un d'autre (ou ses préoccupations, sa perspective ou ses plaintes réelles), et concentrez-vous simplement sur vos points positifs.

Si quelqu'un fait part de ses préoccupations, utilisez-les comme point de repère pour savoir en quoi c'était "un excellent point à soulever", car vous souhaitez expliquer en quoi cela constituera une amélioration dans le contexte de ces préoccupations.

/ strong> Ne rejetez pas vos inquiétudes. N'invalidez pas l'acte d'avoir des inquiétudes. Trouvez un angle positif et prospectif. Ne vous enlisez pas dans les détails si les choses déraillent trop, il est normal de dire que vous seriez heureux d'entrer plus en détail séparément en ce qui concerne une préoccupation donnée, mais pour l'instant, vous voulez le rassurer en termes de les aspects plus larges de cette préoccupation, les choses sont bien traitées. Planifiez une réunion connexe, sur place si nécessaire. Reportez tout déraillement connexe à cette réunion. Vous devrez probablement vous assurer que la personne qui supervise à la fois vous et cette autre personne acceptera cela à l'avance (et vous ne voudrez certainement pas faire quoi que ce soit de tel sans sa présence).

Le logiciel ne se produit pas sans personnes. Le logiciel n'est utile que dans la façon dont il sert d'outil aux gens. Il en va de même pour les travaux de développement. Oui, cela implique de dire à l'ordinateur ce qu'il doit faire. Mais c'est aussi une question de travail d'équipe et de communication. Je dirais que le plus important concerne le travail d’équipe et la communication .

La plupart des principes de développement logiciel que vous évoquez concernent, à la base, vraiment la création de cadres cohérents au service du travail d'équipe, de la communication (même lorsque vous travaillez individuellement, c'est vrai, car il s'agit de communiquer avec votre futur moi) et les réalités fondamentales de la faillibilité humaine. Vous avez eu un manque de communication avec les membres de votre équipe et cette friction en est le résultat. Il est facile de rejeter la «politique sur le lieu de travail» comme quelque chose que les gens «ne devraient pas avoir à gérer pour faire avancer les choses», mais ce que cela signifie vraiment, c'est que nous devons communiquer les uns avec les autres pour avancer en équipe. Idéalement, c'est le rôle de quelqu'un qui gère l'équipe. Mais la réalité est que si vous voulez être quelqu'un qui fait avancer les choses et apporte des changements positifs significatifs, vous devez également gérer les attentes et la communication avec vos collègues. Vous pouvez obtenir votre manager de votre côté à ce sujet, mais vous ne pouvez pas simplement vous enterrer la tête dans le sable à la nécessité et faire semblant de pouvoir gérer tout seul.

Il est facile de transporter le prétendre que des principes tels que SOLID, TDD, etc. sont quelque chose qu'un individu peut simplement abandonner et mettre en œuvre via des changements radicaux sur un projet mal codé, mais en réalité, cela peut effectivement être contraire aux objectifs sous-jacents de SOLID et des principes similaires et les théories de l'architecture logicielle. Tout comme le meilleur algorithme implémenté par logiciel est rendu effectivement inutile si aucune personne qui en a besoin ne peut réellement utiliser le logiciel associé, le logiciel le mieux conçu est inutile en termes de ces aspects architecturaux si l'équipe qui y travaille ne peut plus le faire efficacement ( cela coupe certes certains autres angles connexes aux fins de cette discussion).

Parfois, cela indique la nécessité d'un changement de personnel, mais à moins que vous ne soyez en mesure de prendre des décisions connexes, il est important de se rappeler que ce n'est pas vraiment votre choix ou votre position. Aller de l'avant par vous-même, en particulier si un calendrier différent avait été élaboré et accepté, pourrait même être le pire mouvement possible, et vous pourriez créer un pire désordre pour vous-même que celui qui est juste dans votre visage, parce que d'autres personnes ont peut-être eu des plans pour gérer la situation et maintenant, à la place, elle a explosé. Le but de la plupart des principes modernes du génie logiciel est d'arrêter de prétendre que le code est écrit dans un vide parfait, alors rappelez-vous, il s'agit vraiment d'être réaliste à propos des personnes impliquées . Cela inclut le reste de l'équipe.

Je doute que vous fassiez des gains à ce sujet, il est très difficile de justifier de réécrire quoi que ce soit à la direction sans fournir de nouvelles fonctionnalités, ce sont de nouvelles choses brillantes à jouer avec ce souci de gestion, plus la nouvelle interface est impliquée, mieux c'est. Je viens de transformer un dinosaure à filetage unique en un chef-d'œuvre multithread et personne n'en a rien foutu car il n'y avait rien de nouveau sur lequel ils pouvaient cliquer sur l'écran

Coach The Veteran

D'autres réponses ont donné de bons conseils sur la gestion du code hérité et de la gestion. Je veux me concentrer sur ce que je pense être votre problème principal: traiter avec le développeur d'origine. Vous n'êtes donc pas d'accord sur beaucoup de choses. Si vous voulez qu'il arrête de vous miner, vous devez le faire entrer dans votre équipe. Ce qui signifie que vous avez besoin de lui pour voir le monde comme vous le faites. Et la façon de le faire est de commencer par comprendre à quoi ressemble son monde, avec beaucoup de détails.

Lisez le code hérité et essayez de distiller les modèles et règles implicites avec lesquelles vous n'êtes pas d'accord. Prenez-en note, car c'est là que vous voulez être sur la même longueur d'onde. Ensuite, réfléchissez aux raisons pour lesquelles vous n'êtes pas d'accord avec eux. Ne vous concentrez pas sur les raisons pour lesquelles le modèle hérité est mauvais . Concentrez-vous sur les raisons pour lesquelles votre modèle de remplacement est meilleur , mais reconnaissez également le théorème fondamental de l'ingénierie: tout est un compromis . Même votre «meilleur» modèle a une faiblesse dans certaines conditions. Vous devez être capable d'identifier et de comprendre ces modes de défaillance pour faire valoir avec succès qu'ils sont les moins pertinents par rapport aux scénarios en question. Une fois que vous avez terminé ce travail de préparation, vous êtes prêt pour l'étape suivante.

Programmation par paires

Dites à votre copain que vous êtes parti du mauvais pied, que vous êtes désolé d'être un âne arrogant et condescendant et que vous voulez juste savoir comment être sur la même longueur d'onde. Choisissez un code qui incarne les anti-modèles que vous avez identifiés ci-dessus, et regardez côte à côte l'ancienne et votre version "améliorée". Demandez au développeur de critiquer les deux et donnez-lui suffisamment de temps et d'espace pour le faire. Cherchez des occasions de être d’accord avec lui, plutôt que d’être en désaccord. Vous essayez de construire des ponts à ce stade. Le désaccord est déjà implicite. Après avoir fait ses observations, posez des questions suggestives pour illustrer pourquoi vous pensez que votre version est meilleure. En particulier, évoquez des scénarios d'exécution de code où votre code est évidemment supérieur. Dans le meilleur des cas, ayez en main des cas de test (unité ou acceptation) qui illustrent la supériorité de votre version, et demandez-lui simplement de les revoir.

Votre objectif n'est pas pour attraper le gars dans un piège, mais pour l'aider à voir le monde de votre point de vue. Et cela ne fonctionnera que si vous validez d'abord sa perspective à un certain niveau. En particulier, vous devez être extrêmement sensible à l ' histoire . Beaucoup de choses que nous considérons comme «mauvaises» aujourd'hui étaient courantes, ou acceptées, voire bonnes il y a des décennies, parce que la technologie était différente, les connaissances étaient différentes, le matériel était différent. Essayez de dire à Grace Hopper que "GOTO est considéré comme dangereux". Elle rétorquait: "Jeune homme, j'aimerais vous voir écrire un programme d'assemblage sans aucune instruction JMP. Revenez quand vous aurez terminé."

Cela signifie que vous pouvez et devez comprendre l'architecture du système dans le contexte de sa création . Même s'il ne s'agissait pas d'une technologie de pointe à l'époque, il se peut qu'elle ait été construite sur des modèles relativement matures qui ont ensuite été remplacés. Vous obtiendrez un long chemin en démontrant une certaine conscience et respect pour cette histoire de développement. Tout cela pour dire la chose la plus importante que vous devez apprendre: "Le code n'est pas bon ou mauvais . Il est bon ou mauvais par rapport à un contexte . " Il est fort possible que si vous étiez présent lorsque le code a été écrit à l'origine, vous l'ayez écrit de la même manière. Il y a à peine dix ans, je discutais avec toute mon équipe d'une grande entreprise de technologie du Fortune 100 au sujet de la vertu des tests unitaires. Il n'y a aucun moyen que j'aie cette conversation aujourd'hui. Beaucoup de choses changent avec le temps.

Demandez de l'aide

Si votre copain est particulièrement intransigeant, choisissez simplement un bogue à corriger dans une partie du code que vous n'avez pas refactorisé. Demandez-lui de regarder avec vous là-dessus. Dites: "Je n'ai pas le contexte pour déboguer ce code efficacement. Pouvez-vous me montrer votre approche à ce sujet?" Laissez-le vous guider dans son processus. Quand il fait quelque chose qui invoque la connaissance tribale, faites-lui une pause et dites: "Oh, est-ce que quelqu'un d'autre le sait?" "Bien sûr que non." "Ok, parce que je ne l'aurais pas deviné juste en regardant le code. Pouvons-nous prendre un moment pour documenter cela?" Après un certain temps, la prise de main lui grincera les nerfs, et il verra que simplement parce qu'il est facile pour lui de naviguer dans le code, cela peut être compliqué et frustrant pour quiconque de le faire. Si vous voulez vraiment faire ressortir le problème, demandez-lui de voir le développeur junior pendant que vous regardez par-dessus l'épaule de tout le monde. Encadrez le développeur junior à utiliser la même approche de questionnement plutôt que de défi que vous.

Si vous avez de la chance, il sera frustré et dira quelque chose comme: "D'accord, si vous êtes si intelligent, comment feriez-vous?" Puis dites: "Eh bien, nous avons un rapport de bogue qui montre qu'il y a un bogue quelque part dans un code que j'ai refactoré. Jetons un coup d'œil à cela." Ensuite, laissez-le naviguer dans votre nouveau code et interrogez / défiez-le. Utilisez les tests unitaires que vous avez rédigés pour isoler le bogue et laissez le développeur junior conduire une partie du temps pour illustrer qu'il ne s'agit pas seulement de lui ou de vous, mais de toute l'équipe.

Idéalement, si vous vous êtes concentré sur l'empathie et la qualité, plutôt que sur le jugement et la cruauté, alors vous l'aiderez à voir que vous avez réellement apporté des améliorations précieuses, plutôt que de vous contenter du système qu'il a construit pendant une décennie. Au lieu d'insister sur le fait que vous êtes l'architecte omniscient qui apportera la bonté et la lumière à tout le code, recommencez avec une bonne dose d'humilité et laissez votre code parler de lui-même. S'il est un codeur raisonnable, il devra finalement reconnaître qu'un meilleur code est un meilleur code avec lequel même lui préférerait travailler. Et si vous ne pouvez pas l'amener à ce point, cela peut bien avoir plus à voir avec votre attitude que la sienne. Gardez cela à l'esprit et bonne chance.

TL; DR: si vous n'exagérez pas, alors vous ne pouvez rien faire pour ce projet. Mais vous pouvez essayer de l'appeler un nouveau projet et l'exécuter séparément.

J'ai été presque exactement dans votre situation plus d'une fois. Je ne peux pas dire que vous avez raison évidemment car je ne sais pas tout sur votre projet particulier, mais parfois c'est vraiment noir et blanc comme vous le dites, malgré ce que les autres disent.

Pour mon premier employeur dans mon cheminement de carrière, j'ai eu la chance d'avoir aussi des temps d'arrêt. J'ai continué à voir tellement d'erreurs horribles de la part de quelques développeurs que j'ai décidé d'aider. Ils ont refusé, mais personnellement, je faisais partie de ceux qui ont dû faire face aux retombées de leurs déchets lorsque les gens se sont plaints, alors j'ai quand même marché sur leurs orteils.

J'ai fait une meilleure version. J'étais en contact plus direct avec les utilisateurs finaux que le type dont je marchais les orteils, alors je leur ai même fait tester. Ils ont adoré et certains l'ont adopté.

Notre propre responsable du service client (un informaticien qui comprenait les ramifications techniques) a dit qu'il voulait que la version officielle soit remplacée par la mienne, mais les gars qui ont de l'ancienneté en ont pleuré. , ma version a été abandonnée comme un roc ... mais environ un an après avoir changé de travail, le CTO de l'ancien endroit a reçu mon numéro de mon ancien patron et le CTO a personnellement appelé et m'a demandé si je reviendrais sous un contrat temporaire pour soutenir ma version de cet outil! J'étais intéressé, mais il n'aimait pas le prix que j'ai cité (bien moins que ce que je sais qu'ils ont dépensé pour la version indésirable) et il n'a plus jamais rappelé.

Chez mon prochain employeur, j'ai eu la bénédiction de créer une version "allégée" de l'un de leurs produits. En environ 2 mois, j'ai créé une version qui contenait moins de bogues, fonctionnait beaucoup plus rapidement même sur du matériel moins lourd, était plus facile à maintenir et à mettre à jour, avait une meilleure documentation d'architecture et même commencé à devenir plus riche en fonctionnalités que la version originale (et certaines fonctionnalités ils voulaient même être portés vers la version complète) ... jusqu'à ce que quelqu'un dise "Hé, nous devrions simplement remplacer la version complète par celle-ci." Alors bam! Soudain, la version "allégée" a été supprimée. J'ai été remis sur la version complète, avec toutes ses odeurs de code hideuses (c'est un euphémisme: tout était la tourbière de la puanteur éternelle), le manque de documentation, et les bugs et autres.

Le plein La version a en fait beaucoup planté au démarrage, nécessitant parfois 10 tentatives ou plus avant de démarrer correctement, et la réponse à cela était de ne pas appeler le logiciel directement, mais plutôt de créer un script de démarrage pour celui-ci qui a juste essayé dans une boucle infinie pour démarrer pendant plusieurs minutes. Peu importait le gars avec le plus d'ancienneté et son ami dans la direction.

Parfois, vous ne pouvez rien faire.

Si votre collègue est vraiment aussi dense ou têtu que vous le suggérez et vous n'exagérez pas, alors vous devrez peut-être simplement abandonner l'idée d'avoir son soutien. Dans ce cas, vous devez simplement convaincre quiconque peut prendre la décision et en rester là.

Si vous ne parvenez pas à convaincre votre pair ou le manager avec le rôle de prise de décision, alors c'est une cause perdue et il vous suffit de quitter ce projet. J'espère que l'employeur est assez grand pour que vous puissiez changer.

Une autre voie, bien que cela change encore quelque peu les projets, est ...

Vendre votre logiciel comme nouveau produit

Je ne veux pas nécessairement créer votre propre entreprise pour rivaliser avec votre employeur. C'est une option, mais ce que je veux dire, c'est leur vendre l'idée que votre logiciel pourrait être considéré comme "Notre App 2.0" ou l'appeler un logiciel complètement différent.

Microsoft a à la fois Internet Explorer et Edge. Ils ont Notepad mais ils ont aussi Wordpad et Word, chacun meilleur que le précédent.

Vous pouvez vendre votre logiciel comme le concurrent du logiciel de votre pair même si c'est la même entreprise qui le fait. Ensuite, votre pair peut avoir son logiciel tel qu'il est, et si personne ne le veut, alors son projet mourra tout seul.

Présentez le nouveau système

Organisez une présentation technique en grande équipe \ multi-équipes sur le nouveau système. Démonstration du processus de recherche de bogues en utilisant l'ancien système. Puis démo pour trouver un bug avec le nouveau système. Idéalement, utiliser des exemples de problèmes réels que la direction sait légitimes, et non de petits bogues orchestrés.

Voir, c'est croire. Le développeur d'origine aura du mal à défendre l'ancien système, lorsque le nouveau système est vu en action.

Ensuite, donnez des statistiques montrant la quantité de bogues trouvés en utilisant le nouveau système sur X temps.

Ne frappez pas le système précédent et à quel point il est mauvais. Vendez uniquement le nouveau système et à quel point il est bon sans aucune arrogance, ce qui est important. Vous voulez vous faire des amis pour soutenir le nouveau système, pas vous faire des ennemis pour y résister.

Montrez l'heure - demandez les raisons.

Exécutez l'ancien code et le vôtre et montrez combien de temps vous gagnez.
Montrez à quel point l'ancien code équivaudrait à des déchets lors du passage vers le cloud. Montrez que s'il cesse de fonctionner, le temps d'exécution sera nul. S'il cessait de fonctionner, cela se traduirait non seulement par plus de temps / heures de travail pour le réparer, mais aussi arrêterait toute "production".

Faites-leur prendre conscience, au point de le prouver personnellement, qu'un ancien système bogué est beaucoup plus viable à exploiter.

Vous devez essentiellement prouver que le système ne fonctionne pas. C'est juste "courir". Et même un petit caillou l'écrasera.

Le problème est que ce que vous faites, c'est donner l'impression que l'ancien développeur de rockstar a développé quelque chose de terrible. C'est donc une critique directe à lui. Étant donné que vous êtes un architecte aussi accompli, il est plutôt étrange que vous n'ayez jamais rencontré ce comportement auparavant, mais vous devriez vous y habituer. Je suis diplômé et je rencontre fréquemment ce comportement. La solution à cela doit être trouvée par vous-même.

Si vous devez "aider" la direction à savoir "qui croire", suggérez-lui de lire ce fil de discussion.

Mais gardez votre CV à jour. Je suis certain que l'un des les causes de ma mise à pied ont été de réduire de moitié le temps de compilation et la taille de l'exécutable grâce à une approche qu'un collègue «plus expérimenté» avait dit à la direction était impossible lorsque je l'ai recommandé.

L'une des réponses correspondait déjà à ce que je voulais dire, mais je pense que cela vaut la peine de résumer, donc je vais rester bref.

Les managers, en particulier les managers non techniques, aiment les chiffres. Ils aiment les graphiques. Ils ont besoin de chiffres précis qui peuvent justifier leurs décisions. C'est tout ce dont vous avez vraiment besoin pour leur montrer.

Assemblez quelques diapositives montrant (si possible):

  Temps de déploiement nouveau vs ancienFréquence de bogues avec timeTime à corriger bugs 

Les choses de cette nature. Obtenez quelques bonnes statistiques ensemble, gardez-les courtes et épurées, montrez-les à la direction et vous êtes assuré d'avoir leur attention si vos contributions sont aussi percutantes que vous le prétendez. C'est vraiment tout ce que vous devez faire pour convaincre la direction. Le reste des réponses concerne principalement la politique de bureau, que je conseille d'éviter dans les cas où vous pouvez démontrer votre point de vue avec des chiffres / graphiques solides. Ne vous inquiétez pas pour l'autre développeur, une fois que vous avez convaincu la direction, il lui incombe de se remettre de lui-même ou de trouver un autre emploi.

Désolé pour une réponse aussi concise, mais voici une chose simple et importante que j'ai apprise de mon expérience passée et que j'ai peur que vous manquiez:

La cohérence est importante