Des milliers d'erreurs!

J'ai récemment été affecté à un nouveau projet. Eh bien, un vieux projet en fait, écrit en ASP classique. Maintenant, une nouvelle version de l'application est en cours d'écriture dans le dernier ASP.NET, mais il ne devrait pas être RTM dans un certain temps (la date de sortie estimée est janvier 2017), je dois donc effectuer une maintenance sur l'ancienne application jusqu'à ce qu'elle puisse être mis au rebut.
De plus, j'ai le sentiment que tous les clients ne passeront pas immédiatement au nouveau programme, donc cette version sera probablement là pendant un certain temps.

Et le problème est qu'il est plein d'erreurs. Certaines parties remontent au siècle précédent, quand il n'y avait pas de normes Web, et je ne me soucie pas vraiment du mode Quirks widthet des heightattributs au lieu du CSS, des tableaux utilisés pour la mise en page, des jeux de cadres, etc., mais oh, toutes ces erreurs! width="20px"partout onchange="javascript:...", et dans les endroits où ils utilisent CSS, style="width:20"et style="width=20px"sont monnaie courante. Sans parler beaucoup de lignes où il y a des contradictions widthet des styleattributs. Etc etc.
En conséquence, l'application Web ne fonctionne que sous IE et uniquement en mode de compatibilité. Il est clair que les développeurs n'ont jamais regardé la validité du code, seulement si ce qui est sorti ressemblait à ce qu'ils avaient en tête.

Et je ne sais pas comment gérer ça. Je trouve impossible de fermer les yeux sur ces erreurs en cherchant dans le code d'autres erreurs.
Je peux bien sûr faire une recherche et un remplacement globaux pour éliminer la plupart des problèmes, mais cela signifierait que mon premier commit serait composé de milliers de fichiers .asp modifiés. Puis-je faire cela?

On dirait que vous confondez plusieurs choses dans le terme "erreurs"

• attributs html hérités
• style de codage
• erreurs de codage qui ne provoquent pas de bugs
• bogues non signalés
• erreurs qui sont maintenant des fonctionnalités
• bogues signalés
• a signalé des bogues que vous avez été chargé de corriger

Sur une application héritée qui va être remplacée, un seul de ces types d'erreur devrait vous concerner. Le dernier.

J'irais jusqu'à dire que vous ne devriez même pas refactoriser d'autres choses sur une fonctionnalité que vous corrigez, principalement en raison de:

• erreurs qui sont maintenant des fonctionnalités

Vous pouvez voir dans le code comment il était peut-être censé fonctionner, mais ne l'a jamais fait, mais tous les utilisateurs s'entendent avec l'élément de largeur indéterminée depuis 10 ans et ils ne vous remercieront pas de le corriger.

Sur le plan positif, si vous mettez votre tête JFDI cynique, vous pourrez graver si les bugs sont très rapides et l'équipe de la nouvelle version ne pourra pas suivre les anciennes fonctionnalités des versions.

Cela vous donnera un sourire ironique et joyeux de joie ironique alors que vous recommandez un émulateur de plugin chrome ie6 aux clients afin qu'ils puissent continuer à utiliser la `` fonctionnalité '' de marque qu'ils aiment

Ce que vous demandez n'est pas une question technique et personne ici ne peut y répondre.

Vous travaillez sur un logiciel en mode maintenance, et vous observez une technologie démodée et un grand nombre d'imperfections et d'incohérences. Vous demandez quoi faire. Devriez-vous par exemple déployer des efforts pour le rendre compatible avec tous les navigateurs? Devriez-vous le mettre en conformité avec les normes modernes? Devez-vous corriger les incohérences syntaxiques dans l'application? Le fait est que ce sont des décisions commerciales . Vous devez demander à votre responsable ou propriétaire de produit quels problèmes il souhaite que vous résolviez et quelles sont ses priorités. Puisqu'il y a déjà un projet en cours pour réécrire l'application, la direction est probablement déjà consciente des problèmes que vous observez.

