Quel est le / Y a-t-il une bonne façon de dire à la direction que notre code est nul?


70

Notre code est mauvais. Cela n'a peut-être pas toujours été considéré comme mauvais, mais c'est mauvais et ne fait que descendre. Il y a moins d'un an, j'ai commencé mes études tout récemment, et beaucoup de choses dans notre code me surprennent énormément. Au début, je pensais qu'en tant que nouveau gars, je devrais rester bouche bée jusqu'à ce que j'en apprenne un peu plus sur notre base de code, mais j'en ai vu beaucoup savoir que c'est mauvais.

Quelques faits saillants:

  • Nous utilisons toujours des cadres (essayer d'obtenir quelque chose d'une chaîne de requête, presque impossible)
  • VBScript
  • Source Safe
  • Nous «utilisons» .NET - je veux dire par là que nous avons des wrappers .net qui appellent des DLL COM rendant le débogage presque impossible
  • Tout est fondamentalement une fonction géante
  • Le code n'est pas maintenable. Chaque page contient plusieurs fichiers créés chaque fois qu'une nouvelle page est créée. En général, la page principale affiche Response.Write () plusieurs fois pour rendre le code HTML (runat = "serveur"? Aucun moyen). Après cela, il peut y avoir beaucoup de logique côté client (VBScript), et finalement la page se soumet à elle-même (souvent le temps de stocker beaucoup de choses dans des champs cachés) où elle est ensuite postée sur une page de traitement qui peut faire des choses telles que sauvegarder le fichier. données à la base de données.
  • Les spécifications que nous obtenons sont risibles. Souvent, ils appellent des choses comme "remplir automatiquement le champ X avec le champ Y ou le champ Z" sans indiquer quand choisir le champ Y ou le champ Z.

Je suis sûr que certaines de ces difficultés sont dues au fait qu’elles ne sont pas employées par une entreprise de logiciels, mais j’ai le sentiment que les personnes qui écrivent des logiciels devraient au moins se soucier de la qualité de leur code. Je ne peux même pas imaginer que si j'apportais quelque chose, tout serait fait rapidement, car un délai important est imminent, mais nous continuons à écrire du code incorrect et à utiliser de mauvaises pratiques.

Que puis-je faire? Comment puis-je même aborder ces questions? 75% de mon équipe est d'accord avec moi et a soulevé ces problèmes dans le passé, mais rien ne change.


27
s'y habituer. 90% du code écrit est en lecture.

7
rien n'est changé pour la même raison qu'il s'agisse d'un code défectueux. Ils ont cessé de payer booku $$$$ pour permettre à quiconque de s’amuser il y a longtemps.

11
Ceci est hors sujet. Mais la réponse courte est: économie. Combien de mois de développement coûtera-t-il pour ranger le code, et combien de mois de développeur économisera-t-il?
Oliver Charlesworth

89
la meilleure façon est dans une interview de sortie.
Kylben

32
Peu importe la façon dont vous parlez de la couleur aux aveugles. Ils ne vous comprendront pas.
ThomasX

Réponses:


68

Assurez-vous que vous ne réagissez pas de manière excessive. Vous êtes frais, n'avez probablement pas travaillé beaucoup (n'importe lequel) ailleurs, et ne sont donc pas préparés au monde du "code de la vie réelle". Le code de la vie réelle est une chose horrible. C'est comme si ton code à l'école et ton code de projet personnel impeccablement modifié avaient eu des relations sexuelles dans le sous-sol d'un réacteur nucléaire et que le bébé avait grandi dans un égout de déchets toxiques; c'est un mutant hideux.

