Тысячи ошибок!

Я был назначен на новый проект недавно. Ну, на самом деле старый проект, написанный на классическом ASP. Теперь новая версия приложения пишется в последней версии ASP.NET, но через некоторое время она не станет RTM (предполагаемая дата выпуска - январь 2017 г.), поэтому мне придется выполнить некоторые операции по обслуживанию старого приложения, пока оно не будет отбрасываются.
Кроме того, у меня есть ощущение, что не все клиенты сразу перейдут на новую программу, так что эта версия, вероятно, появится некоторое время.

И проблема в том, что он полон ошибок. Отчасти это относится к прошлому веку, когда не было никаких веб-стандартов, и я не особо беспокоюсь о режиме Quirks, widthа также об heightатрибутах вместо CSS, таблицах, используемых для разметки, наборах кадров и т. Д., Но все эти ошибки! width="20px"повсюду onchange="javascript:..."и в тех местах, где они используют css, style="width:20"и style="width=20px"являются обычным явлением. Не говоря уже о множестве строк, где есть противоречия widthи styleатрибуты. И т.д. и т.п.
В результате веб-приложение работает только под IE и только в режиме совместимости. Понятно, что разработчики никогда не смотрели на достоверность кода, только если то, что получилось, выглядело так, как они думали, должно выглядеть.

И я не знаю, как справиться с этим. Я нахожу невозможным закрыть глаза на эти ошибки, глядя в коде на наличие других ошибок.
Конечно, я могу выполнить глобальный поиск и замену, чтобы устранить большинство проблем, но это будет означать, что мой первый коммит будет состоять из тысяч измененных файлов .asp. Я могу это сделать?

Похоже, вы путаете несколько вещей в термине «ошибки»

• устаревшие атрибуты HTML
• стиль кодирования
• ошибки кодирования, которые не вызывают ошибок
• незарегистрированные ошибки
• ошибки, которые сейчас являются особенностями
• сообщили об ошибках
• сообщили об ошибках, которые вам поручили исправить

В устаревшем приложении, которое будет заменено, вас может беспокоить только один из этих типов ошибок. Последний.

Я бы сказал, что вам не следует даже рефакторировать другие элементы функции, которую вы исправляете, в основном из-за:

• ошибки, которые сейчас являются особенностями

Из кода вы можете видеть, как это должно было работать, но никогда не работало, но все пользователи мирились с неопределенно обессиленным элементом в течение последних 10 лет, и они не будут благодарны вам за исправление.

С другой стороны, если вы наденете свою циничную голову JFDI, вы сможете сгореть, хотя ошибки будут очень быстрыми, и команда новой версии не сможет идти в ногу со старыми функциями версий.

Это заставит вас улыбнуться ироничной радостью, когда вы порекомендуете клиенту хромированный плагин ie6 эмулятор, чтобы они могли продолжать использовать "особенность", которую они любят

То, что вы спрашиваете, не является техническим вопросом, и никто здесь не может ответить на него.

Вы работаете над программным обеспечением в режиме обслуживания и наблюдаете устаревшую технологию и большое количество недостатков и несоответствий. Вы спрашиваете, что делать. Например, стоит ли вам прилагать усилия, чтобы сделать его совместимым с различными браузерами? Должны ли вы привести его в соответствие с современными стандартами? Стоит ли исправлять синтаксические несоответствия в приложении? Дело в том, что это деловые решения . Вы должны спросить своего менеджера или владельца продукта, какие проблемы они хотят, чтобы вы решили, и каковы их приоритеты. Поскольку уже существует проект по переписыванию приложения, руководство, скорее всего, уже знает о проблемах, которые вы наблюдаете.

Если приложение будет полностью заменено в течение нескольких месяцев, скорее всего, они только захотят, чтобы вы исправили конкретные критические проблемы и оставили остальную часть беспорядка в покое. Но мы не знаем.

Вы спрашиваете, можете ли вы выполнить широкую операцию поиска и замены по всей базе кода, изменяя тысячи файлов. Конечно вы можете. Вопрос в том, если вы должны . Такие радикальные изменения, вероятно, потребуют тщательного тестирования, чтобы убедиться, что ничего не сломалось. Опять же, это бизнес-решение, если выгода перевешивает затраты по времени и риску.

Когда приложение будет заменено через 18–24 недели (с учетом ожидаемых задержек к ожидаемой 6–8 неделе, представленной выше), вам действительно нужно спросить себя, какую ценность вы добавляете в бизнес, по-прежнему вкладывая значительный объем работы в старая версия.

Несомненно, если в течение нескольких лет вы будете зависеть от поддержки приложения, то избавление от технического долга может стоить того в долгосрочной перспективе. Но когда все это будет сброшено в любом случае, тогда зачем? Просто добавьте еще одно хакерское исправление поверх всех других хакерских исправлений, чтобы исправить любую проблему, которая просто не может дождаться выхода новой версии, и назвать это днем.

Вы также можете спросить себя, что вы можете сделать для приложения в том небольшом сроке его существования. Если вам действительно скучно прямо сейчас, и вы просто не имеете ничего общего со своим временем, вы можете провести капитальный ремонт и устранить все упомянутые проблемы со стилем, но вполне вероятно, что это поначалу сломает больше вещей, чем исправит , Возможно, вам удастся избавиться от этих новых проблем в конечном итоге, если у вас будет достаточно времени, но у вас нет этого времени.

