나는 일반적으로 리팩토링을 처리하는 방법에 대한 최근 토론에 참여했다. 결국 다음과 같은 질문이 제기되었습니다.
누군가가 코드의 일부를 리팩토링했기 때문에 발생하는 병합 충돌을 어떻게 처리합니까? 다른 사람이 동일한 코드의 기능을 작업하고 있습니까?
기본적으로이를 효율적으로 처리하는 방법을 모르겠습니다. 이와 관련하여 따라야 할 모범 사례가 있습니까? 수많은 레거시 코드가있는 시스템에서이를 처리하는 방법에 차이가 있습니까?
답변:
좋은 질문. 내가 생각할 수있는 가장 좋은 전략은 다음과 같습니다.
지속적인 통합과 소규모 리팩토링 (종종 큰 리팩토링 대신)을 자주 수행하면 이러한 충돌의 비용과 빈도를 최소화 할 수 있습니다.
나는 당신의 질문에 대답하려고 생각합니다. 먼저 충돌이 발생하는 이유와 병합의 진정한 의미와 과정이 무엇인지 알아야합니다.
두 개 이상의 개발자가 작업을 할 때 충돌에만 발생 동일한 파일을 상기 동시에 그리고 그들은 모두 시도는 체크인 할 수 있습니다. 첫 번째 개발자는 물론, 충돌을받지 않습니다. 그러나 두 번째 (3, 4 등)는 충돌을 일으킬 것입니다. 이유는 서버의 기존 코드와 일부 또는 전체적으로 다른 코드가 있기 때문입니다.
이것은 본질적으로 두 번째 개발자가 첫 번째 개발자와 다른 것을 염두에두고 있음을 의미합니다. 이 차이는 언급 한 수준까지 사용 new UserManager().GetUserName()하는 것보다 스타일링에 따라 다를 수 있습니다. UserManager userManager = new UserManager(); userManager.GetUserName();즉, 개발자 모두 코드를 개선하기 위해 코드를 리팩토링하는 방법에 대한 아이디어가 서로 다릅니다.
반면에 병합한다고해서 개발자가 충돌을 고려하지 않고 코드를 체크인 할 수있는 것은 아닙니다. 그들은 해야 하고 있어야 그 갈등을 해결합니다. 충돌이 중요하지 않으면 체크인하고 이전 코드를 무시할 수 있습니다. 그러나 그들이 완전히 다른 것을 보았을 때, 그들은 이전 개발자에게 전화를 걸어서 그와 대화하여 최상의 솔루션을 체크인하기 위해 함께 협력 할 수 있도록해야합니다.
예를 들어 두 명의 개발자에게 온라인 지불 라이브러리 를 개선 하도록 요청 하고 작업이 겹치는 경우 적어도 일부 장소에는 두 가지 솔루션이 있음을 의미합니다. 따라서 이러한 솔루션 중 하나에 대해 더 나은 솔루션으로 이야기하고 수용해야합니다.
나는 우리가 이론적 인 것보다 실제적인 경향이 있기 때문에 이러한 상황 을 막는 것에 동의하지 않습니다 . 때로는 CSS에 능숙한 사람도 있고 ASP.NET 마크 업에 능숙한 사람도 있습니다. 그러나 로그인 페이지에서 작동해야 작동 할 때 작업이 충돌 할 수 있습니다. 우리가 진짜라고 생각하면 (이상적이지 않다),이 현상 (충돌)이 여러 번 발생한다는 것을 알 수 있습니다.
방금 언급하고 싶은 또 다른 요점은 체크인 프로세스에서 도움이되는 도구를 사용하는 것입니다. 이러한 도구는 일반적으로 서버 코드와 개발자 코드의 차이점을 시각화하고 체크인해야 할 부분을 결정하는 데 많은 도움이됩니다.
진행중인 작업 관리가 없으면 충돌이있는 것입니다.
그러나 매일 일 어설 회의 나 관리자 가있는 경우이 문제가 발생할 수 없습니다.
매일 일어나서 말하거나 관리자와 대화하십시오.
이것은 말을 통해 사소하게 방지됩니다.
병합이 가능한 한 간단해야합니다. 리팩토링 은 일반적으로 변수 선언, 공백 변경, 형식 지정, 작업 순서 등 많은 기존 줄 을 변경 하는 다소 기계적인 프로세스입니다 . 피처 생성 은 일반적으로 훨씬 더 창의적인 벤처이며, 종종 새로운 코드 와 기존 코드를 약간 조정 합니다. 이제 리팩토링을 수행하는 개발자가 단계를 기록하면 (예 : 정규식) 다른 방법이 아닌 추가 기능으로 코드에 적용하는 것이 훨씬 쉬울 수 있습니다. 이를 바탕으로, 일반적으로 가장 복잡한 변경 사항을 먼저 적용한 다음 점진적으로 간단한 변경 사항을 적용 해야한다고 말합니다 .