리팩토링 후 팀에서 빈번한 오류를 피하려면 어떻게해야합니까?

약간의 배경 지식을 제공하기 위해 : 대략 12 명의 Ruby on Rails 개발자 (+/- 인턴)를 가진 회사에서 일합니다. 원격 작업이 일반적입니다. 우리의 제품은 두 가지 부분으로 구성되어 있습니다 : 오히려 뚱뚱한 핵심과 그 위에 세워진 큰 고객 프로젝트까지 얇습니다. 고객 프로젝트는 일반적으로 핵심을 확장합니다. 주요 기능을 덮어 쓰지 않습니다. 코어에는 리팩토링이 절실히 필요한 일부 나쁜 부분이 있다고 덧붙였습니다. 사양은 있지만 대부분 고객 프로젝트에 적용됩니다. 코어의 최악의 부분은 테스트되지 않은 것입니다 (그렇지 않아야합니다 ...).

개발자는 두 개의 팀으로 나뉘며 각 스프린트마다 하나 또는 두 개의 PO로 작업합니다. 일반적으로 하나의 고객 프로젝트는 팀 및 PO 중 하나와 엄격하게 연관됩니다.

이제 우리의 문제 : 오히려 자주 서로의 문제를 해결합니다. 팀 A의 누군가가 핵심 기능 Y를 확장하거나 리팩터링하여 팀 B의 고객 프로젝트 중 하나에 예기치 않은 오류가 발생합니다. 대부분 변경 사항이 팀 전체에 발표되지 않으므로 버그는 거의 항상 예상치 못한 것입니다. PO를 포함한 팀 B는 기능 Y가 안정적이라고 생각하고 변경 사항을 알지 못하고 릴리스하기 전에 테스트하지 않았습니다.

이러한 문제를 해결하는 방법은 무엇입니까? 어떤 종류의 '발표 기술'을 추천 해 주시겠습니까?

Michael C. Feathers의 레거시 코드로 효과적으로 작업하기를 읽는 것이 좋습니다 . 자동화 된 테스트가 필요하고 쉽게 추가 할 수있는 방법, 아직없는 경우 리 코드하기 위해 어떤 "코드 냄새"가 필요한지 설명합니다.

게다가, 당신의 상황에서 또 다른 핵심 문제는 두 팀 간의 의사 소통이 부족한 것 같습니다. 이 팀은 얼마나 큽니까? 그들은 서로 다른 백 로그에서 작업하고 있습니까?

아키텍처에 따라 팀을 분할하는 것은 거의 항상 나쁜 습관입니다. 핵심 팀과 비 핵심 팀. 대신 기능 영역에서 팀을 만들고 구성 요소 간을 만들었습니다.

우리는 코어의 최악의 부분이 테스트되지 않았습니다.

이게 문제 야. 효율적인 리팩토링은 일련의 자동화 된 테스트에 크게 좌우됩니다. 그것들이 없으면 설명하는 문제가 나타나기 시작합니다. 이는 메소드를 매개 변수를 전달하는 것과 관련된 기본 오류를 포착 할 컴파일러가없는 Ruby와 같은 동적 언어를 사용하는 경우 특히 중요합니다.

더 나은 단위 테스트를 지시하는 이전 답변은 좋지만 더 근본적인 문제가 있다고 생각합니다. 고객 프로젝트 코드에서 핵심 코드에 액세스하려면 명확한 인터페이스가 필요합니다. 이런 식으로 인터페이스를 통해 관찰 된 동작을 변경하지 않고 핵심 코드를 리팩터링 하면 다른 팀의 코드가 중단되지 않습니다. 이를 통해 "안전하게"리팩토링 할 수있는 것과 인터페이스를 깨뜨릴 수있는 디자인이 필요한 것이 무엇인지 쉽게 알 수 있습니다.

다른 답변은 중요한 포인트 (더 많은 단위 테스트, 기능 팀, 핵심 구성 요소에 대한 깨끗한 인터페이스)를 강조했지만 버전이 누락 된 것으로 나타났습니다.

릴리스 ¹ 을 수행하여 코어의 동작을 정지시키고 해당 릴리스를 개인 아티팩트 관리 시스템 ^2에 넣으면 모든 고객 프로젝트가 코어 버전 X 에 대한 종속성을 선언 할 수 있으며 다음 릴리스 X에 의해 중단되지 않습니다. + 1 .

"발표 정책"은 각 릴리스와 함께 CHANGES 파일을 갖거나 팀 회의를 통해 새로운 각 코어 릴리스의 모든 기능을 발표하는 것으로 줄어 듭니다.