Причины НЕ делать больших изменений:

Первый: код исчезнет через несколько месяцев. Действительно ли стоило бы компании потратить 5 месяцев на исправление системы, которая затем будет выброшена через 1 месяц? Предостережение: системы редко уходят, когда они по расписанию уходят. Замена системы почти всегда происходит поздно, есть пользователи, которые не могут обновиться по какой-либо причине и т. Д. Но это сложный вопрос.

Второе: если вы сделаете много изменений, особенно массового поиска и замен, вы внесете ошибки. Не вы можете ввести ошибки: вы будете. Предположим, вы сделали S & R и изменили "width = 200" на "width: 200px". Есть ли код C # или VB на ваших ASP-страницах? Потому что, если у вас была переменная с именем width, которую вы устанавливали на 200, вы просто ее сломали. (Или, если на то пошло, вы думали ограничить S & R страницами ASP?) Или, если вы изменили «width: 200» на «width: 200px», что произойдет, если в коде будет одно место, которое говорит «width: 200mm» «? Теперь он говорит "ширина: 200pxmm". Хорошо, предположим, вы подумали об этом. Что делать, если есть место с недопустимой спецификацией ширины, которая, конечно же, игнорируется, и теперь она выглядит довольно красиво. Вы исправить" ширина и теперь она составляет 200px ... и дисплей облажался, потому что 200px фактически неправильная ширина, и она работала только потому, что это значение было проигнорировано? Массовые S & R очень опасны, потому что вы почти наверняка не изучаете каждое место, которое вы меняете. Вы, вероятно, даже не уверены, что тестировать.

Третье: код, который «явно» неверен, на самом деле может быть тем, что хочет пользователь. Я видел множество спецификаций требований, которые призывают к поведению, которое явно неправильное и безумное ... и затем я возвращаюсь к пользователям и спрашиваю, чего они ДЕЙСТВИТЕЛЬНО хотят, и оказывается, что они действительно хотят этого безумного поведения, потому что это как их бизнес работает или государственное регулирование требует этого или чего-то еще.

Даже если поведение действительно неправильное, возможно, пользователи привыкли ожидать его, и они обычно обходят его, и, исправив его, вы обойдете обходные пути. Пример: я работаю в системе, где у нас есть место, где вы указываете даты и даты, когда продажа доступна для общественности. Обе даты были действительно полночью, которая началась в тот день, поэтому, если вы сказали «до 30 июля», это означало, что она закончилась в конце дня 29 июля, т.е. за одну минуту до 12:01 30 июля, а не в конце 30 июля. В какой-то момент я исправил это, но я мог сделать это только потому, что было менее полудюжины людей, имеющих право использовать этот экран, и я мог просто сказать им всем, что исправил это. Если бы были сотни пользователей, и они уже все выяснили, что вам действительно нужно дать день после сквозной даты, тогда мое "исправление"

Конечно, я могу выполнить глобальный поиск и замену, чтобы устранить большинство проблем, но это будет означать, что мой первый коммит будет состоять из тысяч измененных файлов .asp. Я могу это сделать?

Я не понимаю, почему нет. Фиксация должна быть концептуально одной вещью, но я не вижу причин, по которым глобальный поиск и замена из style="width=20"to style="width: 20px"не будет считаться концептуально «одной вещью». И если это поможет вам лучше спать, избавит вас от отвлечения внимания, когда вы исправите другие вещи, и ничего не испортит, то почему бы и нет?

Ваша проблема заключается в установлении приоритетов : какие из вопросов являются showtoppers (в производстве)? Какие тикают бомбы замедленного действия? И что можно оставить на некоторое время дольше (потому что это работает и так уже много лет, даже вроде)?

В вашей ситуации я бы сделал списки проблемных классов, на которые мне хотелось бы взглянуть. Например, замена style="width=(\d+)"на style="width: \1px"(которая может быть исправлена ​​глобальным поиском / заменой с использованием регулярного выражения - извините, если у меня нет 100%) будет одним классом, и если есть только одно вхождение, пусть будет так. Для каждой категории укажите приоритет (насколько срочно это сделать) и оценку работы (сколько времени потребуется, чтобы сделать эту категорию).

Ваши задачи по обслуживанию также будут фигурировать в этом списке. Теперь вы начинаете применять какое-то управление, даже если только к себе, и у вас есть инструмент, который вы можете использовать, когда у вас есть время и вам нечего делать, или когда вам нужно договориться с вашим менеджером о работе (или запросить время должно быть выделено на что-то, что он может не знать). (Этот вид проактивности может помочь вам быть замеченным для продвижения по службе, если все сделано правильно.)

Я полагаю, вам нравится программирование, потому что вы в некоторой степени обладаете небольшой перфекционистской индивидуальностью НО в коммерческой среде вы должны начать понимать, что совершенное - это враг хорошего (а хорошее приносит деньги, идеальное не обязательно приносит значительно больше для гораздо большей работы). Сначала делай то, что нужно, потом делай то, что приятно иметь. Да, это может пойти против вашего зерна нет конца. Просто улыбнись и перенеси это, и, возможно, получи хобби проявить свой перфекционизм и держать тебя в здравом уме ;-)