Mais si vous avez raison et que le code est aussi mauvais que vous le dites (c'est-à-dire pire que le code généralement mauvais), vous avez alors raison de vous inquiéter. Parlez à votre équipe et déterminez si tout le monde est de son côté. Il faudra travailler pour améliorer la situation - si le reste de l'équipe reconnaît le problème mais s'en fiche, vous perdez votre temps.

En tant que junior, vous n'êtes probablement pas en mesure de diriger. Si vous allez vous-même à la direction, en tant que nouvelle recrue qui est également junior, votre opinion sera probablement ignorée. Obtenez votre développeur principal ou l'un des gars les plus âgés impliqués. Encore une fois, si aucune des personnes âgées n'est intéressée, vous perdez votre temps.

En supposant que vous puissiez intéresser des techniciens de haut niveau, je travaillerais à l'identification des problèmes et des solutions possibles. Par exemple, si "tout est fondamentalement une fonction géante", la prochaine fois que vous travaillerez dans cette "fonction géante", vous devrez peut-être un peu refactoriser. Encore une fois, vous devez faire participer tout le monde. Si vous ébranlez de petits morceaux de votre problème et améliorez chaque pièce, ils finiront par devenir beaucoup moins problématiques. Chaque fois que vous touchez un morceau de code, demandez-vous s'il peut être amélioré.

Vous n'allez pas vous asseoir avec la direction et dire «tout est mauvais et doit être réécrit». Cela n’a aucun sens pour eux, c’est très coûteux et potentiellement très risqué. Au lieu de cela, ils devraient être informés qu'il y a des problèmes et qu'il existe un plan pour s'améliorer lentement au fil des changements. Ils devraient être informés des avantages du code maintenable. Cela devrait venir d'une personne âgée en qui ils ont confiance techniquement et professionnellement - pas de vous.

Réécriture complète? Presque toujours une mauvaise idée.

En fin de compte, vous ne pouvez rien faire parce que vous êtes nouveau. Si personne ne veut améliorer les choses, alors vous rassemblez votre expérience et passez à l'endroit suivant.


10
+1 pour la dernière ligne seule. Les gens ne sont généralement pas disposés à écouter un débutant, même si ce dernier fournit sa propre expérience et une perspective différente selon laquelle tout le monde est trop envahi par la culture d'entreprise. Les gens sont également aveugles à entendre la vérité (c.-à-d. "Tout est mauvais parce que ceux qui l'ont créée sont des idiots qui ne savaient pas qu'ils étaient en train de faire la WTF") et préféreraient descendre avec le navire plutôt que d'admettre que les choses sont mauvaises et qu'elles doivent être fixé. Il est parfois ahurissant de voir les propriétaires d’entreprise risquer de tout perdre au lieu de prendre le temps de réparer les mauvaises choses.
Wayne Molina

2
Pour poursuivre sur ce dernier point, j’ai vu de nombreux endroits où la direction courait le risque de fermer ses portes lorsque le système de mauvaise qualité s’effondrait sur elle-même plutôt que de régler et de régler les problèmes, même si cela signifiait attendre. sur les nouvelles fonctionnalités.
Wayne Molina

5
Malheureusement, le fait de recourir à une sorte de «guérilla» pour reformater peut parfois vous amener à vous tirer une balle dans le pied. À moins que le système ne contienne un bon ensemble de tests unitaires / d'intégration (qui, s'il est mauvais, ne le fera probablement pas), cela entraînera inévitablement l'introduction de bogues qui nécessiteront un test complet du système afin de les éviter.
aceinthehole

1
@aceinthehole: tout à fait. Si les tests coûtent cher, la direction ne voudra pas risquer des modifications «inutiles», même si sans elles, le système deviendrait impossible à maintenir dans un avenir prévisible.
Kevin Cline

2
@WayneM, et les idiots qui ne connaissaient pas WTF au début du projet sont maintenant les cadres supérieurs. Ne jamais oublier cette partie!
HLGEM

58

Lisez Joel On Software - des choses que vous ne devriez jamais faire. Comprenez son raisonnement, puis lisez quelques autres articles sur les mauvais logiciels et sur la façon de les réparer, écrits par des gestionnaires et non des programmeurs. Armés de ces informations, vous serez en mesure de présenter un dossier pour y remédier, dans des termes que les gestionnaires comprennent et tiennent à cœur. Astuce: Les bons gestionnaires ne dépensent pas leur temps et leur argent uniquement en fonction des opinions des programmeurs et de leurs sentiments sur ce qui doit être fait.

