Виправити помилки чи чекати, коли клієнт їх знайде?


35

Чи інші люди виправляють помилки, коли їх бачать, чи чекають, поки не відбудеться збої / втрата даних / люди вмирають, перш ніж виправити це?

Приклад 1

 Customer customer = null;
 ...
 customer.Save();

Код явно невірний, і навколо цього немає способу - він викликає метод на нульовій посиланні. Це не відбувається збою, оскільки Saveне має доступу до даних про екземпляр; так що це просто як викликати статичну функцію. Але будь-яка невелика зміна в будь-якому місці може раптово призвести до порушення зламаного коду, який не виходить з ладу: почати збій.

Але виправлення коду також неможливо :

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

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

Приклад 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

Люди, які знають фізику, визнають, що у знаменнику має бути R 2 .

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

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

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

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

Приклад 3

Ось приклад, який я нещодавно мав, перевіряючи, чи містить рядок недійсні символи:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

Що робити, якщо виявиться, що у Do somethingгілці є помилка ? Виправлення явно неправильного коду:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

Виправляє код, але вводить помилку.


Як я це бачу, є дві можливості:

  • виправити код і звинуватити його у порушенні
  • зачекайте, коли код вийде з ладу, і його звинувачують у помилці

Чим займаєтесь політично?


Приклад 4 - Помилка в реальному світі сьогодні

Я будую об’єкт, але викликаю неправильний конструктор:

Customer customer = new Customer();

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

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

Називати це помилкою, оскільки він обходить усі наступні конструктори.

Я міг би змінити лінійку об'єкта, щоб не виставляти такого небезпечного конструктора, але тепер я повинен змінити код на:

Customer customer = new Customer(depends);

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

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

Я не можу ставити на це життя вашої дружини.

І я можу перевірити це звідси до вівторка, я не можу присягнути на життя вашої дочки, що я не вніс регресу.

Чи повинен я:

  • Виправити код і звинуватити його у злому? або
  • Залиште помилку та звинувачуйте, коли клієнт її знайде?

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

3
Безумовно, добре
вивчене

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

2
'ти [ти] чекай, поки люди помруть, перш ніж це виправити'! Свята корова, я дуже сподіваюся, що на це є лише одна відповідь ...
Кріс Найт,

3
Як коментар конкретно про одне, що ви сказали: ви не знаєте, чи десь у коді вони покладаються на езотеричну поведінку: так? Якщо хтось зловживає явно невірним правилом визначення масштабів як хак у своєму коді, то він код WRONG. Хороший OOP міг би запобігти цій помилці, але ви не виправите це, оскільки вони використовували погану практику, це ускладнює проблему, залишаючи її відкритою для подальших зловживань та робить систему нестабільною всю дорогу. Виправте помилку, сподіваємось, що тестування виявить будь-які проблеми, виправте більше помилок, якщо цього не відбувається. Довгострокова стабільність продукту є життєво важливим показником.
CodexArcanum

Відповіді:


34

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

Якби я дав загальне керівництво щодо визначення того, що робити, я думаю, що це піде приблизно так:

  1. Введіть дефект у вибраній системі стеження. Обговоріть з потребою керівників / колег.
  2. Якщо це дефект з потенційно тяжкими наслідками (наприклад, ваш приклад №2), бігайте, кричіть, стрибайте вгору та вниз, поки хтось із владними повноваженнями не помітить і визначте відповідний спосіб дії, який зменшить ризики, пов’язані з виправленням помилок. Це може відсунути дату випуску назад, врятувати життя, випрати вікна тощо.
  3. Якщо це несправний дефект або існує рішення, оцініть, чи переважає ризик його виправлення над користю виправлення. У деяких ситуаціях краще буде зачекати, коли клієнт підніме його, оскільки тоді ви знаєте, що не витрачаєте час на виправлення / повторне тестування речей, коли це не потрібно на 100%.

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


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

6
+1 для реєстрації дефекту. Інші дефекти можуть мати пріоритет ...
грудня

35

Клієнти ВЖЕ знайдуть помилок . Ніколи не ховається помилок від клієнтів. Зрештою, введені вами помилки завжди повернуться до вас. Не виправляти їх - просто погана професійна практика. Професіонали цього не роблять.

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


2
Це сумна правда. Нам довелося поставити проект, який ми перевірили як божевільний, і все-таки замовник зумів його зламати протягом 3 хвилин.
Олівер Вайлер

4
@Helper Метод: Можливо, якби ти випробував це на здорових людей, було б краще.
Вінко Врсалович