또한 "핵심"을 정의하고 그 핵심 부분을 "핵심"으로 더 잘 정의해야한다고 생각합니다. "핵심 구성 요소"를 많이 변경하지 않는 것처럼 보이지만 "핵심"을 자주 변경할 수 있습니다. 무언가에 의존하기 위해서는 안정된 상태를 유지해야합니다. 무언가가 안정되지 않으면 그것을 핵심이라고 부르지 마십시오. 어쩌면 "도움말"구성 요소라고 할 수 있습니까?

편집 : 시맨틱 버전 관리 시스템 의 규칙을 따르는 경우 코어 API의 호환되지 않는 변경 사항은 주요 버전 변경 사항 으로 표시되어야합니다 . 즉, 기존 코어의 동작을 변경하거나 무언가를 제거 할 때 단순히 새로운 것을 추가하는 것이 아닙니다. 이러한 규칙을 통해 개발자는 '1.1'에서 '1.2'로 업데이트하는 것이 안전하지만 '1.X'에서 '2.0'으로 변경하는 것은 위험하므로 신중하게 검토해야합니다.

^{1 : 나는 이것이 Ruby의 세계에서 보석이라고 생각합니다
.Java의 Nexus 또는 Python의 PyPI와 같습니다.}

다른 사람들이 말했듯이, 우수한 단위 테스트 세트는 문제를 해결하지 못합니다. 각 팀 테스트 스위트가 통과하더라도 변경 사항을 병합하는 동안 문제가 발생합니다.

TDD와 동일합니다. 어떻게 해결할 수 있는지 모르겠습니다.

귀하의 솔루션은 비 기술적입니다. "핵심"경계를 명확하게 정의하고 "개발자 또는 설계자"인 누군가에게 "감시견"역할을 할당해야합니다. 코어에 대한 모든 변경 사항은이 워치 독을 통과해야합니다. 그는 모든 팀의 모든 산출물이 너무 많은 부수적 피해없이 합병되도록 할 책임이 있습니다.

보다 장기적인 해결책으로 팀 간의보다 나은 적시 커뮤니케이션이 필요합니다. 핵심 기능 Y와 같이 계속 사용할 각 팀은 기능에 대해 계획된 테스트 케이스를 작성하는 데 참여해야합니다. 이 계획 자체는 두 팀 간의 기능 Y 고유의 다양한 사용 사례를 강조합니다. 기능의 작동 방식이 결정되고 테스트 사례가 구현되고 합의되면 구현 체계에 추가 변경이 필요합니다. 기능을 릴리스하는 팀은 기능을 사용하려는 팀이 아닌 테스트 케이스를 실행해야합니다. 충돌이 발생하는 작업은 팀 중 하나에서 새로운 테스트 케이스를 추가하는 것입니다. 팀원이 테스트되지 않은 기능의 새로운 측면을 생각할 때 자신의 샌드 박스를 통과 한 것으로 확인 된 테스트 케이스를 자유롭게 추가 할 수 있어야합니다. 이러한 방식으로 발생하는 유일한 충돌은 의도 수준이며 리팩토링 된 기능이 완전히 공개되기 전에 해결해야합니다.

모든 시스템에는 효과적인 테스트 스위트 (즉, 자동화)가 필요하지만 이러한 테스트가 효과적으로 사용되면 이러한 충돌을 현재보다 빨리 포착 할 수 있지만 근본적인 문제는 해결하지 못합니다.

이 질문은 적어도 두 가지 근본적인 문제, 즉 개별 고객의 요구 사항을 충족시키기 위해 '핵심'을 수정하는 관행과 팀이 변경 의사를 의사 소통하고 조정하지 못하는 문제를 드러냅니다. 이들 중 어느 것도 근본 원인이 아니므로이를 해결하기 전에 이것이 수행되는 이유를 이해해야합니다.

가장 먼저 결정해야 할 사항 중 하나는 개발자와 관리자가 여기에 문제가 있음을 인식하는지 여부입니다. 적어도 일부 사람들이 그렇게한다면, 그들이 그들에 대해 아무 것도 할 수 없다고 생각하거나하지 않기로 선택한 이유를 찾아야합니다. 그렇지 않은 사람들을 위해, 현재의 행동이 미래의 문제를 어떻게 만들 수 있는지 예측할 수있는 능력을 향상 시키거나이를 가능한 사람들로 대체 할 수 있습니다. 일이 어떻게 잘못되고 있는지를 아는 인력이있을 때까지는 문제를 해결할 수 없을 것입니다.

최소한 초기에는 문제를 추상적 인 용어로 분석하기 어려울 수 있으므로 문제를 일으킨 특정 사건에 초점을 맞추고 문제가 어떻게 발생했는지 확인하십시오. 관련된 사람들이 방어적일 가능성이 높으므로 실제로 일어나는 일을 찾으려면 자급 및 사후 정당화에주의해야합니다.

고객의 요구 사항이 너무 이질적이므로 공유 코어 코드를 정당화하기에는 공통점이 충분하지 않습니다. 그렇다면 실제로 여러 개의 개별 제품이 있으므로 해당 제품을 관리해야하며 제품간에 인위적인 연결을 생성하지 않아야합니다.