"Ce code est de la merde et a besoin d'être réécrit", même si vous êtes techniquement correct, il va certainement vous être renvoyé.

"Nous pouvons réduire de plusieurs mois le calendrier actuel du projet, coûter moins cher et le rendre plus fiable." attirera leur attention (remarquez le manque de mention de la façon dont vous avez l’intention de le faire à ce stade.

Quoi que vous disiez, assurez-vous d'avoir raison. Si vous dites que c'est mauvais, votre réécriture doit être bien foutue. Si vous dites que cela prendra une semaine, vous feriez mieux de vous assurer que ce sera une semaine et soyez bon. Tout défaut dans le code retravaillé vous coûtera, personnellement, très cher, indépendamment de ce qui aurait pu se passer si vous n'aviez pas refait le travail. Si quelqu'un a été là avant vous et a foiré ou survendu une réécriture, abandonnez, les gestionnaires n'aiment pas être ridiculisés et ne le laisseront pas arriver deux fois. Par ce jeton, ne faites pas gaffe aux gars qui suivent, vous n’avez qu’une chance à cela…

Trouvez des moyens de répartir les coûts sur une période ou un nombre de projets. Les gestionnaires détestent les risques, les investissements spéculatifs et les flux de trésorerie négatifs - respectez les tolérances de vos gestionnaires. Commencez par une petite suggestion à faible risque et à faible coût. Une fois que vous avez raison, vous pouvez aller chercher le plus gros poisson.


2
drôle ... je me suis voté vers le bas pour suggérer le site de Joel :-)
Robert Français

6
@Robert French: votre manager lit vos messages ...
Dave Markle

8
Sans blague. Ce n'est pas amusant d'essayer de plaider en faveur de "Puis-je disposer de 6 mois de temps de développement pour tout réécrire? Le résultat final sera exactement ce que nous avons aujourd'hui, mais probablement avec quelques nouveaux bogues. Oh, et nous allons en utiliser beaucoup les mêmes développeurs qui ont créé le tas de merde fumant à la vapeur pour la réécriture, car ils savent mieux maintenant. "
JohnFx

3
@ joshin4colours: <quote> Oui, je sais, c'est une simple fonction d'afficher une fenêtre, mais elle a laissé pousser de petits poils et d'autres choses et personne ne sait pourquoi. Eh bien, je vais vous dire pourquoi: ce sont des corrections de bugs . ... Chacun de ces bugs a nécessité des semaines d'utilisation dans le monde réel avant d'être découvert. ... Lorsque vous jetez le code et recommencez à zéro, vous
Martin York

4
Désolé, mais un an d'expérience n'accorde pas la crédibilité nécessaire pour faire l'une de ces revendications à sa direction.
Jeremy

14

Tout d’abord, vous trouverez des documents obsolètes partout où vous travaillerez en tant que programmeur, à moins que vous ne travailliez pour une start-up et que vous ne créiez le code original maladroit d’origine. Vous devez être capable de rouler avec ces coups si vous envisagez de faire carrière dans la programmation.

Deuxièmement, l'amélioration des anciens systèmes est souvent un facteur de coût. Par exemple, j'ai vu plus d'une entreprise qui utilisait encore des applications VB6 classiques et ASP datant de 10 ans. Dans certains cas, c'était parce qu'un grand projet de déplacement de .NET avait échoué. Dans d'autres cas, la raison était "si ça ne casse pas, ne le répare pas". Mais dans d’autres, le coût du déménagement est justifiable, car les problèmes causés par le système existant sont trop importants pour être ignorés.

Dans les situations où il y a eu un gros échec dans le passé, il est presque impossible de provoquer un changement. Dans ce cas, peaufinez votre CV et commencez à chercher un nouvel emploi. Si ce n'est pas cassé, vous n'aurez probablement pas à vous plaindre du code lui-même, mais vous n'êtes pas sur un cheminement de carrière épanouissant et en croissance. S'il est cassé et que cela ressemble à votre cas, vous avez une chance de changer.

