Недавно я участвовал в дискуссии о том, как проводить рефакторинг в целом (что само по себе является интересной темой). В конце концов был поднят следующий вопрос:
Как можно обрабатывать конфликты слияния, возникающие из-за того, что кто-то выполнял рефакторинг части кода, в то время как кто-то еще работал над функцией для того же куска кода?
По сути, я понятия не имею, как с этим справиться эффективно. Есть ли лучшие практики, которые следует соблюдать в отношении этого? Есть ли какая-то разница в том, как с этим обращаться в системе с тоннами устаревшего кода?
version-control
refactoring
legacy
Андреас Йоханссон
источник
источник
Ответы:
Хороший вопрос. Лучшая стратегия, о которой я могу подумать:
профилактика
Сочетание непрерывной интеграции и частых небольших рефакторингов (вместо случайных больших рефакторингов) будет иметь большое значение для минимизации стоимости и частоты таких конфликтов.
источник
Я думаю, чтобы ответить на ваш вопрос, сначала мы должны понять, почему происходят конфликты, и каково истинное значение и процесс слияния?
Конфликты возникают только тогда , когда два или более разработчиков работают на том же файле в то же время , а затем они оба пытаются проверить. Первый разработчик не получит какой - либо конфликт, конечно. Но второй (третий, четвертый и т. Д.) Получит конфликты. Почему, потому что у него есть некоторый код, который частично или полностью отличается от существующего кода на сервере.
Это по своей природе означает, что второй разработчик имеет в виду нечто иное, чем первый разработчик. Это различие может отличаться от стиля, например,
new UserManager().GetUserName()вместо использованияUserManager userManager = new UserManager(); userManager.GetUserName();до упомянутого вами уровня, что означает, что оба разработчика имели разные идеи о том, как реорганизовать код для его улучшения.Слияние, с другой стороны, не означает, что разработчики могут зарегистрировать свой код без учета конфликтов. Они должны и должны решать эти конфликты. Если конфликты не важны, они могут проверить и переопределить предыдущий код. Но когда они видят что-то совершенно другое, им следует позвонить предыдущему разработчику и поговорить с ним, чтобы они оба могли скоординироваться друг с другом, чтобы найти лучшее решение.
Например, если вы попросите двух разработчиков улучшить библиотеку онлайн-платежей, и их работа пересекается, это означает, что, по крайней мере, в некоторых местах есть 2 разных решения. Итак, об одном из этих решений следует поговорить и принять, таким образом, отмеченное как лучшее решение.
Я не согласен с тем, чтобы предотвратить эти обстоятельства, поскольку мы должны быть более реальными, чем теоретическими. Иногда один парень действительно хорош в CSS, а другой - в ASP.NET Markup. Но их работа может конфликтовать, когда они оба должны работать на странице входа в систему, чтобы заставить его работать. Я имею в виду, что если мы думаем реальным (не идеальным), мы можем видеть, что много раз это явление (конфликт) происходит.
Еще один момент, о котором я только хотел упомянуть, - это использование инструментов, которые помогут вам в процессе регистрации. Эти инструменты обычно визуализируют различие кода сервера и кода разработчика и очень помогают в определении того, какая часть должна быть проверена.
источник
Если нет активного управления задачами, у вас есть конфликты.
Однако, если у вас есть ежедневная встреча или менеджер , у вас не может быть этой проблемы.
Либо поговорите (через ежедневное вставание), либо поговорите с менеджером.
Это легко предотвратить разговором.
источник
У вас есть отдельная общая ветка для разработки определенной функции, часто объединяйте / вытягивайте / толкайте - и все.
И общаться . Поговорите с другими разработчиками о коде даже при запуске. Даже при кодировании)))
источник
Убедитесь, что объединение максимально простое. Рефакторинг обычно представляет собой довольно механический процесс, который изменяет многие существующие строки : перемещение объявлений переменных, изменения пробелов, форматирование, последовательность операций. Создание функций, как правило, является гораздо более творческим предприятием, часто приводящим к новому коду и небольшим изменениям в существующем коде. Теперь, если разработчик, выполняющий рефакторинг, записывает шаги (например, как регулярные выражения), может быть намного проще применить их к коду с дополнительной функциональностью, а не наоборот. Исходя из этого, я бы сказал, что по общему правилу вы должны сначала применить самое сложное изменение, а затем постепенно упрощенные изменения.
источник