대규모 코드 기반과 많은 개발자를 통해 리팩토링을 어떻게 관리합니까?

두 개발자가 먼저 이야기하지 않고 동일한 코드를 동시에 리팩터링하는 상황을 방지하고 싶습니다. 어쩌면 어떤 종류의 도구, 아마도 Eclipse 플러그인을 사용합니다. 도울 수 있니?

우리는 450 만 라인의 코드와 4 개 대륙의 20 개 이상의 개발자 팀을 보유하고 있습니다.

이상적으로는 앞서 언급 한 두 번째 개발자가 다른 사람이 동일한 코드 조각을 작업 중이며 첫 번째 코드와 대화하여 내용을 수정하기를 원합니다.

해결책을 알고 있습니까?

많은 2 세대 소스 제어 시스템은 연결된 "체크 아웃"을 사용하여 서버에 파일을 수정하려고 함을 알려줍니다. 예로는 TFS, SourceGear Vault 등이 있습니다. 이러한 방식으로 요구 사항을 기술적으로 달성 할 수 있습니다 . 그러나 Adam Butler가 지적했듯이 이러한 유형의 도구에는 긴 토론에 참여하지 않고 오프라인 작업에 대한 제한적인 지원과 일반적으로 비생산적인 개발 워크 플로와 같은 자체 문제가 있습니다.

리팩토링 작업을 할당하는 일종의 계층 적 접근 방식을 제안합니다. 개발자는 코드의 특정 영역을 담당하는 하위 팀으로 논리적으로 그룹화 할 수 있습니다. 팀 구성 방법에 따라 각 팀은 팀 영역의 고급 디자인을 담당하는 "리드"역할을 수행 할 수 있습니다. 이 구조는 개발자에게 잘 알려져 있어야하며 리팩토링을위한 통신을 단순화해야합니다. 나는이 접근 방식이 너무 형식적이고 일부에는 뒤 떨어질 것이라고 확신하지만, 20 명 이상의 개발자가 큰 시스템을 리팩토링하기 위해 "무료"접근 방식을 사용하는 것이 매우 바람직하다고 생각합니다. 일부 리팩토링은 상위 수준에서 수행됩니다 (예 : 모듈 X가 모듈 Y와 통신하는 방법). 이 경우 적절한 수준에서 전화를 걸 수있는 사람들이 필요합니다. 팀의 모든 개발자가 아키텍처 결정을 내려야하는 것은 아니기 때문에, 어떤 경우에도 계층 구조가 무시됩니다.

기본적으로, 여러분이 제시 한 기본 요구 사항을 충족시키는 도구가 있지만 적절한 의사 소통을 대체하고 소수의 사람들이 프로젝트의 일반 아키텍처를 추진하는 도구는 없습니다.

1. 개발자에게 특정 모듈이 지정되어 있는지 확인하십시오.
2. 모든 리팩토링 변경을 추적하는 작업 / 버그 추적 시스템을 갖추십시오. 각 이슈를 한 명의 개발자에게만 할당
3. 일부 버전 제어 시스템에는 파일을 잠그는 기능이있어 한 명의 개발자 만 파일에 대한 업데이트 권한을 가질 수 있습니다. 필자는이 기능을 사용한 적이 없지만 개발자가 지속적으로 서로 단계별로 지원하는 경우 고려해야 할 사항입니다.
4. 개발자가 동일한 파일로 작업하더라도 변경 사항이 앱을 중단시키지 않는 단위 테스트를 수행하십시오.
5. 리팩토링이 모듈 내에 포함되어 있으면 위의 모든 것이 도움이 될 것입니다. 그러나 누군가가 로깅이나 보안과 같은 교차 문제에 대해 리팩토링을 수행하는 경우 정의에 따라 많은 파일에 영향을 미칩니다. 이미 aop 접근 방식을 활용하지 않은 경우 특히주의해서 다루어야합니다.

개발자가 편집하기 전에 코드를 체크 아웃하도록하는 버전 제어 시스템이 있지만 여기에는 고유 한 문제가 있습니다. 더 나은 방법은 개발자가 자주 커밋하고 업데이트하도록하는 것입니다. 한 개발자는 클래스를 감가 상각 된 것으로 표시하고 다른 개발자가 리 팩터를 시작하기 전에 업데이트하면 의도를 볼 수 있습니다.

기술은 사회적 문제를 해결할 수 없습니다. 개발자가 서로 대화하고 작업을 조정하도록해야합니다. 20 개 팀으로 구성하면 일부 구조와 규칙이 필수적입니다. 기술 솔루션으로 지원하고 싶지만 사람들이 먼저옵니다.

notice that someone else is working on the same piece of code and talk to the first one before modifying anything당신이 말한대로, 떠나면 버전 제어 시스템 (CVS / SVN / GIT)이 필요합니다. 확실하지는 않지만 포함 시키려면 고급 기능이 필요합니다 (일부 트리거 메커니즘 / 사용자 지정 기능).

소스 제어에서 파일을 잠그는 개발자는 문제를 쉽게 해결해야하지만 더 큰 문제가 있다고 생각합니다.

4.5 백만 LOC는 잘 설계되고 설계된 솔루션에서 사용할 수있는 방대한 샌드 박스이므로 여러 팀의 개발자가 서로 발을 딛는 상황에는 거의 빠지지 않아야합니다. 이것이 우연히 발생하는 것 이상으로 발생한다는 사실은 고려해야 할 심각한 잠재적 인 설계 결함을 말하는 것입니다.

몇 가지:

1. 작업 할 별도의 모듈
2. 변경하기 전에 모든 개발자와 대화하기
3. 단위 테스트 [관련 사항을 확인하고 피하기 위해]
4. 다른 사람들이 VCS를 언급했듯이