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

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.

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.

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.

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.

"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)

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) ;-)

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.

• 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.

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.

"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.

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.

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.

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.

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.

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.

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é.

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.