절반의 기능을 구현하는 올바른 방법을 배우려면 어떻게해야합니까? [닫은]

개발 팀을 이끌고 가능한 한 자주 제품을 출시하려고합니다 (연속 배송).

대부분의 경우 릴리스 간 시간보다 구현하는 데 시간이 오래 걸리는 기능을 구현해야합니다. 나는 여전히 사람들이 매일 코드를 커밋하기를 원합니다 (연속 통합).

여러 번 새 기능을 구현하려면 기존 기능을 변경해야하며 새 기능이 아직 완료되지 않은 경우에도 기존 기능이 계속 작동해야합니다.

개발자가 올바른 접근 방식을 사용하면 기존 기능을 신중하게 조정할 수 있으며 위의 모든 사항은 문제가되지 않습니다.

그러나 실제로 올바른 접근법은 무엇입니까? 나 자신의 프로그래밍 조정 된 마음이 각 개별 사례에 대해 무엇을해야하는지 알려 주지만 더 배우고 팀원들이 읽고 읽을 수 있도록 읽을 자료가 필요합니다. 또는이 접근법을 배우는 올바른 방법을 배우는 다른 방법이 있습니다.

이것이 바로 질문입니다. 팀 구성원이 절반 기능을 구현하는 올바른 접근 방법을 배우도록하려면 어떻게해야합니까?

나는 이것에 관한 전략을 가지고 있다고 주장하는 사람들을 검색했지만 주제에 대해 무작위로 생각하는 사람들을 제외하고는 아직 찾지 못했습니다. 아마도 올바른 검색 단어를 사용하지 않았거나 아무도 이것에 대한 권위있는 지침을 작성하지 않았을 것입니다.

나는 이미 여기에있는 다른 답변과 다른 견해를 취합니다. 가능한 빨리 개발자의 변경 사항을 통합하고 결합 된 코드 조합을 테스트하고 싶다는 데 동의합니다.

그러나 오늘 오후에 출시 할 예정이기 때문에 오늘 아침에 코드를 선적 할 수있는 권리가 개발되었다는 데 동의하지 않습니다. 실망한 고객을위한 레시피입니다.

해결책은 버전 제어 트리에 분기가 있고 개발 분기에서 릴리스 분기로 검증 된 델타를 승격시키는 별도의 프로세스가 있다는 것입니다.

그렇게하면 두 세계를 최대한 활용할 수 있습니다. 지속적인 통합을 수행하는 개발자와 그 이점으로 인해 정기적으로 고객에게 안정적인 코드 배송이 제공되며 개발자 지점에서 완성 된 기능을 테스트하는 새로운 프로세스가 있으며 테스트를 통과하면 출시 된 제품의 일부가됩니다. .

이러한 종류의 프로세스를 잘 지원하는 두 가지 도구가 있습니다. 개발 구조가 간단하다면 git-flow를 사용하는 git은 중소 규모의 팀 (약 20 명의 개발자)에서 잘 작동하는 좋은 분기 구조를 구현합니다.

대규모 개발 팀 또는 제품의 여러 '스핀'을 지원하기 위해보다 복잡한 분기 전략이 필요한 경우 accurrev가 최고입니다. 변경 관리에 관여하지 않는 개발자는 하위 버전보다 어렵다고 불평하지만 복잡한 개발 환경을 지원합니다.

여기에는 두 가지 문제가 있습니다. 하나는 기능 절반을 구현하는 것입니다. 다른 하나는 지속적인 개발 과정에서 선적 제품의 작동 상태를 유지하는 것입니다.

절반 기능 구현

강력한 디자인이 도움이 될 것입니다. 이를 통해 인접 코드 비트에 대한 API, 데이터 구조에 대한 기대치, 구현 된 코드의 호출 방법 및시기에 대한 이해 등 명확하게 정의 된 경계를 가진 기능을 구현할 수 있습니다.

테스트에는 기능의 다른 부분에 대한 목업 버전의 코드가 포함될 수 있습니다. 이것은 후반을 구현할 때 전환을 부드럽게하는 데 도움이됩니다.

배송 제품 작동 상태 유지

여기 몇 가지 옵션이 있습니다.

1. 배송 된 제품에서 기능을 '해제'하십시오. 코드가 제품에 있다고해서 코드를 실행하거나 사용자에게 제시해야하는 것은 아닙니다. 단점은 사용자에게 점진적인 가치를 제공하지 않으며 피드백을받지 못한다는 것입니다.
2. 기능의 가장자리를 사용자에게 공개하십시오. 당신이 가진 것을 보여주고, 앞으로 올 것을 표시하십시오.
3. 사용자가 새로운 기능과 기존 기능을 전환 할 수 있습니다. 최종 사용자 준비가 된 두 개의 코드 경로를 유지해야하는 경우가 있습니다.

마지막으로 이러한 솔루션에 문제가있는 경우 기능을 올바른 경계로 분할했는지 여부를 고려하십시오. 물건을 다른 방식으로 얇게 썰면 더 쉽게 분리 할 수 ​​있습니까?

팀 구성원이 절반 기능을 구현하는 올바른 접근 방법을 배우도록하려면 어떻게해야합니까?

그들을 가르치는 것. (두)

학습에는 반복, 즉 무언가 시도, 작동 방식 확인 및 더 나은 결과를 얻기 위해 접근 방식 수정이 포함됩니다. 이런 종류의 일을 위해 디자인 / 코드 리뷰를 옹호합니다. 반 기능이 어떻게 설계 / 구현되고 피드백을 줄 수있는 기회를 얻게됩니다. "이것은 CI를 깨뜨릴 것이기 때문에 작동하지 않습니다. XYZ는 어떻습니까?", "여기 잘하셨습니다. 정말 깨끗합니다."

검토를 팀으로 수행하면 모든 사람이 이미 직관적으로 알고있는 내용을 배우는 데 도움이됩니다.

여기에서 당신을 도울 가장 큰 것은 가능한 한 코드 영역이 다른 영역을 방해하지 않도록 우려를 잘 구분하는 것입니다.

인터페이스에 Dependency Injection과 프로그래밍을 사용하면 실제로 사이트에서 ISupportingFeature를 구현할 수 있고 다른 구현에 따라 INewFeature를 만들어야 할 경우 다음과 같이 개발할 수 있습니다. 새로운 구현을 수행하고 잘 테스트되고 실행 준비가 될 때까지 프로덕션 환경에서 기존 구현을 유지합니다. DI가 어떤 종류의 구성 시스템에서 작업한다고 가정하면 시스템에서 동일한 코드를 병렬로 유지하고 항상 안정적인 코드를 사용할 수 있습니다.

실제로이 구성 방식은 Martin Fowler에 의해 기능 토글 로 설명되어 있습니다.

물론 모든 코드를 항상 배포 하는 경우에만 문제가 발생합니다 . 이것은 정확히 기능 브랜치가 설계된 시나리오의 유형이며 파울러 씨가 찌르는 것을 인정하지만, 특히 계획되고 생각에 만들어지고 사용된다면 그것들이 모두 나쁘다는 것을 알지 못합니다. 길을 통해.