Як сперечатися проти зниження стандартів якості для застарілої бази даних? [зачинено]

У нас є велика база застарілих кодів з неправильним кодом, який ви не можете собі уявити.

Зараз ми визначили деякі стандарти якості та хочемо, щоб вони були виконані в абсолютно новій базі коду, але також якщо ви торкнетесь застарілого коду.

І ми примушуємо їх застосовувати Sonar (інструмент аналізу коду), який вже має тисячі порушень.

Зараз дискусія почала знижувати ці порушення для спадщини. Тому що це спадщина.

Дискусія йде про правила читабельності. Як і скільки вкладених ifs / for .. це може мати.

Тепер, як я можу заперечити зниження якості кодування на застарілому коді?

Кодекс - це лише засіб для досягнення мети. Це може бути різним, але зазвичай це прибуток.

Якщо це прибуток; потім успішно аргументувати все, що ви хочете, щоб показати, що це підвищить прибуток - наприклад, за рахунок збільшення продажів, зниження витрат на обслуговування, зниження витрат на розробку, зниження заробітної плати, зменшення витрат на перепідготовку тощо. Якщо ви не можете / не показуєте, що це буде покращити прибуток; то ви здебільшого просто говорите, що це було б цікавим способом злити гроші в туалет.

Я, як і я, був і виробником, і зберігачем спадкового коду. Якщо ваш інструмент генерує "тисячі порушень" (або навіть сотні з цього приводу), забудьте про інструмент, це не застосовується до ситуації ...

Я припускаю, що оригінальні розробники вже давно не доступні для обговорення. Тож ніхто не знає, хто розуміє, чому і чому це стиль дизайну та кодування. Виправлення сотень чи тисяч порушень не буде справою переписування декількох рядків коду тут і там. Натомість, це, безперечно, вимагає рефакторингу / повторного функціонування-розкладання. Ви намагаєтеся зробити це на будь-якій великій існуючій кодовій базі, не чітко розуміючи її сучасний дизайн, і ви зобов’язані представити цілий новий набір помилок / проблем / тощо. Просто нова банка глистів навіть гірша, ніж у вас зараз (або гірше, ніж ваш інструмент >> думає, що у вас є <<).

Єдиним розумним підходом до вирішення "тисяч порушень" було б переписання з нуля. Довгі та дорогі зусилля та майже неможливо продати керівництву. І в цьому випадку вони, мабуть, праві ...

Спадковий код зазвичай вимагає налаштування. Як для y2k, або коли акції перейшли з 256-го на десятковий. Я зробив навантаження обох, що cr * p. І багато іншого подібного. Зазвичай це досить «чітка точка» в тому, що ви можете «прочитати» іноді поганий стиль, поганий функціональний розклад, поганий тощо, і знайти колекцію місць, які потрібно змінити. І тоді те, що відбувається "між тими місцями", тобто, що є більш високим потоком, може залишатися для вас загадкою. Просто переконайтеся, що ви розумієте локалізовану функціональність, яку ви змінюєте, а потім протестуйте, тестуйте, перевіряйте на наявність будь-яких побічних ефектів тощо, ваші локалізовані знання не зможуть передбачити.

Якщо ви не можете бачити свій шлях через такий код, то, можливо, ви не найкраща людина для збереження спадкового коду. Деякі люди можуть починати з порожнього екрана і писати прекрасні програми, але не можуть починати з великої кодової бази коду інших людей і підтримувати її. Інші люди можуть підтримувати код, але не можуть почати з нуля. Деякі можуть зробити і те, і інше. Переконайтеся, що правильні люди підтримують ваш застарілий код.

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

Єдиний >> неправильний << предмет, який потрібно зробити, - це спробувати поводитись із підтримкою застарілого коду так само, як і в новій розробці. І ця одна неправильна річ, здається, є саме тим шляхом, яким ви хотіли б піти :) Візьміть моє слово, це не те, що ви хочете зробити.

Питання не в тому, наскільки хороший чи поганий цей код. Питання в тому, яку вигоду ви отримаєте від скільки інвестицій.

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

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

Якщо він не зламався, не виправляйте

Це практично слід татуювати на кожному розробнику та менеджері програмного забезпечення, щоб вони його ніколи не забували.

Так, він порушує всі сучасні умови кодування. Так, це написано у FORTRAN-77 із обгорткою на C, щоб його можна було викликати з Python. Так, це неструктуровані ГОТО. Так, є одна підпрограма три тисячі рядків. Так, імена змінних мають сенс лише для хорвата. тощо.

Але якщо він випробовувався в гніві більше десятиліття і більше і минув, залиште його в спокої! Якщо потрібна модифікація невелика, то зберігайте її якнайменше та максимально локально. Все інше ризикує зламати щось, що не потребує виправлення.

Звичайно, іноді ви виявляєте, що це дійсно незбагненний клубок і що єдиний спосіб розмістити "малу" модифікацію - це переписати з нуля. У такому випадку вам доведеться повернутися до того, хто просить зміни, і сказати йому, що це буде коштувати (і в доларах, або в людино-годинах за переписування, і в крові, поті і сльозах для неминучих нових помилок).

Давним-давно виникла помилка на збої одного з дисководів Digital. Вони в кінцевому підсумку згадували і замінювали їх усіх на gord знає, яка вартість. Мабуть, була крапка клею, яка тримала фільтр всередині HDA. Інженерний маніфест сказав про клей "Не параметрично вказано, НЕ ЗАМОВЛЕННЯ ПРИЙОМНО". Лічильник бобів "врятувався" під центом на дисковий диск, знайшовши якийсь інший клей. Це випускало пари всередині HDA, що вбило привід через пару років роботи. Його не зламали, поки він не виправив. Безсумнівно, "це була лише крихітна зміна ..."

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

Це єдиний і мертвий простий підхід.

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

Контроль ризику….

• Код у великій застарілій кодовій базі перевірено принаймні реальним використанням програмного забезпечення.
• Код у великій застарілій базі даних коду охоплюється автоматизованими тестовими одиницями.
• Отже, будь-які зміни холоду у великій застарілій кодовій базі є високим ризиком.

Вартість….

• Зробити код пройти перевірку коду, поки ви пишете код дешево
• Робити це в подальшому стані набагато дорожче

Вигода

• Ви сподіваєтесь, що дотримання стандартів кодування призводить до кращого оформлення коду.

• Але дуже малоймовірно, що коли хтось витратить багато тижнів на зміну коду просто для того, щоб видалити попередження зі стандартного інструменту перевірки кодування, це призведе до вдосконалення дизайну коду.

• Простий код зрозуміліший і його легше зрозуміти, якщо складний код не розділиться на короткі методи тим, хто його не розуміє….

Рекомендація….

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

Особистий досвід….

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

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

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

... окрім цього, просто поговоріть про це із залученими людьми та також почуйте їх причини.

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

Таким чином ви можете проаналізувати обидва проекти в сонарі з різними стандартами якості. Стандарти повинні відрізнятися лише за значенням правил. Самі правила повинні бути однаковими. Таким чином, у проекті "спадщина" ви бачите, що потрібно "виправити", щоб відповідати стандартам "чистого" проекту .

Щоразу, коли вам вдалося підняти якийсь застарілий код до вищих стандартів, ви можете перенести його на проект «чисто».

У щоденній роботі ви не можете здійснити підняття кожного класу, який ви торкаєтесь до стандартів «чистого» проекту через відставання часу. Але вам слід спробувати дістатися туди невеликими кроками, намагаючись трохи вдосконалити застарілий код щоразу, коли ви торкаєтесь його.