Отслеживание рефакторинга в базе данных ошибок

Question

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

• Напишите отчет об ошибке и свяжите с ним рефакторинг.
• Напишите запрос на добавление функции и свяжите с ним рефакторинг.
• Выполняйте рефакторинг, работая над кодом, который связан с отчетом об ошибке/запросом функции.
• Просто не делайте рефакторинга.
• Другой

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

Answer 1

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

Answer 2

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

Answer 3

Как мы работаем:Должна быть веская причина для рефакторинга кода, иначе зачем?

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

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

Если речь идет о разработке ошибки, зарегистрируйте ее.

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

Answer 4

Давайте рассмотрим каждый вариант:

• Напишите отчет об ошибке и свяжите с ним рефакторинг.

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

• Напишите запрос на добавление функции и свяжите с ним рефакторинг.

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

• Выполняйте рефакторинг, работая над кодом, который связан с отчетом об ошибке/запросом функции.

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

• Просто не делайте рефакторинга.

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

• Другой

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

Answer 5

• Другой

Если вы работаете в месте с такой негибкой (и нелепой) политикой, лучшее решение — найти другую работу!