모든 개발이 브랜치에있을 때 리팩터링하는 방법?

우리 회사에서는 모든 개발 (버그 수정 및 새로운 기능)이 별도의 지점에서 수행됩니다. 완료되면 해당 지점에서 테스트하는 QA에게 전달하고 녹색 표시를 주 지점으로 통합합니다. 이 과정은 하루에서 1 년 정도 걸릴 수 있습니다.

브랜치에서 리팩토링을 짜려고 시도하는 경우 "아웃"기간을 알 수 없으므로 다시 병합 될 때 많은 충돌이 발생할 수 있습니다.

예를 들어, 작업중 인 기능 이이 기능을 많이 사용하고 있기 때문에 함수의 이름을 바꾸고 싶다고 가정 해 봅시다. 그래서 나는이 기능의 모든 사용법을 찾아서 모두 새로운 이름으로 바꾸고 모든 것이 완벽하게 작동하므로 QA로 보냅니다.

한편, 새로운 개발이 진행되고 있으며 이름이 바뀐 기능이 메인에서 분기되는 분기에 존재하지 않습니다. 내 문제가 다시 병합되면 모두 문제가 발생합니다.

이것을 다루는 방법이 있습니까?

경영진이 리 팩터 전용 문제를 승인하는 것과 같지 않으므로 다른 작업과 함께 압박해야합니다. 모든 변경 사항이 QA를 거쳐야하고 메인을 중단 한 사람이 아니기 때문에 본질적으로 직접 개발할 수 없으므로 약간의 비 필수 리팩토링을 수행 할 수 있습니다.

이 환경에서 리팩토링을 어렵게 만들기 위해 서로 혼합되는 몇 가지 문제가 있습니다. 여기에는 기술적이지 않은 몇 가지 문제가 있습니다 ( "관리 문제이며 아직 달성하지 못한 전투").

살펴볼 첫 번째 문제는 장기 실행 지점입니다. 이러한 지점은 개발자의 관점에서 변경 사항을 추적하는 데 어려움이 있습니다. 이 문제를 해결하려면

• 코드가 완성되면 코드를 한 번만 제공하고 (고객 지원팀에서 원하는 경우 살펴 보도록), 코드를 개발에 신속하게 병합하여 의존하는 다른 변경 사항을 포착하고 충돌하는 변경 사항을 조기에 식별 할 수 있습니다. 진행중.
• 리팩토링이 진행되는 동안 어떤 이유로 브 래치가 오래 걸리는 경우, 변경 사항 및 리팩토링을 취하기 위해 안정적인 지점에서 지점으로 병합하는 것이 좋습니다. 이것은 종종 피처 브랜치에서 안정적인 브랜치로 병합 할 때 충돌과 놀라움을 최소화합니다.
• 모든 통합 테스트는 기능이 아닌 릴리스에서 수행해야 합니다 . 이 환경에서 기능은 시스템과 완전히 통합되거나 통합되지 않을 수 있습니다. 기능에 대한 상태 점검을 단독으로 수행 할 수는 있지만 릴리스시 문제점을 식별하지는 않습니다.
• 코드 완성 시점부터 병합 시점까지 (마스터 / 안정적 / 릴리스에서 분기 할 경우 최신 개발 변경 사항을 적용하지 않는 자체 문제가 있음) 호출 시간이 너무 길지 않아야합니다. 더 오래 기다릴수록 지식이 손실되고 코드가 다른 코드 라인과 통합되기가 더 어려워집니다.

이것과 혼합되는 또 다른 문제는 위의 요점으로 언급 한 점은 시간이 지남에 따라 지점의 변화하는 역할입니다. 개발자가 커밋 한 개발 지점으로 시작한 다음 테스트 영역 (여기서는 응용 프로그램 전체에서 의미가있는 테스트가 수행되고 있습니까?)이 된 다음 안정적인 영역으로 병합됩니다 (아마도 릴리스 되었습니까? 다시 테스트 했습니까?).

기능 시작 시간이 짧을수록 다른 브랜치에서 리팩토링을 더 쉽게 선택할 수 있습니다.

개발자가 전체 환경을 갖도록 장려하십시오. 체리 따기 변경만으로도 흥미로운 개발자 환경을 말할 수 있습니다. 체리 피킹에는 그 용도가 있지만 변경 사항을 브랜치로 가져 오는 기본 모드이기 때문에 걱정할 수 있습니다.

리팩토링은 지속적으로 또는 다운 타임이 발생할 때마다 지속적으로 수행되는 것이 이상적입니다. 브랜치는 간단한 리팩토링을 수행하고 유닛 테스트를 실행하여 모든 것이 여전히 작동하는지 확인합니다 (유닛 테스트, 맞습니까 ? ) ? 다른 개발자가 정보를 전달하여 리팩토링 한 변경 사항을 자체 분기로 가져옵니다.

개발자는 코드의 품질을 소유하는 것이 중요합니다. 기능의 방향은 외부에서 나오고 시간 할당은 종종 우리 자신의 것이 아니지만 코드 품질은 자부심을 가지고 시간을 내야 할 필요가 있습니다.

기술 부채를 다루기위한 시간을 할당하는 데 도움이되는 다음과 같은 질문이 있습니다.

