2010-07-28 4 views
0

저는 다른 고객을 대상으로 제공되는 각 앱과 관련된 기능을 갖춘 일련의 애플리케이션을 개발 중입니다. 앱은 상당 부분 공통된 기능을 가지고 있지만 각 고객 요구 사항에 고유 한 기능이있어 다른 기능에 제공 할 수 없습니다.순차적으로 개발 된 관련 앱용 코드베이스 관리

지금까지 우리 고객 (A1, B2, A3)에 속한 모든 버전은 개별적으로 자금을 공급 받고 개발 되었기 때문에 이전 고객의 스냅 샷을 간단하게 가져 와서 새로운 SVN 저장소에 넣었습니다. 거기에서 변화를 만들기 시작했다. 우리는 지금까지는 OK를 관리했지만 앞으로 더 많은 고객이있을 것으로 예상하고 고객 A3의 응용 프로그램에서 개선 된 사항 중 일부를 A1 용 새 버전으로 롤백 할 계획입니다. 현재의 설정은 현재 프로세스로 관리 할 수있는 상태로 유지되지 않습니다. .

내가 찾고있는 것은 이러한 종류의 일이 다른 곳에서 어떻게 이루어졌으며 계속 진행하기위한 최선의 방법이 무엇인지에 대한 정보입니다. 나는 우리가 그것에 대해 가지고있는 염려를 어떻게 진행하고 그것에 대한 피드백을 찾고 있는지에 대한 나의 생각을 기술 할 것이다.

우리는 높은 수준의 기능 차이에 따라 고객을 두 개의 주요 그룹으로 나눌 것을 계획합니다. 고객 ID 앞에 A와 B를 붙이는 것은 이것을 반영합니다. A1과 A3의 소프트웨어 버전은 B2보다 훨씬 많은 공통점이 있습니다. 현재 우리는 C 카테고리가 추가 될 것으로 기대하지는 않지만 앞으로 몇 년 동안 변경 될 수있는 카테고리를 배제 할 수는 없습니다.

우리의 기본 아이디어는 기능의 공통된 부분 (백엔드 및 윈 폼 클래스 모두)을 A 및 B 유형 고객을위한 공통 핵심 라이브러리로 분할하는 것입니다. 그런 다음 공통 클래스를 상속하고 각 버전에 대한 고객 별 기능을 별도의 솔루션으로 구현할 수 있습니다. 우리는 A와 B 모두와 공유되는 것들에 대한 최상위 공통 라이브러리를 가질 수도 있습니다.하지만 A와 B 사이에 충분한 차이점이 있습니다. 그렇기 때문에 복잡성을 추가하는 것만 큼 끝나는 메소드를 재정의해야 할 것입니다. 그 상황.

내가 하나의 솔루션을 가지고 바로 실행할 수있는 응용 프로그램 고객이 선택하는 대신 별도의 솔루션으로 각 고객의 응용 프로그램을 넣을 필요가 있다고 생각하는 이유는 몇 배입니다 :

첫 번째입니다 때문에 고객 별 NDA의 우리에 고객 X의 애플리케이션에 대한 작업이 없어도 NDA 승인 요구 사항을 알 필요가있는 외부 적으로 부과 된 요구를 충족 할 수 없으므로 이전에 앱에 대한 액세스가 허용되지 않는 새로운 개발자가있을 가능성이 높습니다.

두 번째는 특정 고객의 돈을 직접 사용하기 때문에 공통 라이브러리 기능을 변경할 수 없다는 것입니다 (예 : 특정 고객을 코어 또는 부통령으로 이동). 새로운 코어로 계속해서 작업 할 수 있습니다. 이 제약 조건은 우리가 초기에 독자적으로 유지 관리되는 코드 기반 개념을 도입 한 이유 중 상당 부분을 차지하며 공통 및 고객 별 기능을 계약 수준에서 분리 한 부분의 "정확성"을 검증 할 수있는 잠재력이 있습니다.

세 번째는 두 번째와 관련이 있습니다. 보안상의 이유로 고객 X가 기능 Y를 가질 수없는 경우 X의 응용 프로그램이 메소드를 호출 할 수있는 방법이 없더라도 X의 응용 프로그램은 공용 라이브러리에서 Y를 구현할 수 없습니다. 엔지니어링은 공용 라이브러리의 맨 위에있는 자체 프런트 엔드를 작성합니다.

편집 :이 질문은 대부분 여기에 사망 to've 것 같다,하지만 난 another site.

+0

관련성이 있는지 확실하지 않습니다. 하지만 이들은 C# winform 앱이며 인터넷에 접속할 수없는 컴퓨터에서 실행할 수 있어야합니다. –

답변

1

내가 아주이 상황이 없었다 그러나 희망이 도움이 될 것입니다에 대한 논의의 상당한 금액을 얻었다.

저는 고객이 고객을 별도의 솔루션으로 유지하는 것이 옳은 결정이라고 생각합니다. 반복 코드는 초기 개발 단계에서 추가 작업이 될 수 있습니다. 그러나 종속성을 관리 할 때받을 수있는 슬픔의 수위와 그 우선 순위에서 관리해야하는 오버 헤드가 있습니다.

Stable Abstractions PrincipleStable Dependencies Principle을 염두에 둬야합니다. 너무 많이 변경되지 않고 많은 정치적으로 민감한 패키지가 참조 할 수있는 많은 일반 및 저급 코드를 라이브러리에 포함 시키십시오.

낮은 수준의 "코딩"또는 시스템 레벨 서비스 (파일 저장, confog 액세스 등)를 제공하는 "라이브러리"코드와 순수한 비즈니스 로직 코드/모듈 간에는 중요한 구별이 있습니다. 그래서 나는 여기서 재사용 할 수있는 합리적인 재사용이 가능하다고 생각했을 것이다.

또한 SAP 및 SDP와 함께하면 가능한 한 구현을 추상화하는 접근 방식입니다. 여기서는 종속성 반전과 전략 패턴이 유용합니다.

당신이하고있는 것은 멀티 테넌트 응용 프로그램이 아니지만 몇 가지 공통된 문제를 발견 할 수 있다고 생각합니다.

내가 작성한 모든 제안은 코드/아키텍처/패턴 레벨에있는 것처럼 보입니다. 실용적인 코드 관리/품질 보증/릴리스 측면에 많은 자원을 지원하지 않았습니다. 미안합니다.

+0

"내가 작성한 모든 제안은 코드/아키텍처/패턴 수준에있는 것처럼 보입니다. 실용적인 코드 관리/QA/릴리스 측면에 대해서는 많이 자원 한 적이 없지만 미안합니다." 그것은 궁극적으로 모든 것이 함께 흐르는 문제는 아닙니다. –