Метод @Helper: Хоча, якщо серйозніше, то, якби це було насправді три хвилини, схоже, тестери не знали, які реальні випадки використання очікував замовник.
Вінко Врсалович

8
@Helper метод: залучіть клієнта до тестування (припустимо, що замовник == клієнт). Розробники написання та тестування коду - це проблема, де розробники не використовують програмне забезпечення однаково. Розробники ніжні. Це їхня робота - їх мистецтво: клієнти стукають по ній, як мавпа на паніо. Коли це можливо, поділіться тестовими зусиллями, поділіться відповідальністю. Це не входить у кожну поведінку, але робота з клієнтами як команда, а не консультанти можуть покращити програмне забезпечення.
Брайан Чендлі

Е, гірше? (наповнювач)
Hello71

24

Виправити помилку

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

Не плутайте це з рефакторингом або покращенням продуктивності, які не пов'язані з помилкою продуктивності.

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


4
+1. Полагодь це. Якщо виправлення порушує щось інше, то, що все-таки щось було порушено - виправте це теж. Якщо ваше тестування не сприймає цих перерв, то тестування порушено - виправте це також. Ви не можете дозволити собі злякатися зміни коду, боячись щось зламати - ця дорога веде лише до повної руїни.
Том Андерсон

21

Що б сказав замовник?

Ось як я уявляю це розіграш:

Клієнт: Виходить з ладу, коли я роблю х.

Програміст: О так! Пам’ятаю, я бачив це деякий час назад. Я подумав, що це ще не велика справа, тому я залишив це там.

Замовник: [тягнеться до тупого об’єкта]

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

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


8

Усі приклади, які ви навели, мають загальну нитку. Ви, здається, хочете виправити помилку, яку ви не повністю розумієте. Я це кажу, тому що ви відзначаєте можливість ненавмисних наслідків для кожного з них.

Я б сказав, що це, мабуть, величезна помилка, і, як пише Бен Лорі , не виправляйте помилку, ви не розумієте . У цьому відомому прикладі команда Debian порушила шифрування OpenSSL для Debian та таких похідних, як Ubuntu, коли вони дотримувались результатів інструменту аналізу.

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


7

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

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

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

У прикладі 2 легко обшивати калькулятор швидкості тестами та забезпечити правильність обчислення результату у всіх ключових прикладах.

У прикладі 3 існує небезпека повернення мертвого коду до життя. Чи повинен цей код взагалі усунути? Який уміст булевої умови при цьому, якщо? Чи потрібно для того, щоб рядок не містив недійсних символів? Або для того, щоб у ньому було "PO BOX"? Чим раніше ви почнете вирішувати такі питання, тим краще.

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


5

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

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

На жаль, ідеальна ситуація - вигадана. Незалежно від того, наскільки зчеплення нещільне, буде з'єднання, а отже, й можливість зламати щось інше.

Рішення для цього двояке:

  1. Зробіть код максимально структурованим.
  2. Коли код достатньо ізольований, ви знаєте, що більше нічого не зламається, виправте його.

Зробити код добре структурованим не робиться, переписавши весь код на новий архітектурний дизайн. Швидше, ваш друг тут рефакторинг, керований тестами. На цьому кроці ви не змінюєте функціональність.

Другий крок - ви виправите помилку.

Доречні кілька моментів:

  1. Контроль версій абсолютно необхідний для цього процесу.
  2. Крок рефакторингу та етап виправлення помилок краще здійснювати управління версіями як окремі коміти, тому кожен має чітко визначений історичний функціонал.
  3. Не зациклюйтесь на можливості зробити ще одну помилку, ви нічого не зробите. Швидше подумайте, як зробити ваш код кращим. Іншими словами, якщо ви не знаєте, що збільшуєте помилки, а не зменшуєте їх, тоді вам слід це зробити.
  4. Зв'язаний з останнім пунктом: не намагайтеся передбачити майбутнє. Люди упереджено думають, що вони дуже добре прогнозують. Насправді наші повноваження щодо прогнозування є короткотерміновими. Тому не хвилюйтесь про невиразну невизначену майбутня помилка. Це також є принципом YAGNI .
  5. Відповідним інструментом контролю версій у світі помилок є трекер помилок . Вам це також знадобиться.
  6. Виправляти помилки потрібно з двох причин: щоб задовольнити клієнта; і щоб можна було прогресувати у своєму розвитку. Використовувати приклад 3 (фізичний): якщо програма задовольняє клієнта таким розбитим рівнянням, то існує багато інших частин програмного забезпечення, які неправильно розроблені для зменшення цієї помилки (наприклад, розгортання подушки безпеки). Якщо для цього програмного забезпечення потрібна версія 2 (або 1.1), то вам буде складніше розробити правильний код на основі цього несправного. Тоді ви або прямуєте до великого переписування, або до великої невдачі. І те, і інше вам слід уникати.

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


