Разрешение конфликтов слияния из-за рефакторинга

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

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

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

Хороший вопрос. Лучшая стратегия, о которой я могу подумать:

профилактика

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

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

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

Это по своей природе означает, что второй разработчик имеет в виду нечто иное, чем первый разработчик. Это различие может отличаться от стиля, например, new UserManager().GetUserName()вместо использования UserManager userManager = new UserManager(); userManager.GetUserName();до упомянутого вами уровня, что означает, что оба разработчика имели разные идеи о том, как реорганизовать код для его улучшения.

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

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

Я не согласен с тем, чтобы предотвратить эти обстоятельства, поскольку мы должны быть более реальными, чем теоретическими. Иногда один парень действительно хорош в CSS, а другой - в ASP.NET Markup. Но их работа может конфликтовать, когда они оба должны работать на странице входа в систему, чтобы заставить его работать. Я имею в виду, что если мы думаем реальным (не идеальным), мы можем видеть, что много раз это явление (конфликт) происходит.

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

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

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

Либо поговорите (через ежедневное вставание), либо поговорите с менеджером.

Это легко предотвратить разговором.

У вас есть отдельная общая ветка для разработки определенной функции, часто объединяйте / вытягивайте / толкайте - и все.

И общаться . Поговорите с другими разработчиками о коде даже при запуске. Даже при кодировании)))

Убедитесь, что объединение максимально простое. Рефакторинг обычно представляет собой довольно механический процесс, который изменяет многие существующие строки : перемещение объявлений переменных, изменения пробелов, форматирование, последовательность операций. Создание функций, как правило, является гораздо более творческим предприятием, часто приводящим к новому коду и небольшим изменениям в существующем коде. Теперь, если разработчик, выполняющий рефакторинг, записывает шаги (например, как регулярные выражения), может быть намного проще применить их к коду с дополнительной функциональностью, а не наоборот. Исходя из этого, я бы сказал, что по общему правилу вы должны сначала применить самое сложное изменение, а затем постепенно упрощенные изменения.