Исправление ошибки, которая до сих пор не вызывала проблем

20

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

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

Мне ясно, что до сих пор нам просто везло, но он не будет слушать причину.

Должен ли я это исправить в любом случае?

Обновить

Технически лидерство не имеет никакого отношения ко мне. Просто владение. Он был единственным разработчиком проекта в течение ряда лет, пока год назад, и я думаю, что он не очень хорошо воспринимает конструктивную критику. За что я не критиковал его. Я только что указал, что просто потому, что ошибка никогда не обнаруживалась, не означало, что ее там не было.

Кеннет Кокран
источник
Это ошибка, связанная с многопоточностью или что-то еще?
TheLQ
3
Он босс по причине. Когда корма поражает поклонника, он будет тем, кого они жарят. Если он поджарится, потому что вы не сделали то, что он просит, тогда вам понадобится большое весло.
Мартин Йорк,
3
Можете ли вы построить случай, когда ошибка возникает даже после отмены изменений? Если нет, то, возможно, это не ошибка, а недокументированное ограничение fea ^ H ^ H ^ H ^ Hn.
Steve314
3
Хм, «Если он сломан, открой еще что-нибудь». - Ну, это новая интерпретация, я дам ему это.
Orbling
1
"Если это не сломано, не чини это"? Но это сломано.
StuperUser

Ответы:

26

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

Райан Хейс
источник
9
Помните:
прикрывайте
1
Не так повезло. Все в штанах. Нет отслеживания ошибок, нет сбора требований, нет тестирования. Вероятно, даже не будет контроля версий, если руководство не настаивает на этом.
Кеннет Кохран,
18
Исходя из вашего описания вашей рабочей среды, вы должны были кивнуть и улыбнуться, когда ведущий разработчик сказал вам не исправлять это, а затем пойти дальше и сделать то, что вы хотели сделать в любом случае.
Carson63000
2
И не задавайте такие вопросы в следующий раз :-)
gruszczy
2
@codeelegance: «Без отслеживания ошибок, без сбора требований, без тестирования. Вероятно, даже не было бы контроля версий, если бы руководство на этом не настаивало». - Сладкая Мария Богородица !! 1 !! Эта среда стоит в полной иронии к вашему имени пользователя. :)
Бобби Таблицы
8

Лично я бы это исправил, если бы на это не потребовалось значительно больше усилий, чем оно того стоило. «Если ничего не сломано, не почините» - это ужасно, если применить к программному обеспечению.

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

JZD
источник
2
Как поздно они в цикле? Это может быть потенциальным самоубийством.
Работа
8
«Если ничего не сломано, не чините его» - это очень хорошее правило для применения к программному обеспечению - только не тогда, когда оно сломано.
Steve314
Если это не сломано, не исправляйте это, это относится к программному обеспечению в зависимости от определения поврежденного кода. В тот самый момент, когда вы садитесь и смотрите на код, который, очевидно, необходимо исправить, он становится неработоспособным. В тот самый момент, когда вы начинаете реализовывать обходные пути для сломанного кода, вы фактически работаете в обратном направлении, и со временем сломанный код будет все труднее и труднее исправить ...
Эрнелли
2

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

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

Не идеальное решение, но, по крайней мере, ошибка была исправлена ​​правильно.

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

Напомните ему фразу: «Если это не сломано, не исправляйте это», а не «Если клиент не заметил это, не исправляйте это».

Дэн Диплом
источник
1

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


На мой взгляд, у вас есть по крайней мере несколько вариантов:

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

Если вы делаете то, что вам было сказано, это просто вина, или проблема в этом? Мне интересно, что здесь не так, кроме того, что называется принципами и ценностями. Я имею в виду это как шутку, а также честный вопрос о том, что не так с этой идеей?

JB King
источник
Изменение было необходимо, чтобы исправить еще одну ошибку. Ведущий предложил поставить условные обозначения, которые ограничивают частоту выполнения кода, а не исправляют причину ошибки. И ошибка, которую я исправил, и та, которую я обнаружил, являются пробками показа.
Кеннет Кокран,
3
В этом случае это должно быть исправлено. Использование условий, охватывающих проблему, просто откладывает катастрофу И добавляет новый код, который больше не работает. Это плохое (даже глупое) решение.
quick_now
1

Хотя мой непреодолимый инстинкт состоял бы в том, чтобы исправить ошибки, чтобы не скрывать проблему, существуют сценарии, когда я держу свой нос и скрываю проблему.

  1. Код используется внутри компании и иногда, поэтому последствия ошибки могут быть устранены внутри компании.
  2. Огромные коммерческие соображения, которые требовали доставки сегодня, и исправление ошибки может быть выпущено через 2 недели с минимальными последствиями.

С профессиональной точки зрения, мне не нравятся эти ответы, и я буду внутренне разъяснять, что происходит в этих ситуациях.

Майкл Шоу
источник
0

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

Pemdas
источник
0

Скопируйте ошибочную функцию, примените исправление, переименуйте его, возможно, немного замаскируйте, и вместо этого вызовите его.

Основываясь на ваших двух комментариях к ошибкам в Showtopper, ваш лучший выбор может заключаться в том, чтобы следовать букве закона, но игнорировать его дух.

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

Steve314
источник
1
Плохая идея, если бы я поймал одного из моих программистов, делающего что-то подобное, я бы уволил его на месте, это гарантированный способ нанести ущерб коду и любому, кто должен поддерживать этот код.
Мики Уоттс
@Miki - в этом случае, скажите мне точно, что не плохая идея? Пожалуйста, объясните, как исправить ошибку, потому что она сделала другую ошибку (которая была в любом случае) более заметной - это хорошо. Что касается стрельбы на месте, я бы поспорил с конструктивным увольнением, так как у разработчика не было иного выбора.
Steve314