Тисячі помилок!

Нещодавно мене призначили на новий проект. Ну, власне, старий проект, написаний класичним 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 місяць? Caveat: Системи рідко відходять, коли вони планують вийти. Система заміни майже завжди запізнюється, є користувачі, які не можуть оновити з будь-якої причини тощо. Але це складне питання.

Двоє: Якщо ви внесете багато змін, особливо масового пошуку та заміни, ви введете помилки. Ви не можете вводити помилок: будете. Припустимо, ви зробили S&R і змінили "width = 200" на "width: 200px". Чи є на ваших сторінках ASP код C # або VB? Тому що якщо у вас була змінна назва "ширина", яку ви встановлювали на 200, ви просто зламали її. (Або з цього питання, ви думали обмежити S&R на сторінках ASP?) Або якщо ви змінили "ширина: 200" на "ширина: 200 пікс", що станеться, якщо в коді було одне місце, яке сказало "ширина: 200 мм "? Тепер він говорить "ширина: 200pxmm". Гаразд, припустимо, ви думали про це. Що робити, якщо знайдеться місце, де було вказано недійсну специфікацію ширини, яку, звичайно, ігнорують, і вона зараз викладається досить непогано. Ви "виправляєте" ширина, і тепер він викладається з 200 пікселів ... і дисплей накручується, тому що 200px насправді неправильна ширина, і він працював лише тому, що це значення було проігноровано? Масові S&R дуже небезпечні, адже ви майже напевно не вивчаєте кожного місця, яке змінюєте. Ви, ймовірно, навіть не знаєте, що тестувати.

Третє: "очевидно" неправильний код може насправді бути тим, що хоче користувач. Я бачив безліч специфікацій вимог, які закликають до поведінки, яка, очевидно, неправильна і божевільна ... а потім я повертаюся до користувачів і запитую, чого вони дійсно хочуть, і виявляється, що вони справді хочуть цієї божевільної поведінки, тому що це як цього вимагає їхній бізнес чи урядові постанови чи що завгодно.

Навіть якщо поведінка насправді неправильна, можливо, користувачі придумали цього, і вони звичайно обійдуться цим, і, виправляючи це, ви порушите їхні обходи. Приклад: Я працюю над системою, де у нас є місце, де ви визначаєте дати та дати, коли продаж буде доступний для населення. Обидві дати справді були опівночі, що розпочався в цей день, тому, якщо ви сказали "до 30 липня", це означало, що закінчилося закінчення дня 29 липня, тобто за хвилину до 12:01 ранку 30 липня, а не кінця 30 липня Одного разу я це виправив, але це міг зробити лише тому, що було менше півдесятка людей, які мали повноваження користуватися цим екраном, і я міг просто сказати їм усе, що я виправив. Якщо було сотні користувачів, і вони досі зрозуміли, що вам справді потрібно було дати день після закінчення дати, то моє "виправлення"

Я, звичайно, можу зробити глобальну знахідку та замінити, щоб позбутися більшості питань, але це означатиме, що моя перша комісія складається з тисяч змінених файлів .asp. Чи можу я це зробити?

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

Ваша проблема полягає у встановленні пріоритетів : Яке з питань є стоп-шоу (на виробництві)? Які тикають таймбоми? І що можна залишити на деякий час довше (адже це працює і робиться так уже роками, навіть на зразок)?

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

Ваші завдання з обслуговування також будуть відображені в цьому списку. Тепер ви починаєте застосовувати деякий менеджмент, навіть якщо тільки до себе, і у вас є інструмент, який можна використовувати, коли у вас є час на руках і нічого робити, або коли вам потрібно домовитись з вашим менеджером щодо роботи (або просити запит час виділити на щось, про що він може не усвідомлювати). (Цей тип активності може допомогти вам помітити рекламні акції, якщо зробити все правильно.)

Я думаю, що вам подобається програмувати, оскільки ви певною мірою володієте перфекціоністською особистістю. Але в комерційному середовищі, ви повинні почати розуміти, що досконалий - ворог добра (а добро приносить гроші, ідеальне може не обов'язково приносити помітно більше за набагато більше роботи). Спочатку робіть те, що потрібно, потім робіть те, що приємно мати. Так, це може не проти кінця зерна. Просто посміхніться і потерпіть це, і, можливо, отримайте хобі, щоб проявити свій перфекціонізм і зберегти вас здоровим ;-)