La meilleure approche que j’ai vue consiste à ne pas mordre trop, mais à commencer par des changements progressifs qui auront l’impact le plus positif. Selon votre description, une meilleure gestion des demandes de changement constituerait un point de départ. Une fois que cela est sous contrôle, vous pouvez commencer à créer un framework de service ou d’autres améliorations incrémentielles en termes de conception / code.

La pire approche que j'ai vue consiste à essayer de faire un grand saut directement d'un système hérité au dernier et plus performant, par exemple en passant d'un système VB6 / Classic ASP / COM + fonctionnel mais encombrant à un système MVC / Entity Framework.


3
"Tout d’abord, vous trouverez des documents obsolètes partout où vous travaillerez en tant que programmeur, à moins que vous ne travailliez pour une start-up et que vous ne créiez le code original maladroit d’origine." J'étais le premier programmeur de mon démarrage. Huit derniers, je me retrouve souvent à dire «qui a écrit ce code idiot?», Seulement pour vérifier et découvrir que je suis le coupable.
Jim In Texas

La vitesse d'itération bat la qualité d'itération. En d’autres termes, apportez souvent de nombreux petits changements et vous finirez par arriver où vous voulez.
jasonk

11

"Hé Boss, après Big Project, l'équipe et moi-même aimerions disposer de notre temps, idéalement X mois, pour organiser notre code. Ce qui devrait pouvoir être fait en quelques minutes prend des heures, car tout cela est très désorganisé. S'il n'est pas possible de le faire juste après Big Project, nous aimerions planifier un calendrier réaliste. "

