Рефакторинг и нерефакторинг изменений как отдельные проверки?

Question

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

Answer 1

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

Answer 2

Сохраняйте это простым.

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

• У меня есть две рабочие папки
• Обе папки извлекаются из одной ветви
• Я использую одну папку для реализации новой функции разработки / исправления ошибок
• В другой папке я делаю рефакторинг,
• После каждого рефакторинга я проверяю в папке рефакторинга
• Затем обновите новую папку для разработки функций, которая сливается с моими рефакторингами

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