• 기술 부채가 기능이나 집안일 (또는 버그)로 예약되어야합니까?
• 경영진이 기술 부채를 처리하도록 설득하려면 어떻게해야합니까?
  • 이 질문 과 관련된 질문 도 살펴보십시오. 종종 가치가 있고 읽을만한 다른 질문에 인용됩니다.

리팩토링에 가장 필요한 코드 영역을 식별하는 데 도움이 되는 소나 와 같은 도구를 살펴볼 수도 있습니다 . 기술 부채 플러그인 코드베이스에서 시간이 지남에 따라 부채의 축적 도와 포인트로 사용할 수있는 무언가이다.

기술 부채 처리에 대한 ROI 가 개발 팀의 기능 및 버그 수정에 대한 처리 시간이 더 빠르다는 점을 지적해야 할 때가 있습니다.

일반적으로 현재 버전의 "병렬"로 리팩토링 된 버전을 개발하고 있습니다. 즉 동일한 코드베이스에서 핵심 응용 프로그램에서는 참조하지 않습니다. 그리고 새로운 솔루션이 수행되고 테스트되면 실제 리팩토링을 시작합니다.

예제 1. 내가 가지고 있다고 가정하면, 함수, 인터페이스, 모듈 또는 무엇이든하자. 그리고 나는 그것을 리팩토링하고 싶다. 동일한 코드베이스에서 Thing2를 작성 중이며 Thing의 리팩토링 버전입니다. 완료되고 테스트되면 Thing2를 대체하기 위해 Thing을 참조하는 모든 것을 리팩토링합니다. 일반적으로이 단계는 비교적 적은 시간이 걸립니다.

실제 리팩토링이 팀을 망치지 않고 동기화하는 데 너무 많은 시간이 걸리면 관련 기능을 모두 가져 와서 동시에 리팩토링합니다.

예 2. 새로운 렌더링 백엔드가 있는데, 이는 이전 버전의 리팩토링 된 버전입니다. 그러나 이전 렌더링 프론트 엔드와 호환되지 않습니다. 따라서 프론트 엔드를 리팩터링해야합니다. 그리고 다시 : 동일한 코드베이스에서. 모든 것이 끝나면 프론트 엔드 인스턴스 클래스를 변경하는 것이 이상적입니다. 짧은 커밋이 하나 이상 필요합니다.

재귀 적으로 모든 것이 병렬로 이루어져야 한다는 결론을 내릴 수 있습니다. 그러나 이것은 일반적으로 코드베이스에 커플 링이 너무 많거나 너무 빠르게 변경 될 때 발생합니다.

마지막으로, 새 코드가 통합되어 제대로 작동하면 코드베이스에서 이전 기능이 제거되고 새 기능의 이름이 바뀌어 이전 이름을 얻을 수 있습니다.

일반적으로 새로운 기능을 병렬로 준비하고 하나의 작은 단계로 사용하도록 전환하는 것이 좋습니다.

존 카맥 (John Carmack)은 아마도 자신의 블로그 포스트는 더 잘 설명이 (또는 적어도 비슷한에) 접근 방식을 사용 : (링크)

실제로 요구 사항 측면에있는 경우 기술 측면에서 어려움처럼 보일 수 있습니다.

개발이 다른 브랜치의 다른 요구 사항을 지향하는 경우에는 실제로 어려움이 있습니다. 팀의 관리자와 설계자는 다양한 비즈니스 요구가 공존 할 수있는 결정을 내려야합니다.

ZBB 프로세스와 Co-Dev는 모든 개발자의 관련 정보를 바탕으로 올바른 결정을 내린 후 "약속"합니다. 사후에 생각없이 필요한 것을 구현할 수 있도록해야합니다. 코드를 어떻게 병합합니까?

_{ZBB는 제로 기반 예산 책정을 나타냅니다 . Co-Dev라고 말하면 병렬 프로그래밍 작업을하는 사람들은 거의 없었습니다.}

문제는 당신이 가지에서 지나치게 오래 일하고있는 것 같습니다. 모든 사람이 지점에 머무르는 기간에 따라 갈등 비용이 기하 급수적으로 증가하므로 매우 긴 갈등으로 리팩토링을 수행 할 가능성이 거의 없습니다.

문제는 사용중인 지점 모델입니다. 지점에서 개발할 수 있으며 QA 준비가 완료되면 지점이 통합 또는 테스트라고하는 '중간 트렁크'로 병합됩니다. 다음 기능을 개발할 때이 중간 트렁크에서 분기 할 수 있습니다.

이 모델을 사용하면 서로 다른 브랜치에서 여러 기능을 병렬로 개발하여 통합 브랜치에 통합하여 QA로 보낼 수 있으며 단일 릴리스 트렁크를 유지할 수 있습니다 (인증 할 때 기본 트렁크에 수신 한 코드베이스 QA를 병합 함) )

QA에 전달 된 변경 사항은 큰 수정없이 전달 될 것이라고 가정합니다. QA 코드가 변경 사항을 제거하라는 지시와 함께 되돌아 오면 되돌려 야하지만 그렇지 않은 경우에는 변경 사항이 적용됩니다. 개발이 훨씬 매끄 럽습니다. 따라서 기본적으로 현재 코드 (현재 트렁크)가 아닌 메인 라인 코드 (예 : QA로 전달 된 코드 병합 후 트렁크)에서 새로운 기능의 분기를 수행하므로 더 이상 이전 릴리스의 코드베이스에 대해 개발되지 않습니다. .