(partiellement paraphrasé du commentaire d'Azkar sur la question)


10
En théorie, ce serait génial. En pratique, la réponse serait du type "Non, le PDG veut que ce soit Another Big Projectfait dans X mois." ou "Nous avons y de nouvelles fonctionnalités qui doivent être apportées immédiatement, nous n'avons pas le temps de réparer ce qui fonctionne déjà"
Wayne Molina

2
Cela fonctionne rarement (si jamais). Surtout si vous avez un manager qui existe depuis un moment, car il / elle aura déjà entendu cette ligne avant de la voir exploser.
Taylor

1
Cela me fait juste rire. Vous n'allez jamais obtenir une réécriture complète dans le programme. Ce que vous pourriez potentiellement faire est d’améliorer la tâche de chaque sous-système dans chaque projet à venir afin qu’il soit finalement conforme aux spécifications (au cours des quelques années à venir).
Martin York

D'après mon expérience, cette approche sera souvent rejetée. Une autre approche consiste à multiplier par 1,5 les estimations d'un grand projet et à passer le tiers de son temps à nettoyer le code en cours de route.
JBRWilkinson

2
Une réponse très fréquente est "Qui financera votre chèque de paie en faisant cela?" Si vous ne parrainez pas directement la tâche, vous devrez demander à l'entreprise de réaliser l'investissement à long terme. Ou travaillerez-vous gratuitement en faisant cela?

7

Commencez à lire Joel on Software (Joel Spolsky / fondateur de Stack Exchange) ...

La première chose que je ferais serait d’effectuer un test de Joël .

Cela vous permettra de le présenter comme suit: "Alors que je cherchais des moyens de m'améliorer en tant que développeur ... je suis tombé sur ce test de 12 questions sur les environnements de développement, alors, pour le plaisir, je leur ai expliqué où je travaillais." Cela en fait une tierce partie décrivant ce qui ne va pas avec votre code et pas vous personnellement.

À mesure que vous en lirez plus sur les pratiques pragmatiques, vous vous améliorerez et implémenterez des éléments comme red / green / refactor, ce qui vous permettra de nettoyer la base de code afin qu’elle devienne gérable. (heures supplémentaires)

J'espère que ça t'as aidé! Bienvenue dans la programmation (le code d'hier est généralement nul) ;-)


4
Je ne pense pas que cela explique comment il devrait aborder la direction.
Pubby

3
Il semble que Azbar connaisse le problème et sache le résoudre, mais il ne sait pas comment lancer le processus pour le résoudre.
Pubby

1
Oui ... Je proposais d'utiliser le point de vue d'un tiers lors de sa présentation. Je ne pensais pas qu'il demandait spécifiquement comment parler à son patron.
Robert French

4
Cette réponse mérite à peine autant de votes négatifs. La première phrase mérite +10. Joel, le problème avec l’approche de la direction, c’est de comprendre ce qui est important pour eux, Joel, et cette réponse aborde ce genre de problème en examinant les raisons pour lesquelles, et non pas, d’un point de vue commercial, le code doit être réécrit.
Mattnz

1
@Robert French +1 pour une bonne réponse. Il est important qu'Azkar comprenne à la fois les affaires et la technologie. Le fait de suggérer qu’il forme sa propre opinion à partir des observations d’une troisième personne hautement qualifiée contribuera au développement d’Azkar en tant que développeur, et pas seulement en tant que codeur. En outre, l'histoire de PB & J est drôle.
bakoyaro

7

Petit conseil: si vous proposez à la direction une liste des raisons pour lesquelles vous devriez coder différemment, incluez comme argument "Conditions de travail / moral améliorées pour les programmeurs".

Expliquez clairement que l'équipe technique aura davantage de contenu à rédiger et à maintenir un code propre que ce gâchis actuel, ce qui peut certainement améliorer votre attitude à l'égard du travail. Pourrait être un argument utile.


certainement une bonne idée et aussi très vrai
sdm350

5
  • La direction dicte-t-elle réellement la conception? Si vous avez la plupart de l'équipe derrière vous, qu'est-ce qui vous empêche? Soyez proactif et décidez en groupe. Élaborez un plan pour le mettre en œuvre progressivement . Alors fais le.
  • La direction dicte-t-elle les outils de développement que vous utilisez? À moins d'un coût en temps pour échanger un outil, la gestion des outils s'en moque généralement. Soyez proactif et décidez en groupe des outils de développement que vous souhaitez utiliser. Si vous avez besoin d'un achat auprès de la direction, montrez-leur un plan de migration et une analyse coûts-avantages. Alors fais le.
  • La direction dicte-t-elle les langues que vous utilisez? Soyez proactif et décidez en groupe quoi utiliser à la place de VBScript. Élaborez un plan pour le mettre en œuvre progressivement et faites-le. Si vous avez besoin de rachat par la direction, montrez-leur le plan. Alors fais le.
  • Je n'ai rien pour les spécifications. Cela dépend généralement beaucoup des personnes et des processus de votre travail. Identifier ce qui est brisé et les changements minimaux requis pour résoudre le processus prend du temps, il faut du temps pour analyser et comprendre comment les choses fonctionnent actuellement et comment elles devraient fonctionner. Si vous savez que vous pouvez élaborer un plan et essayer de convaincre la direction.

Vous obtenez plus de changement et de respect si vous proposez des moyens de changer qui n'impliquent pas de grandes quantités de temps dédié sans valeur commerciale (ou douce) à démontrer.


Non / Oui / Oui. Le choix de la langue et des outils est rarement un choix fait pour des raisons techniques. (voir: parashift.com/c++-faq-lite/big-picture.html#faq-6.5 ) Ce sont les outils dont la société dispose depuis le début. Il est peu probable que la ré-outillage d’une entreprise ou d’une équipe se produise à cause de la baisse de productivité.
Martin York

1
+1 pour planifier et mettre en œuvre progressivement. tout réécrire, c'est demander un échec. Les petites victoires au fil du temps renforcent la confiance. En ce qui concerne les spécifications ... la plupart des spécifications que vous obtenez en tant que programmeur ne nous ont pas confié le soin de les affiner. De temps en temps, vous êtes gâté par quelqu'un qui écrit de bonnes spécifications. La plupart du temps, le programmeur se déplace / est promu / trouve un meilleur travail.
SoylentGray

@Loki Astari: Dans la plupart des entreprises où j'ai été chez moi, j'ai proposé des modifications allant du système de contrôle de révision, à la structure, au processus de développement et même au langage. Tout ce dont vous avez besoin est un plan raisonnable qui décrit les coûts et les avantages du changement. Le fait que cela soit rarement fait ne signifie pas que cela ne peut pas être fait.
dietbuddha

4

Parlant d'expérience: Ce n'est pas facile. C'est presque impossible. La direction ne s’inquiète pas du fait que le code soit nul et il est plus que probable qu’elle ignore totalement les problèmes rencontrés et / ou qu’elle n’ait aucune idée des problèmes auxquels elle fait face; sinon, ils l’auraient corrigée depuis longtemps et vous ne seriez pas pris au piège aujourd’hui. La meilleure chose à faire est de dresser une liste des raisons pour lesquelles le code est nul, puis du raisonnement qui explique pourquoi il est nul de démontrer la valeur métier réelle du refactoring / de la réécriture.

Un exemple pourrait être "Le code n'est pas maintenable":

Le code actuel n'est pas maintenable à cause de X , Y et Z (liste des raisons pour lesquelles il n'est pas maintenable). Cela rend les demandes de modification et les nouvelles fonctionnalités très difficiles à effectuer, car X , Y , Z (il est difficile d’apporter des modifications). Les modifications étant difficiles, l'équipe de développement ne peut pas facilement répondre aux corrections de bogues et aux améliorations.

Votre seul espoir est que votre supérieur hiérarchique et votre équipe de direction ne soient pas trop stupides pour comprendre les conséquences du code et soient prêts à cesser de présenter de nouvelles demandes de fonctionnalités afin de résoudre ces problèmes, sinon vos efforts seront vains. . Par le passé, il est fort probable qu'ils ne verront rien de mal dans le code et / ou que vos collègues sont trop vifs pour faire part de leurs préoccupations à la direction.

Bonne chance. Vous en aurez besoin.


2
D'accord et "non maintenable" ne fonctionne également que dans une certaine mesure. Pour de nombreux gestionnaires (surtout sans connaissances techniques), le code de travail est égal au code maintenable. Si vous prétendez le contraire, vous pourriez même être vu comme incompétent à leurs yeux.
MaR

3

"J'ai commencé tout juste de l'université" - devrait répondre à votre question.

La direction sait probablement que le code est sous-optimal. La plupart du code est à moins que vous ayez engagé Ray Gosling, Guido Van Rossum ou quelqu'un d'autre vraiment bon et cher pour l'écrire.

La direction sait également que cela fonctionne en utilisant la définition de "travaux" qui s'applique à votre entreprise (ne plante pas, ne vend pas, ne publie pas les rapports, etc.).

Ils veulent que le code «fonctionne» à un coût minimal. Ils ne veulent pas d'une proposition de projet coûteux pour tout réécrire.


Votre première ligne est totalement biaisée contre les juniors. D'une part, vous ne connaissez pas SON expérience, vous ne pouvez donc pas répondre à sa question. Et généraliser en tant que tel, c'est être extrêmement biaisé contre les juniors! J'y travaille depuis environ 20 ans et je peux vous garantir que j'ai vu plus de "débutants" que de "grands ignorants".
Jeach

Pas exactement biaisé contre les juniors, mais peut-être devrait-il reconnaître l'expérience et la connaissance supérieure de ses collègues qui travaillent depuis un certain temps? Ils ne peuvent pas tous être des vieux Wallies incompétents.
James Anderson

2

Le business case est presque impossible à réaliser car votre livrable est un logiciel fonctionnel (ce qu’ils ont déjà) pas un code élégant.

Ajoutez au fait que, dans le cas des logiciels, il y a un coût d'opportunité important pour arriver au marché avec des fonctionnalités d'abord. Si vous y réfléchissez vraiment, le retour sur investissement à long terme sur l'investissement temporel n'est pas garanti.

Cela dit, il est toujours bon de refactoriser et de corriger les petites choses (comme obtenir un bon VSS) en cours de route en petites étapes gérables. En fin de compte, il s’agit d’un problème technique et non de gestion. Faites juste ce qui doit être fait tout en respectant ce que vous avez promis et tout ira bien. La direction ne sera probablement pas intéressée par les détails de base de la qualité du code même si vous défendez vos arguments.


2

Il suffit de partir dès que possible (peut-être que vous ne partez pas trop tôt, car vous ne voulez pas ressembler à une situation désespérée). Le fait qu’ils codent est un désordre et que les gens y restent signifie que vous travaillez probablement avec des développeurs pauvres. Tout développeur digne de ce nom qui se soucie de son travail ne resterait pas longtemps à travailler sur une telle merde.

La probabilité qu'une réécriture se produise est assez faible, à moins que vous ne puissiez clairement démontrer que l'investissement en vaut la peine.


C’est finalement le seul véritable plan d’action. Je l'ai déjà dit, je le répète: les développeurs intelligents travaillent pour des entreprises intelligentes qui comprennent pourquoi il est important d'écrire TOUJOURS un bon code et de consacrer le temps nécessaire à son bon fonctionnement. Les développeurs médiocres travaillent pour des entreprises médiocres où tout le monde est trop concentré sur "l'achèvement de ses tâches" pour veiller à ajouter de la boue et même à voir le code de refactoring qui n'est pas directement lié à votre tâche actuelle "gaspillé temps". Ces endroits ne valent pas la peine d’être travaillés si vous vous considérez intelligent.
Wayne Molina

1

La direction ne se soucie pas du code. Ils se soucient d'avoir un produit à vendre.

Si le système existant est vraiment, vraiment mauvais et qu’il ajoute une quantité ridicule de frais généraux pour la majorité de l’équipe (je dis majorité, car il y a toujours un gars qui a codé de gros morceaux ou l’ensemble du code et le sait comme le sa main) puis approchez-les et dites-leur que cela coûte de l'argent à l'entreprise en temps de développement, et que cela aura un effet d'entraînement sur la satisfaction du client.

Mais encore une fois, ils ne se soucient pas du code, ils se soucient du produit. Par conséquent, même si cette réponse peut leur faire dire «Ouais, faisons-le», vous pourriez aussi bien ranger le code sans demander la permission du responsable. Ne partez pas à la mer, assurez-vous de parler à l'équipe en premier, personne n'aime venir et essayer d'utiliser cette fonction qui vous a pris 3 mois pour écrire et semble maintenant ne pas fonctionner car elle a été piratée.


Comme vous le suggérez ... Il doit pouvoir faire quelque chose pour améliorer le code. Si c'est une fonction géante, vous pouvez faire quelque chose à ce sujet. Le fait qu'il se plaint même de Source Safe est un peu drôle. Il n’ya rien de mal avec Source Safe, il a été utilisé pendant des années, il a peut-être quelques choses qui n’ont aucun sens dans le monde d’aujourd’hui, mais c’est le recul.
Ramhound

Je pense que SourceSafe lui-même n'est pas le problème, il continue à utiliser SourceSafe lorsqu'il existe de meilleurs outils gratuits disponibles crie simplement "Nous ignorons tout ce qui est en dehors de la boîte" et "La médiocrité est la règle du jour, car nous allons nous en tenir à un inférieur produit plutôt que d'apprendre un supérieur ". C'est l'attitude de la plupart des utilisateurs de SourceSafe qui est le problème.
Wayne Molina

"ranger le code sans permission" - cela ressemble à réparer quelque chose qui n'est pas cassé.
James Anderson

1
Mon salon n'est pas dangereux pour la santé mais je m'assure néanmoins de le nettoyer régulièrement. Il ne s'agit pas vraiment de réparer quelque chose qui n'est pas cassé, mais d'accomplir une tâche nécessaire.
Nicholas Smith

0

Adressez-vous à la gestion de telle manière que vous montriez que vous comprenez les conséquences budgétaires de l’introduction de modifications importantes dans le code et les incidences budgétaires de la NON-modification. J'ai aimé le libellé d'Emilio.

Il est important de garder à l'esprit que cet "ancien" code sera toujours horrible. Je veux dire par là que nous grandissons tous constamment en tant que développeurs. Nous écrivons un bon code, puis nous apprenons à écrire un meilleur code plus tard et l'ancien "bon" code semble terrible. Trop de développeurs essaient constamment de l'améliorer et de gaspiller plus d'argent à long terme. C'est un acte d'équilibre. Cela dit, il est toujours bon de pouvoir améliorer les choses au fur et à mesure. Lorsque vous allez modifier cette fonction géante, séparez-la! Finalement, vous arriverez à quelque chose.


0

Ne le fais pas.

Réécrire un grand projet à partir de zéro est une grave erreur la plupart du temps de toute façon.


Large est relatif.
Luca

1
Ma définition est la suivante: si vous ne pouvez pas le réécrire vous-même en 5 jours, il est volumineux.
Cesar Canassa

-1

Je n'ai jamais pensé qu'il était facile d'informer les gestionnaires, en particulier les chefs de projet, au sujet du code défectueux et du refactoring. Premièrement, ils doivent vous faire confiance, même si vous êtes un type plus âgé, vous avez encore besoin de temps pour vous faire confiance. Deuxièmement, ils ne comprennent tout simplement pas à quel point le problème est grave. Si aujourd'hui est le dernier jour pour publier une nouvelle version, celle-ci échoue. Ils savent à quel point c'est grave, mais ils ne savent jamais que la compilation a échoué à cause de nombreux problèmes, tels que code incorrect, tests inadéquats, etc.

J'ai effectué des tâches de configuration et de déploiement dans un projet Web. La résolution de problèmes imprévus prend souvent beaucoup de temps chaque fois que je déploie une nouvelle version. La plupart des problèmes étaient liés à la sécurité et à l'intégration (entre plusieurs applications Web / Windows). Notre code est nul, le code des autres est nul, ils sont complètement codés.

Nous avions prévu une nouvelle version et j’ai demandé instamment que nous procédions à une refactorisation. Il suffit d’ajouter un journal détaillé au code de connexion / d’authentification, où des bogues sont souvent survenus. Les gestionnaires ont accepté, mais cela a ensuite été placé dans une liste agréable et je ne sais pas si cela sera fait car nous avions déjà une longue liste de fonctionnalités et un calendrier serré.


-3

Il existe deux types de gestionnaires: ceux qui prétendent comprendre ce que vous faites et ceux qui ne le font pas. Ceux qui prétendent comprendre un logiciel vous seront hostiles. Ceux qui ne le sont pas sont simplement ennuyés par vous.

Dans tous les cas, les gestionnaires sont tous des menteurs, ils sont donc très disposés à assumer que tout le monde l'est.

Mon point est que, si vous dites que le logiciel est obsolète, ils le prendront comme une excuse. Ils s'en foutent.


+1 sur "Les gestionnaires sont tous des menteurs, ils sont donc très enclins à assumer que tout le monde est
pareil

-1 sur le même; A la fois faux et inutile
Jaap

@Jaap Il existe de nombreuses études établissant une corrélation entre le pouvoir et la classe sociale et la malhonnêteté. Est-ce que cela signifie que vous allez retirer votre -1? Exemples: msnbc.msn.com/id/35836844 blogs.discovermagazine.com/notrocketscience/2010/04/27/… news.sciencemag.org/sciencenow/2012/02/shame-on-the-rich.html
Joe

La deuxième étude confirme particulièrement mon point exact.
Joe

1
@ Joe: vos liens ne (commencent à) prouver votre affirmation selon laquelle "les gestionnaires sont tous des menteurs".
Jaap
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.