Si l'application sera remplacée dans quelques mois, il est probable qu'ils souhaitent uniquement que vous résolviez des problèmes critiques spécifiques et que vous laissiez le reste du désordre tranquille. Mais on ne sait pas.

Vous demandez si vous pouvez effectuer une opération de recherche et de remplacement à grande échelle dans la base de code, en modifiant des milliers de fichiers. Bien sûr vous pouvez. La question est de savoir si vous le devriez . De tels changements radicaux nécessiteront probablement des tests approfondis pour s'assurer que rien ne s'est cassé. Encore une fois, c'est une décision commerciale si l'avantage l'emporte sur le coût en temps et en risque.

Lorsque l'application sera remplacée dans 18 à 24 semaines (en ajoutant les retards à prévoir aux 6 à 8 semaines estimées présentées ci-dessus), vous devez vraiment vous demander quelle valeur vous ajoutez à l'entreprise en investissant toujours une quantité considérable de travail dans l'ancienne version.

Bien sûr, quand vous seriez coincé à soutenir la demande pendant plusieurs années à venir, alors vous débarrasser de la dette technique peut en valoir la peine à long terme. Mais quand tout cela va être jeté de toute façon, alors pourquoi s'embêter? Ajoutez simplement un autre correctif piraté en plus de tous les autres correctifs piratés pour réparer tout problème ne peut tout simplement pas attendre la sortie de la nouvelle version et l'appeler un jour.

Vous pouvez également vous demander ce que vous pouvez faire pour l'application dans le peu de vie qui lui reste. Lorsque vous vous ennuyez vraiment en ce moment et que vous n'avez tout simplement rien de mieux à faire avec votre temps, vous pouvez lui donner une grande refonte et supprimer tous les problèmes de style que vous avez mentionnés, mais il est très probable que cela cassera d'abord plus de choses qu'il ne réglera . Vous pourriez peut-être vous débarrasser de ces nouveaux problèmes avec un peu de temps, mais vous n'avez pas ce temps.

Raisons de NE PAS faire de grands changements:

Un: Le code disparaîtra dans quelques mois. Serait-ce vraiment la peine pour l'entreprise de passer 5 mois à réparer un système qui sera ensuite jeté 1 mois plus tard? Mise en garde: les systèmes disparaissent rarement lorsqu'ils doivent partir. Le système de remplacement est presque toujours en retard, il y a des utilisateurs qui ne peuvent pas mettre à niveau pour une raison quelconque, etc. Mais c'est un problème complexe.

Deux: si vous apportez beaucoup de modifications, en particulier la recherche en masse et les remplacements, vous introduirez des bogues. Non, vous pourriez introduire des bogues: vous le ferez. Supposons que vous ayez fait un S&R et changé "width = 200" en "width: 200px". Y a-t-il du code C # ou VB sur vos pges ASP? Parce que si vous aviez une variable nommée "largeur" ​​que vous définissiez à 200, vous l'avez juste cassée. (Ou d'ailleurs, avez-vous pensé à limiter le S&R aux pages ASP?) Ou si vous avez changé "width: 200" en "width: 200px", que se passe-t-il s'il y avait un endroit dans le code qui disait "width: 200mm "? Maintenant, il dit "largeur: 200pxmm". D'accord, supposons que vous y pensiez. Et s'il y avait un endroit qui avait la spécification de largeur invalide, qui est bien sûr ignorée, et qui se présente maintenant très bien. Tu répares" la largeur et il dispose maintenant de 200px ... et l'affichage est foutu, parce que 200px est en fait la mauvaise largeur à donner et cela n'a fonctionné que parce que cette valeur a été ignorée? Les S&R de masse sont très dangereux, car vous n'étudiez certainement pas tous les endroits que vous changez. Vous ne savez probablement pas quoi tester.

