팀 이름 변경, 리팩토링 및 변경 주요 변경에 대한 모범 사례

팀 환경에서 리팩토링하고 이름을 바꾸는 모범 사례는 무엇입니까? 몇 가지 시나리오를 염두에 두고이 작업을 수행합니다.

1. 일반적으로 참조되는 라이브러리가 리팩토링되어이를 참조하는 라이브러리 또는 프로젝트에 주요 변경 사항이있는 경우. 예를 들어, 메소드의 이름을 임의로 변경합니다.

2. 프로젝트의 이름이 바뀌고 업데이트 된 참조로 솔루션을 다시 빌드해야하는 경우

3. 폴더를 소개하고 기존 프로젝트 또는 솔루션을 새 위치로 이동하여 프로젝트 구조가 "보다 체계적으로"변경된 경우

몇 가지 추가 생각 / 질문 :

1. 이 문제와 같은 변화가 발생하거나 고통이 구조가 잘못되었다는 표시입니까?

2. 주요 변경과 관련된 오류를 수정하는 책임은 누구에게 있습니까? 개발자가 주요 변경 사항을 적용하는 경우 영향을받는 프로젝트에 참여하고 업데이트해야합니까? 아니면 다른 개발자에게 알리고 변경을 요청해야합니까?

3. 예약 된 방식으로 수행 할 수 있습니까? 아니면 가능한 한 자주 수행해야합니까? 리팩토링이 너무 오랫동안 연기되면 조정하기가 점점 어려워 지지만 동시에 다른 곳에서 발생하는 변경으로 인해 빌드를 수정하는 데 하루에 1 시간 씩 소비합니다.

4. 이것은 공식적인 의사 소통 과정의 문제입니까, 아니면 유기적 일 수 있습니까?

나열된 각 시나리오는 "게시 된 API / 코드"범주에 속합니다. 이것은 리팩토링하기 어렵 기 때문에 가볍게 변경해서는 안됩니다. 그보다는 계획된 변경 사항을 모든 관련 당사자와 미리 협상해야합니다. 최소한 기술적 문제만큼이나 정치적 문제입니다.

따라서 Martin Fowler의 이것에 관한 최고의 조언은 인터페이스 (프로젝트 이름 및 구조)를 조기에 게시하지 않는 것 입니다.

그러나 이미 완료되었고 수정이 필요한 경우 다른 당사자의 방해를 최소화하기 위해 가능한 한 적은 단계로 필요한 변경을 수행하는 것이 좋습니다. 이는 리팩토링의 원래 개념과는 상당히 거리가 멀지 만 그만한 이유가 있습니다.

또한 가능 하면 기존 방법의 이름을 바꾸는 대신 새 방법을 추가 (기존 방법은 사용하지 않음)하는 것을 고려 하십시오. 이를 통해 클라이언트 코드가 중단되지 않도록하고 최신 API를 준수하도록 코드를 업데이트 할 수있는 전환 기간을 제공합니다. 단점은 API가 복잡하다는 것입니다. 상태는 일시적이지만, 더 이상 사용되지 않는 API 메소드 (Java 클래스 라이브러리의 경우 몇 년)를 안전하게 제거하려면 상당한 시간이 걸릴 수 있습니다.

두 단계로 리팩토링하여 이러한 문제를 거의 항상 피할 수 있습니다. 첫 번째 단계에서 새 코드를 소개하고 이전 코드를 폐기하십시오. 모든 팀이 새 코드로 마이그레이션하면 이전 코드를 삭제하십시오. 또한이 기법을 사용하여 단일 모듈을 점진적으로 리팩터링합니다. 이런 식으로 테스트 실행간에 변경해야하는 코드의 양을 제한 할 수 있습니다.

이것이 테스트를 실행하는 빌드 서버가있는 주요 이유 중 하나입니다.

주어진 프로그램을 망칠 수있는 일이 발생하면 가능한 한 빨리 통보를받으며 세부 사항이 여전히 최신 상태 인 동안 범인을 찾아 문제를 해결할 수 있습니다.