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

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

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

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

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

Обновить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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