Trois: Un code qui est "manifestement" erroné peut en fait être ce que veut l'utilisateur. J'ai vu beaucoup de spécifications d'exigences qui appellent un comportement qui est manifestement faux et fou ... puis je reviens vers les utilisateurs et leur demande ce qu'ils veulent vraiment, et il s'avère qu'ils veulent vraiment ce comportement fou, parce que c'est comment leur entreprise fonctionne ou les réglementations gouvernementales l'exigent ou quoi que ce soit.

Même si le comportement est vraiment mauvais, peut-être que les utilisateurs en sont venus à s'y attendre et qu'ils le contournent régulièrement, et en le corrigeant, vous romprez leurs solutions de contournement. Exemple: je travaille sur un système où nous avons un endroit où vous spécifiez à partir et à travers des dates qu'une vente est disponible au public. Les deux dates étaient vraiment minuit qui a commencé ce jour-là, donc si vous avez dit "jusqu'au 30 juillet", cela signifiait que cela se terminait à la fin de la journée du 29 juillet, soit une minute avant 12 h 01 le 30 juillet, pas la fin du 30 juillet. À un moment donné, j'ai corrigé cela, mais je ne pouvais le faire que parce qu'il y avait moins d'une demi-douzaine de personnes autorisées à utiliser cet écran, et je pouvais simplement leur dire que je l'avais résolu. S'il y avait des centaines d'utilisateurs, et ils avaient tous compris maintenant que vous deviez vraiment donner le lendemain de la date limite, alors ma "correction"

Je peux bien sûr faire une recherche et un remplacement globaux pour éliminer la plupart des problèmes, mais cela signifierait que mon premier commit serait composé de milliers de fichiers .asp modifiés. Puis-je faire cela?

Je ne vois pas pourquoi pas. Un commit devrait être conceptuellement une chose, mais je ne vois aucune raison pour laquelle une recherche globale et un remplacement de style="width=20"à style="width: 20px"ne compteraient pas comme "une chose", conceptuellement parlant. Et si cela vous aiderait à mieux dormir, vous éviterait d'être distrait pendant que vous réparez d'autres choses, et ne rien gâcher , pourquoi pas?

Votre problème est de fixer des priorités : Quels sont les problèmes qui sont des showstoppers (en production)? Quelles sont les bombes à retardement? Et lequel peut être laissé dans un certain temps (parce que cela fonctionne et le fait depuis des années, même en quelque sorte)?

Ce que je ferais dans votre situation serait de faire des listes de classes de problèmes que j'aimerais examiner. Par exemple, le remplacement style="width=(\d+)"par style="width: \1px"(qui peut probablement être corrigé par une recherche / remplacement globale en utilisant regexp - désolé si le mien n'est pas à 100%) serait une classe, et s'il n'y a qu'une seule occurrence, qu'il en soit ainsi. Pour chaque catégorie, énumérez une priorité (à quel point est-il urgent de le faire) et une estimation du travail (combien de temps cela prendra-t-il pour faire cette catégorie).

Vos tâches de maintenance figureront également dans cette liste. Maintenant, vous commencez à appliquer une gestion, même si ce n'est qu'à vous-même, et vous avez un outil à utiliser lorsque vous avez du temps libre et rien à faire, ou lorsque vous avez besoin de négocier avec votre manager sur le travail à faire (ou demander temps à allouer à quelque chose dont il n’était peut-être pas au courant). (Ce type de proactivité peut vous aider à vous faire remarquer pour les promotions, si cela est fait correctement.)

Je suppose que vous aimez la programmation parce que vous avez une légère personnalité perfectionniste dans une certaine mesure. MAIS dans un environnement commercial, vous devez commencer à réaliser que le parfait est l'ennemi du bien (et le bon rapporte de l'argent, le parfait n'apportera pas nécessairement beaucoup plus pour beaucoup plus de travail). Faites d'abord ce qui est nécessaire, puis faites ce qui est agréable à avoir. Oui, cela pourrait aller contre votre grain sans fin. Il suffit de sourire et de le supporter, et peut-être d'avoir un passe-temps pour exercer votre perfectionnisme et vous garder sain d'esprit ;-)