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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Другой

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

• Другой

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