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

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

• Другое

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

Answer 5

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

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

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

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

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

• Проникнуть в рефакторинг при работе с кодом, связанным с сообщением об ошибке / запросом функции.

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

• Только не делайте рефакторинга.

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

• Другое

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