개발 팀이 Visual Studio의 여러 프로젝트에 단일 솔루션을 사용하면 "상호 종속성 복잡성이 증가"한다고 주장하는 이유는 무엇입니까?

기존 제품의 새 버전을 개발하기 시작한 외부 팀을 관리하는 데 도움을주고 있습니다. 역사적으로이 팀은 Visual Studio에서 약 30 개의 모듈에 대해 단일 솔루션으로 단일 프로젝트 모델을 사용하여 배포 가능한 빌드를 생성했습니다.

항상 최신 소스 코드를 보내지는 않기 때문에 빌드 안정성과 품질에 해로운 영향을 미칩니다. 우리는 그것들을 눌러 모든 참조 코드를 단일 솔루션으로 통합하려고 노력하고 있지만 약간의 저항을 얻고 있습니다. 단일 솔루션 파일. 별도의 솔루션에있는 코드는 다른 곳에서 사용되지 않습니다.

나는 이것이 넌센스라고 주장하고 좋은 개발 패턴은 그러한 문제를 피할 것이라고 주장한다.

문제의 팀은 기존 제품에 대한 버그 수정 및 새로운 기능 개발도 수행합니다. 경험이 가장 적었고 여러 솔루션에 대한 동일한 문제로 어려움을 겪었습니다. 소스 제어 ( TFS )에 대한 액세스가 거부되었으며 코드베이스를 통합하기위한 접근 방식은 누락 된 업데이트 수와 때때로 회귀 이상을 시도하고 줄이는 것입니다 (예 : 수정 된 버그가 다시 발생 함) "제품에 도입))"솔루션 폴더 전체의 ZIP을 보내서 압축을 풀고 Visual Studio에서 열고F5 일반적인 구조와 품질면에서 코드는 매우 열악하고 지원하기가 어렵습니다. 이러한 경험 때문에 개발 프로세스 초기에 작업 프로세스를 최대한 빨리 수행하려고합니다.

내가 놓친 것이 있습니까? 모든 코드를 분리해야 할 이유가 있습니까? 내 돈을 위해서는 그것이 일반적인 지식이 될만한 이유를 설득력이 있어야하지만, 나는 모든 것을 알지 못한다는 것을 기꺼이 인정합니다.

프로젝트를 구성하는 방법을 알려주지 않아도됩니다. 대신 오류없이 하나의 스크립트를 실행하여 소스에서 시스템을 구축 할 수있는 어려운 요구 사항이됩니다. 해당 스크립트가 Visual Studio 또는 Msbuild 또는 다른 도구를 실행하고 한 번 호출 된 경우 50 번 또는 100 번은 중요하지 않습니다.

이렇게하면 모든 것을 단일 솔루션에 넣는 것과 동일한 코드의 "완전성 테스트"를 수행 할 수 있습니다. 물론,이 스크립트는 팀이 소스 컨트롤에서 최신 버전을 실제로 체크 아웃했는지 여부를 알려주지 않지만 하나의 솔루션에 전체 코드를 가지고 있으면이를 확인할 수 없습니다.

"모든 것이 단일 솔루션 파일에 배치되면 모듈 간의 상호 의존성이 증가합니다"에 대한 답변으로 - 프로젝트에 솔루션을 추가해도 프로젝트 간의 종속성이 변경되지 않으므로 이는 하나의 프로젝트에서 비롯된 것이기 때문에 의미가 없습니다. 어떤 솔루션이 어떤 프로젝트 파일을 참조하는지와 완전히 독립적 인 다른 파일을 참조하는 파일. 그 팀이 모든 프로젝트를 참조하는 단일 솔루션과 각각 하나의 프로젝트 만 참조하는 개별 솔루션을 모두 갖도록 막을 수는 없습니다.

그럼에도 불구하고 빌드 스크립트를 추가하는 것이 좋습니다. 솔루션 파일이 하나 뿐인 경우에도 이점이 있습니다. 예를 들어, 선호하는 구성으로 VS 빌드를 실행하고 배치를위한 최종 파일을 "배치"폴더에 복사하고 빌드를 완료하기 위해 다른 도구 및 단계를 실행할 수 있습니다. 참조 F5는 빌드 과정이 아니다! 그리고 Joel 시험 .

컴파일 된 어셈블리가 얼마나 재사용되는지에 달려 있습니다. 어셈블리를 재사용하지 않으면 "모듈"을 별도로 유지해야 할 이유가 없습니다. 실제로 내 경험상 이것은 더 많은 방해입니다.

개발 팀에는 여러 제품에 별도의 솔루션으로 사용되는 독립적 인 라이브러리가 있습니다.이 경우에는 응용 프로그램 A를 컴파일하여 응용 프로그램 B를 최신 상태로 유지해야합니다. 응용 프로그램 C를 최신 상태로 유지해야 할 수도 있습니다.

제품을 구성하는 여러 프로젝트가 있어도 각 제품은 자체 솔루션으로 유지됩니다. 이렇게하면 개발 된 모든 제품에서 공유 코드를 최신으로 유지하기 위해 라이브러리 솔루션 만 구축하면됩니다.

내가 일했던 모든 소프트웨어 회사에는 회사 제품의 기본 사용 사례를 다루는 헤드 지점을 제공하는 핵심 개발 팀이있었습니다.

핵심 리포지토리를 사용하는 지점 개발자는 개선 사항을 발견하고 풀 요청을 검토하기 위해 헤드 지점에 제출해야합니다. 이것은 일반적으로 아키텍처 충돌의 불꽃을 부채질하는 것보다 더 나은 기여를 할 수 있음을 보여줌으로써 핵심 개발자가되는 방법입니다.

귀사에 "참조 된 모든 코드를 단일 솔루션으로 즉시 통합 할 수있는"리소스가없는 것 같습니다. 예산 제약 조건을 이해하지 않고 제안하면 핵심 엔지니어가되는 것을 막을 수 있습니다.

그러니 웅대 한 비전을 핵심에 대한 몇 가지 파괴적인 끌어 오기 요청으로 공식화하고 검토에서 자신을 방어 할 준비를하십시오!

"여러 프로젝트에 단일 솔루션을 사용하면 상호 의존성이 복잡해집니다"라는 주장에는 진실이 있습니다.

단일 솔루션을 사용하면 다른 프로젝트에서 프로젝트를 참조 할 수 있습니다 (예 : "상호 종속성 복잡성"이라는 프로젝트 코드 재사용).

• 참조 된 어셈블리에 대한 전체 파일 시스템 / 글로벌 어셈블리 캐시를 탐색하는 대신 솔루션의 제한된 관련 프로젝트 세트에서 프로젝트를 선택할 수 있습니다. 과,
• 소스 코드를 읽을 때 임의의 (이진) 어셈블리보다 솔루션의 참조 된 프로젝트로 이동하는 것이 훨씬 쉽습니다.

따라서 단일 솔루션에서 여러 프로젝트를 사용하는 훈련받지 않은 팀의 손에 부주의하게 도입 된 많은 종속성이 발생할 수 있습니다. 그러나 팀은 종속성을 신중하게 관리하고 솔루션을 사용하여 제공하는 재사용 용이성을 사용하는 데 필요한 원칙을 배우려고 노력할 수 있습니다.