우리는 모두 단위 테스트가 진행된다는 것을 알고 있습니다. 그러나 우리는 이것들을 코어에 현실적으로 개조하는 것이 어렵다는 것을 알고 있습니다.

기능을 확장 할 때 유용 할 수있는 특정 기술은 기존 기능이 변경되지 않았는지 일시적으로 로컬에서 확인하는 것입니다. 이것은 다음과 같이 수행 할 수 있습니다 :

원래 의사 코드 :

def someFunction
   do original stuff
   return result
end

임시 현장 테스트 코드 :

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

존재하는 시스템 레벨 테스트를 통해이 버전을 실행하십시오. 모든 것이 괜찮다면, 당신은 당신이 물건을 깨지 않았 음을 알고 오래된 코드를 제거 할 수 있습니다. 당신은 과거와 결과가 일치 검사 할 때, 당신은 또한 당신이 알고 캡처의 경우에 차이를 분석하는 코드를 추가 할 수 있음을주의 해야한다 이러한 버그 수정으로 인해 의도 된 변화 다를 수 있습니다.

"버그가 거의 항상 예상치 못한 공격 때문에 대부분의 변화는 팀을 통해 발표되지 않은"

통신 문제 누군가? 적절한 의사 소통이 있는지 확인하기 위해 (다른 사람들이 이미 지적한 것 외에도 엄격한 테스트를 받아야 함) 어떻습니까? 사람들은 그들이 작성하는 인터페이스가 다음 릴리스에서 변경 될 것이며 그 변경 내용은 무엇입니까?
그리고 개발 중에 가능한 한 빨리 더미 인터페이스 (빈 구현으로)에 액세스하여 자체 코드 작성을 시작할 수 있도록하십시오.

모든 것이 없으면 단위 테스트는 시스템의 각 부분 사이에 문제가 있다는 마지막 단계를 지적하는 것 외에는 별다른 영향을 미치지 않습니다. 그 사실을 알고 싶지만 일찍, 아주 일찍 알고 팀이 서로 대화하고 노력을 조정하며 실제로 다른 팀이하고있는 작업에 자주 액세스 할 수 있도록하려면 (대규모가 아닌 정기적 인 커밋) 배달 몇 주 또는 몇 달, 1-2 일 후 커밋).
버그는 코드에 포함되어 있지 않으며 다른 팀의 코드에는 포함되어 있지 않습니다. 버그는 개발 프로세스에 있으며 사람들 간의 의사 소통과 협업이 부족합니다. 다른 방에 앉아 있다고해서 다른 사람과 자신을 격리시켜야한다는 의미는 아닙니다.

주로 의사 소통 문제 (아마도 팀 빌딩 문제 와 관련이 있음 )가 있으므로 귀하의 사례에 대한 솔루션은 개발 기술 대신 의사 소통에 중점을 두어야한다고 생각합니다.

고객 프로젝트를 시작할 때 핵심 모듈을 정지 시키거나 포크 할 수 없다는 점은 당연한 일입니다 (그렇지 않으면 단순히 핵심 모듈 업데이트를 목표로하는 비 고객 관련 프로젝트 일정을 회사에 통합해야합니다).

따라서 우리는 팀 간의 의사 소통을 개선하려는 문제에 직면 해 있습니다. 이것은 두 가지 방법으로 해결할 수 있습니다.

• 인간과. 즉, 귀사 는 코드의 품질과 가용성을 책임지는 핵심 모듈 아키텍트 (또는 최고 경영진에게 적합한 용어) 로 회사를 지정 합니다. 이 사람은 핵심을 구체화 할 것입니다. 따라서 그녀는 모든 팀이 공유하고 팀 간의 적절한 동기화를 보장합니다. 또한, 일관성을 유지하기 위해 핵심 모듈에 적용되는 코드를 검토하는 역할을 수행해야합니다.
• 도구와 워크 플로우. 부과함으로써 지속적인 통합을 핵심에, 당신은 핵심 코드 자체 통신 매체 할 것입니다. 이를 위해서는 먼저 자동화 된 테스트 스위트를 추가하여 약간의 노력이 필요하지만 야간 CI 보고서는 핵심 모듈의 전반적인 상태 업데이트가됩니다.

통신 프로세스로 CI에 대한 자세한 내용은 여기를 참조하십시오 .

마지막으로 회사 수준에서 팀 작업이 부족하다는 문제가 있습니다. 나는 팀 빌딩 이벤트의 열렬한 팬은 아니지만 이것이 유용한 경우처럼 보입니다. 정기적으로 개발자 차원의 회의가 있습니까? 다른 팀의 사람들을 프로젝트 회고에 초대 할 수 있습니까? 아니면 금요일 저녁 맥주를 드시나요?