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

30

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

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

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

Мистер листер
источник
21
Под "ошибками" вы подразумеваете стиль кодирования, который вам не нравится?
Юань
9
Совет, который я услышал: идите в место, где практикующие студенты музыки. Попробуйте получить пятнадцать минут в звуконепроницаемой комнате. СКРИМ на пятнадцать минут. Теперь тебе полегчало, иди и исправляй ошибки! Серьезно, уточните у руководства, какова цель. Если это программное обеспечение необходимо, оно может очень скоро остановить их обновление компьютеров и вызвать проблемы с заменой старых сломанных компьютеров.
gnasher729
24
Этот вопрос больше напоминает напыщенную речь. Почему вы жалуетесь на программное обеспечение, которое будет утилизировано через несколько месяцев?
Док Браун
5
Не является «ошибкой» то, что код, написанный на «классическом ASP», следует стандартам (таким, как они были) классического ASP, которые отличаются от последней моды в веб-кодировании - и последняя мода, вероятно, будет «вне» даты "в следующем году в любом случае. «Понятно, что разработчики никогда не смотрели на достоверность кода» - если ОП думает, что он может написать код, который все еще будет «выглядеть валидным» через 15 или более лет, время покажет, является ли это убеждение естественным оптимизмом ( или невежество) молодости.
Алефзеро
19
«Я должен выполнить техническое обслуживание старого приложения, пока оно не будет удалено». Какое обслуживание? Пожалуйста, будьте конкретны. Если вам было поручено поддерживать эту кодовую базу, и больше ничего не было сказано, не меняйте ничего. Поддержание этого подразумевает, что вы продолжаете заставлять его работать, а не исправлять вещи, которые не считаются сломанными с самого начала.
Стефан Бранчик

Ответы:

99

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

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

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

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

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

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

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

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

Ewan
источник
28
« ошибки, которые теперь являются особенностями » - о, радость ...
FP
36
Действительно будьте очень осторожны в том, к чему вы прикасаетесь, Это сразу пришло на ум: xkcd.com/1172
Деннис Джаэруддин
3
Пожалуйста, уточните... JFDI ...
GER
5
@GER "Just [expletive] Do It", что означает отказ от нормальных стандартов, тестирования и других вещей, и просто получить исправление, не заботясь о том, сделано ли оно обслуживаемым и читабельным способом.
Nzall
3
как агли, но тем более
Эван
40

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

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

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

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

JacquesB
источник
1
Это деловое решение, но ответить так очевидно, что ему не нужно спрашивать менеджера. Он не должен навести порядок, если не требуется. (+1)
USR
14

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

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

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

Philipp
источник
11
s/weeks/years/
CodesInChaos
9
В прошлом году я исправлял ошибку производительности, которая по существу составляла таблицу, которая должна кэшировать некоторые недавние значения, фактически сохраняя всю историю и безгранично увеличиваясь. В соответствующем месте кода был комментарий, в котором говорилось, что «это следует периодически очищать, но это не имеет значения, поскольку мы планируем отказаться от системы к концу 2007 года». Ничто не живет дольше, чем временные решения.
Петерис
@ Петерис Ну, временные налоги. Но да
Джей
В прошлый раз, когда я работал над таким приложением, оно также было предназначено для временного использования. Аппаратное обеспечение, которое оно было предназначено для управления, было утилизировано, и была произведена замена, и должно было быть разработано новое программное обеспечение для управления заменой. Оно будет доступно через 6 месяцев. К сожалению, замена оборудования была неисправна, и весь бюджет был потрачен на устранение неисправностей, поэтому для замены системы управления не осталось ничего. Через несколько лет весь проект был свернут. AFAIK, вся система по-прежнему работает на старом оборудовании и программном обеспечении, 5 лет спустя.
Жюль
К счастью, я получил разрешение, чтобы исправить худшую из проблем (атаки с использованием SQL-инъекций, таблицы SQL с миллионами строк, но без индексов , страницы, на которых первоначальный разработчик забыл проверить авторизацию ...).
Жюль
3

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

Первый: код исчезнет через несколько месяцев. Действительно ли стоило бы компании потратить 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 июля. В какой-то момент я исправил это, но я мог сделать это только потому, что было менее полудюжины людей, имеющих право использовать этот экран, и я мог просто сказать им всем, что исправил это. Если бы были сотни пользователей, и они уже все выяснили, что вам действительно нужно дать день после сквозной даты, тогда мое "исправление"

сойка
источник
0

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

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

наряжать
источник
12
Почему бы нет? Потому что быстрый поиск и замена в большой устаревшей кодовой базе требует тщательного тестирования, чтобы убедиться, что ничего не сломалось.
JacquesB
-2

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

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

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

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

fr13d
источник