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 elle ne devrait pas être RTM dans un certain temps (la date de sortie estimée est janvier 2017), je dois donc effectuer certaines l'entretien de l'ancienne application jusqu'à ce qu'elle puisse être jetée.
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 et des attributs width et height au lieu de CSS, les tables utilisées pour mise en page, framesets 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 de nombreuses lignes où il y a des attributs width et style contradictoires. Etc.
Par conséquent, l'application Web s'exécute uniquement 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 effectuer une recherche et un remplacement globaux pour éliminer la plupart des problèmes, mais cela signifierait que mon premier commit consisterait en des 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 chrome plugin ie6 aux clients afin qu'ils puissent continuer à utiliser la "fonctionnalité" Marquee 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 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 entièrement remplacée dans quelques mois, il est probable qu'ils veulent seulement que vous résolviez des problèmes critiques spécifiques et laissiez le reste du désordre seul. Mais on ne sait pas.
Vous demandez si vous pouvez effectuer une opération de recherche et de remplacement à travers la base de code, en changeant des milliers de fichiers. Bien sûr vous pouvez. La question est de savoir si vous 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 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 pourriez aussi vous demander ce que vous pouvez faire pour l'application dans le peu de vie qu'il lui reste. Lorsque vous vous ennuyez vraiment en ce moment et n'avez tout simplement rien de mieux à faire avec votre temps, vous pourriez 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 au début casser plus de choses qu'il n'en résoudra. Vous pourrez peut-être vous débarrasser de ces nouveaux problèmes avec suffisamment de temps, mais vous ne disposez pas de 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é "largeur = 200" en "largeur: 200px". Y a-t-il du code C # ou VB sur votre ASP pges? Parce que si vous aviez une variable nommée "largeur" que vous définissiez à 200, vous la cassiez simplement) . (Ou d'ailleurs, avez-vous pensé à limiter le S&R à ASP pages?) Ou si vous avez changé "width: 200" en "width: 200px", que se passe-t-il s'il y en a un placer dans le code qui dit "largeur: 200 mm"? Maintenant, il dit "largeur: 200pxmm". D'accord, supposons que vous y pensiez. Et s'il y a un endroit qui avait la spécification de largeur invalide, qui est bien sûr ignorée, et c'est maintenant, vous disposez très bien. Vous "fixez" la largeur et elle se présente maintenant avec 200 pixels ... et l'affichage est foutu, parce que 200 pixels n'est en fait pas la bonne largeur à donner et cela n'a fonctionné que parce que cette valeur a été ignorée? Les S&R 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 où 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 s'étaient tous rendu compte maintenant que vous deviez vraiment donner le lendemain de la date limite, alors ma "correction" l'aurait cassé pour toutes ces personnes.
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 à partir de style="width=20" à style="width: 20px" ne compterait pas comme "une chose", conceptuellement parlant. Et si cela vous aide à mieux dormir, vous évite d'être distrait pendant que vous réparez d'autres choses, et ne rien foutre en l'air, pourquoi pas?