何千ものエラー！
最近、新しいプロジェクトに割り当てられました。まあ、実際には古いプロジェクトで、古典的なASPで書かれています。現在、アプリケーションの新しいバージョンが最新のASP.NETで記述されていますが、しばらくの間、RTM）になるとは予想されていません（推定リリース日は2017年1月です）。古いアプリケーションを破棄できるまでメンテナンスします。
また、すべてのお客様がすぐに新しいプログラムに切り替わるとは限らないので、このバージョンはしばらく使用されると思います。
そして問題は、エラーがたくさんあることです。その一部は、Web規格がなかった前世紀にさかのぼります。Quirksモードや、CSSの代わりにwidthおよびheight属性を使用することについては特に気にしません。レイアウト、フレームセットなどですが、すべてのエラーです！ width="20px" あらゆる所に、 onchange="javascript:..."、およびcssを使用する場所ではstyle="width:20"およびstyle="width=20px"はありふれたものです。矛盾するwidth属性とstyle属性が存在する多くの行は言うまでもありません。など.
その結果、WebアプリケーションはIEでのみ実行され、互換モードでのみ実行されます。開発者がコードの妥当性を確認したことがないことは明らかです。
そして、私はそれを処理する方法を知りません。他のエラーのコードを調べている間、それらのエラーに目を閉じることは不可能です。
もちろん、グローバルな検索と置換を行ってほとんどの問題を解決することができますが、それは、最初のコミットが何千もの.aspファイルで構成されることを意味します。それをしてもいいですか？
いくつかのことを「エラー」という用語に混乱させているようです
- 従来のHTML属性
- コーディングスタイル
- バグを引き起こさないコーディングエラー
- 報告されていないバグ
- 今の特徴である間違い
- 報告されたバグ
- 修正するよう割り当てられたバグの報告
置き換えられるレガシーアプリでは、これらのタイプのエラーの1つだけが問題になります。最後です。
主に次の理由により、バグを修正している機能で他の要素をリファクタリングしてはいけないと言っています。
- 今の特徴である間違い
コードから、それがどのように機能することを意図していたが実際には機能しなかったのかを確認できますが、すべてのユーザーは過去10年間、不確定な幅の要素を使用しており、修正してくれたことに感謝しません。
プラス面としては、シニカルJFDIヘッドを装着すると、バグが非常に迅速に発生し、新バージョンチームが旧バージョンの機能に追いつくことができなくなります。
chromeプラグインie6エミュレーターをクライアントにすすめ、クライアントが愛するMarqueeの「機能」を使い続けることができるので、これは皮肉な喜びの悲惨な笑顔を与えます。
あなたが尋ねるのは技術的な質問ではなく、誰も答えることはできません。
あなたは保守モードでソフトウェアの一部に取り組んでおり、時代遅れのテクノロジーと多数の不完全性と不整合を観察します。あなたは何をすべきか尋ねます。たとえば、ブラウザ間で互換性を持たせるために努力する必要がありますか？それを現代の基準に合わせる必要がありますか？アプリ全体で構文の不整合を修正する必要がありますか？実は、これらはビジネス上の決定です。マネージャーまたは製品の所有者に、どのような問題を解決してほしいのか、優先順位は何かを尋ねてください。アプリを書き換えるためのプロジェクトがすでに進行中であるため、管理者はほとんどの場合、観察した問題をすでに認識しています。
アプリが数か月以内に完全に置き換えられる場合、それは可能性が高いです彼らはあなたに特定の重大な問題を修正して残りの混乱を残してほしいだけです一人で。しかし、私たちは知りません。
何千ものファイルを変更して、コードベース全体で検索と置換操作を実行できるかどうかを尋ねます。もちろんできます。問題はあなたがすべきかどうかです。そのような抜本的な変更は、何も壊れていないことを確認するために、おそらく広範なテストを必要とするでしょう。繰り返しになりますが、時間とリスクにおいて利益がコストを上回る場合は、ビジネス上の決定です。
アプリケーションが18〜24週間で交換される場合（上記の推定6〜8週間に予想される遅延を追加）、実際に相当な量の作業を投資することによって、ビジネスにどのような価値を付加するかを実際に確認する必要があります。古いバージョン。
確かに、今後数年間アプリケーションのサポートに困っていた場合、技術的な負債を取り除くことは、長期的にはそれだけの価値があります。しかし、とにかくそれのすべてが捨てられるつもりであるなら、なぜわざわざ？他のすべてのハッキングフィックスの上に別のハックフィックスを追加して、新しいバージョンのリリースまで待つことができない問題を修復し、1日と呼ぶだけです。
また、アプリケーションがまだ残っている少しの存続期間で、アプリケーションに対してcanをどうするかを自問することもできます。あなたが今本当に本当に退屈していて、あなたの時間と何の関係もないときはcould大幅な見直しを行い、あなたが述べたすべてのスタイルの問題を取り除きますが、これは最初は非常に可能性が高いですそれが修正するよりも多くのものを壊します。十分な時間が与えられれば、これらの新しい問題を取り除くことができるかもしれませんが、その時間はありません。
大きな変更を加えない理由：
1つ目：コードは数か月で廃止されます。 1か月後に破棄されるシステムの修正に5か月を費やすことは、会社の時間に本当に価値がありますか？警告：システムが廃止予定である場合、システムが廃止されることはほとんどありません。交換システムはほとんどの場合遅く、何らかの理由でアップグレードできないユーザーもいます。しかし、これは複雑な問題です。
2：大量の変更、特に一括検索と置換を行うと、バグが発生します。バグを導入する可能性はありません。 S＆Rを実行し、「width = 200」を「width：200px」に変更したとします。 VBコードにC＃またはASP pgesがありますか？200に設定している "width"という名前の変数がある場合、それを壊しましたので。（あるいは、S＆RをASPページに制限することを考えましたか？）または、「width：200」を「width：200px」に変更した場合、1つあった場合はどうなりますか？ 「width：200mm」と書いたコードに配置しますか？今では「width：200pxmm」と書いてあります。さて、あなたはそれらを考えたとしましょう。無効な幅の指定があった場所があり、それはもちろん無視されます。幅を「固定」すると、幅が200pxになり、200pxは実際には間違った幅であり、その値が無視されたためにのみ機能したため、ディスプレイがねじ込まれていますか？質量S＆Rは、変更するすべての場所を調査しているわけではないため、非常に危険です。何をテストするかさえわからない可能性があります。
3：「明らかに」間違っているコードは、実際にはユーザーが望んでいるものである可能性があります。私は明らかに間違っていて正気ではない動作を要求する多くの要件仕様を見てきました...それから私はユーザーに戻って本当に本当に欲しいものを尋ねます、そしてそれは彼らが本当にこの非常識な動作を望んでいることがわかります彼らのビジネスがどのように機能するか、または政府の規制がそれを要求するか、または何でも。
動作が本当に間違っている場合でも、ユーザーがそれを予期し、日常的に回避している可能性があります。修正することで、回避策を打ち破ることになります。例：私は、あなたがセールを公に利用できる日付から、および日付を指定できる場所があるシステムに取り組んでいます。どちらの日付も実際にはその日から始まった真夜中なので、「7月30日まで」と言った場合、7月29日の終わり、つまり7月30日の終わりではなく、12月1日の1分1分前に終わりました。 。ある時点でこれを修正しましたが、その画面を使用する権限を持っているのは6ダース未満であり、修正したことをすべての人に簡単に伝えることができたので、それだけが可能でした。何百人ものユーザーがいて、それらすべてがあなたが本当に通過日の翌日を与えなければならないことを今までに理解しているなら、私の「修正」はこれらすべての人々のためにそれを壊したでしょう。
もちろん、グローバルな検索と置換を行ってほとんどの問題を解決することもできますが、これは、最初のコミットが何千もの.aspファイルの変更で構成されることを意味します。それをしてもいいですか？
なぜかわかりません。コミットは概念的に 1つのものでなければなりませんが、概念的に言えば、style="width=20"からstyle="width: 20px"へのグローバルな検索と置換が「1つのもの」としてカウントされない理由はわかりません。そしてそれがあなたがよりよく眠れるのを助けるなら、あなたが他のものを修正するときあなたが気を散らされることを救い、そして何も汚さない、なぜそうしないのですか？