답변:
공유 코드를 라이브러리로 분리하고 라이브러리를 프로젝트에 포함하십시오.
Android 개발자는 아마도 Java를 사용하고있을 것입니다. Maven 또는 Ivy 와 같은 종속성 관리 도구를 사용해보십시오 .
부작용은 이것이 모듈성을 강화함으로써 우려의 분리를 유지 하는 데 도움이된다는 것 입니다. 비용은 분리하는 데 약간의 작업이 필요할 수 있습니다. 이점은 더 나은 미래 유지 보수성입니다. 또한, 결정한 경우, 응용 프로그램과 별도로 (상업적으로 또는 공개 소스로) 라이브러리를 해제 할 수 있습니다.
git 또는 mercurial 등과 같은 dvc를 사용하여 프로젝트를 버전 관리 상태로 만듭니다. 공유 코드를 git의 하위 모듈에 넣습니다. 필요한 프로젝트에서 서브 모듈을 사용하십시오. 서브 모듈을 업데이트 할 때 단일 명령으로 다른 프로젝트로 변경 사항을 가져올 수 있습니다.
아무도 양날 칼을 언급하지 않았으므로 2 센트를 더할 것입니다. 좋은 프로그래밍 사례 / 원칙에 따라 프로젝트가 여러 개이고 재사용 가능한 코드를 모두 공유하는 경우 (예 : DRY), 코드를 하나의 글로벌 위치에 배치하고 모든 사람이 공유 할 수 있도록 코드를 구성해야합니다 수정없이 프로젝트. 다시 말해, 인터페이스는 모든 사람에게 적합 할 정도로 일반적이고 공통적 인 인터페이스를 정의하십시오.
이를위한 몇 가지 옵션이 있습니다. 1) 다른 사람들이 의존하는 기본 프로젝트를 만듭니다. 이 프로젝트는 다른 프로젝트가 사용하는 이진 배포를 만들 수 있습니다. 2) 조직 내에서 오픈 소스 모델을 가져옵니다. 공통 코드를 자체 코드 브랜치로 만들고 다른 프로젝트에서 온라인으로 OSS에서 소스 코드를 가져 오는 것과 같은 방식으로 코드를 가져옵니다.
이제 여기 칼이 들어 와요
다른 프로젝트 / 사람들이 의존하는 공통된 장소에 코드를 배치하면 비용이 많이들 수 있습니다. 코드 조각이 있고 그에 따라 4 개의 다른 프로젝트가 있다고 가정 해 봅시다. 프로젝트 A를 사용하는 고객 중 하나가 버그를 발견하고 수정해야합니다. 당신은 수정을 서두르고 그 고객은 행복합니다. 그러나 3 개의 다른 프로젝트가 의존하는 일부 코드를 수정했습니다. 에지 조건이 발생하지 않도록 모든 것을 다시 테스트 했습니까?
공통 코드는 훨씬 더 신중하게 제작되어야하며 모듈 인터페이스는 훨씬 더 잘 설계되어야합니다. 그 코드는 4 명 이상의 클라이언트를 수용해야하고 각 사용자는이 코드를 약간의 차이로 사용할 수 있기 때문입니다.
프로젝트가 다른 릴리스주기에있는 경우 공통 코드 관리에 대해 더욱주의해야합니다. 프로젝트 C의 최종 이미지를 잘라내는 데 3 일이 걸리지 않으면 프로젝트 B에는 새로운 기능이 필요하기 때문에 공통 코드를 간단히 변경할 수 없습니다.
공통 라이브러리가 올바른 솔루션이 아니라고 말하는 것은 아닙니다. 저는 DRY의 강력한 지지자이며 이전에 공통 코드를 작성하고 지원했으며 계속 그렇게하고 있습니다. 단순히 코드를 공통으로 만들면 자체 비용이 들게하기를 원했습니다.
이 코드를 재사용하는 유일한 사람이라면 나쁘지 않습니다. 엔지니어 팀이 있고 공통 코드를 사용하기 시작하면 비용이 더 많이 발생합니다. 다른 사람들이 관여하는 경우, 코드를 공통 라이브러리에 배치하면 코드가 "완전"하다고 생각되는 시점에 도달하는 데 걸리는 시간보다 3 배 더 오래 걸릴 것으로 예상됩니다. a) 모든 종류의 엣지 조건 및 유효하지 않은 사용으로부터 보호하기 위해 라이브러리를보다 강력하게 만들어야합니다. b) 다른 사람이 라이브러리를 사용할 수 있도록 문서를 제공합니다. 예상하지 않았고 설명서에서 특정 사용 사례를 다루지 않았습니다.
내가 제안 할 수있는 몇 가지 제안 :
이것은 이상적인 솔루션이며 작업을하려면 약간의 노력이 필요할 수 있습니다.
DRY 원칙에 따르면 신뢰할만한 단일 출처가 있어야합니다. 이것은 복제없이 모든 프로그램 로직에 단일 소스 저장소를 사용하도록 지시합니다 . 문서 공유 및 재사용을 촉진하도록 구성된 파일
분산 된 다중 팀 환경에서 의사 소통의 실제 요구 사항은 각 프로젝트 또는 협업마다 하나씩 여러 개의 독립적 인 저장소가 있어야 함을 나타냅니다.
필자는이 문제를 피할 수없는 것으로 제출함으로써 접근 할 것이다. 두 가지 접근 방식을 동시에 수행해야하며, 우리는 접근 방식이 모순된다는 사실을 매끄럽게하기 위해 스크립팅 및 자동화를 사용할 것이다.
:-)
하나의 통합 저장소는 단일 권한 소스가됩니다. 각 프로젝트의 빌드 프로세스는 해당 프로젝트에서 사용하는 모든 파일 (및 해당 파일 만)을 중간 위치로 복사 한 다음 해당 중간 위치에서 빌드합니다. 전체 파일 대신 델타를 이동하기 위해 Unison 또는 이와 유사한 도구를 사용할 수 있습니다.
이러한 중간 위치는 보조, 파생 또는 다운 스트림 리포지토리의 로컬 작업 복사본으로 사용할 수 있습니다. 신뢰할 수있는 저장소의 커미트 후 후크 스크립트는 모든 중간 위치를 업데이트하고 각각의 위치가 변경되었는지 확인하고 변경이 감지되면 해당 보조 저장소에 동일한 커미트를 작성합니다.
이러한 방식으로 여러 보조 저장소가 단일 권한 소스 저장소와 동기화 된 상태로 유지되며 빌드 프로세스를 통해 보조 저장소에 빌드에 필요한 모든 (공유 가능) 문서 및 기타 파일이 포함됩니다. 마지막으로 가장 중요한 것은 개발 및 빌드 프로세스를 통해 한 곳에서 한 곳에서만 파일을 편집하고 모든 사본이 일관되고 최신 상태로 유지되도록하는 것입니다.