3

Спочатку потрібно розглянути визначення помилки:

  1. Прочитаний код не відповідає тому, що ви вважаєте правильним
  2. Програмне забезпечення не виконує належним чином своїх завдань

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

Те, що ви можете або не можете зробити з базою коду, яка може випадково ввести нові помилки, не має значення для погляду №2 щодо поточного програмного забезпечення. Однак, №1 має значення для вас або програміста з технічного обслуговування, що слідує за цим. Іноді важко вирішити, але коли конфлікт №2 та №1, ти повинен знати, що №2 явно важливіше.


2

Ні. Є третій спосіб: знайти спосіб довести, що "проблемний код" насправді викликає проблеми з бізнес-точки зору. Підтвердьте те, що ви знайдете в BA / QA або принаймні у вашого менеджера. Потім плануйте виправлення, коли всі знають про проблему.

Існує більше можливих сценаріїв, крім дійсних помилок у вказаних вами випадках:

  1. Код, який ви дивитесь, є деяким мертвим кодом. Це можливо тому, що, як сказав ysolik: клієнти завжди знаходять помилки. Якщо вони цього не зробили, можливо, код ніколи не виконується.
  2. Була ситуація з WTF, коли очевидна помилка мала своє призначення. (Ми говоримо про виробничий код, щось могло статися, правда?)
  3. Бізнес / клієнти вже знали про цю проблему, але не відчувають необхідності виправляти цю проблему.
  4. Можливо, більше ...

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


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

1
@David: не поширюй мою думку до невідповідної міри. Розробникам, безумовно, потрібне судження, але має бути межа. У цьому випадку розробники використовують своє судження, щоб виявити потенційну помилку та вжити подальших кроків для її вирішення.
Кодизм

2

Чи я:

  • виправити код і звинуватити його у злому? або
  • залишити помилку і звинуватити її, коли клієнт її знайде?

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

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


1
Або якщо ви використовуєте реєстр із встановленим кодом, встановіть це, щоб ви насправді не зафіксували зламаного коду.
Адам Лір

3
Тривати тривалий час - це не привід для вчинення кумедного коду.
Тобі

@Toby: Хто говорив про виправдання? Зараз я працюю в невеликій команді, навіть не півдесятка розробників. Одиничні випробування проекту займають 1 год. Наша політика полягає в тому, щоб запустити тести, які здаються пов’язаними з усім, що ви робите, а потім перевірити та дозволити CI з’ясувати, чи зламали ви щось, здавалося б, не пов’язане. Це не буде працювати у великій команді, але в маленькій це економить багато часу.
sbi

1

Виправте їх, якщо вони стають помилками збою / втратою даних. Доставка програми з відомою помилкою втрати даних - це явно шкідливо і недоцільно.

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

Зверніть увагу, як кожен більший програмний проект має розділ "Відомі проблеми" в ReadMe, який зазвичай перераховує саме те: Помилки, які відомі.

Знаючи про помилки та НЕ повідомляючи їх, IMHO прийнятний лише для дійсно незначних / косметичних помилок.


1

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

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


0

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

Пам'ятайте, що "ми знаємо про цю проблему і вирішимо її в майбутньому випуску" є синонімом "ми знаємо про цю проблему, але не дбаємо про вас достатньо, щоб уникнути її вирішення".


0

Правильний хід дій - ні ігнорувати помилку, ні «виправляти» її на місці; з тих самих причин, які ви визначили у своєму запитанні.

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

  • Історія : Використовуйте програмне забезпечення для управління версіями, щоб відповісти на запитання: Хто торкнувся коду? Що вони змінили? І з якими повідомленнями про фіксацію вони перевіряли? Чи можете ви зробити висновок про те, чому код виглядає так, як він є?

  • Використання : Який код використовує несправний код? І як? Чи код мертвий? Чи існує інший код, який спирається на помилкову поведінку?

  • Автор : Якщо ви не можете швидко дійти висновку, використовуючи інформацію, подану вище, запитайте у автора коду (принаймні, якщо це можливо), чому код виглядає так, як він є. Зазвичай ви отримаєте або "Оп, це слід виправити!" або "Ні! Не змінюйте це! Це потрібно саме так!" зразу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.