Стоит ли исправлять существующие дефекты, работая над чем-то другим?

Загадка: во время работы над новой функцией или исправления дефекта вы обнаружите унаследованную проблему в коде. Что вы должны сделать? Исправьте это и рискуйте изменить поведение кода. Он либо до сих пор работал какой-то случайностью, либо дефект не был обнаружен или стоил чьего-либо времени сообщать. Стоит ли оставить это в покое и позволить проблеме усложнить работу с кодом позже? Решение проблемы только добавит времени к исходному заданию и заставит вас пройти регрессионный тест. Мало кто оценит работу. Однако исправить это кажется правильным. Код с меньшим количеством проблем проще реорганизовать и использовать.

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

Спасибо Кори

Я работаю в очень маленькой команде, так что это отчасти зависит от изменений:

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

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

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

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

РЕДАКТИРОВАТЬ: Вы также должны следить за своим временем на проекте. Очевидно, что в сжатые сроки вы должны сосредоточиться на выполнении основной работы, но если вы просто находитесь под «нормальной нагрузкой», то я думаю, что небольшая уборка здесь и там делает всех счастливее в долгосрочной перспективе.

Как всегда, это зависит.

• Если это тривиально, и вы уверены, что можете это исправить, исправьте это.
• Если есть много модульных тестов, так что вы можете быть уверены, что ничего не сломали, исправьте это.
• В противном случае, добавьте // TODO, добавьте его в отслеживание ошибок, что угодно

По сути, вы проводите оценку риска: каков риск изменения, а не изменения. Если вы не чувствуете, что у вас достаточно опыта (с программированием в целом или системой в частности), спросите кого-то еще в команде.

Прагматичный программист называет их «разбитыми окнами».

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

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

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

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

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

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

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

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

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

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

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

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

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

Проведите формальное обсуждение (например, на обычной встрече) или неформальное обсуждение (например, во время обеда) со своими коллегами и внесите изменения после того, как вы получите больше уверенности в поведении кодов, которые вы собираетесь исправить.

Хотя это кажется вам ошибкой / дефектом, на этот раз это может быть «фича». Это может быть плохо реализованное решение, позволяющее обойти некоторые крайние случаи в последнюю минуту предыдущего выпуска, и ваше «чистое исправление» может восстановить некоторые ранее решенные проблемы.

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

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