Виправлення помилки, яка досі ніколи не викликала проблем

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

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

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

Чи варто це все-таки виправити?

Оновлення

Ведучий технічно не має ніяких повноважень щодо мене. Справедливість. Він був єдиним розробником проекту протягом багатьох років до року тому, і я думаю, що він не сприймає конструктивної критики дуже добре. Що варто, я його не критикував. Я щойно зазначив, що те, що помилка ніколи не з’явилася, не означає, що її там немає.

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

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

Якщо ваш головний розробник - ваш начальник, і він каже, що не торкайтеся цього, я б цього не зробив.

Більшість відповідей та коментарів пропонували пом'якшити відповідальність за рішення, створивши звіт про помилку та дозволивши комусь іншим телефонувати.

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

Не ідеальне рішення, але принаймні помилка була виправлена ​​належним чином.

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

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

Тут у мене є принаймні кілька різних варіантів:

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

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

Хоча мій інстинкт міг би виправити помилки, а не приховати проблему, є сценарії, коли я затримаю ніс і приховую проблему.

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

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

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

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

Виходячи з двох ваших коментарів про помилки showstopper, найкращим вибором може бути дотримання букви закону, але ігнорування його духу.

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