확장/재사용 프로젝트 재구성

Question

내가 작업하고있는 프로젝트의 범위는 확장되고 있습니다. 응용 프로그램은 상당히 간단하지만 현재 매우 구체적인 틈새 시장을 목표로합니다. 즉시 미래에 나는 새로운 시장을 목표로하고 두 프로젝트를 계속 개발하기 위해 프로젝트를 포크하라는 요청을 받았습니다.

두 프로젝트 모두 기능적으로 유사하므로 많은 것을 일반화 할 매우 강력한 인센티브가 있습니다. 끈기 원래 프로젝트의. 또한 가까운 시일 내에 더 많은 시장을 목표로 할 것이라고 확신합니다 (시장은 지리적입니다).

문제는 프로젝트의 이전 관리자가 원래 시장에 묶는 많은 가정을 만들었습니다. 시장 별 코드와 제네릭을 분리하려면 상당히 약간의 리팩토링이 필요합니다.

점점 더 많은 시장을위한 프로젝트를 구성하는 방법에 대한 몇 가지 제안이 더 복잡하게 만들기 위해 다음과 같습니다.

1. 각 시장은 별도의 프로젝트이며, 프로젝트 간의 공통점은 공유 라이브러리로 옮겨지고 프로젝트는 독립적으로 배치됩니다.
2. 기존 프로젝트를 확장하여 여러 시장을 대상으로 구매 한 라이센스를 기반으로 기능을 제한합니다.
3. 부모 애플리케이션을 작성하고 프로젝트를 개별적으로 구매 한 플러그인으로 재 설계하십시오.

세 가지 제안은 모두 장점이 있으며 이상적으로는 코드를 구조화하고 싶습니다. 제안 3은 플러그인 아키텍처를 구축해야하기 때문에 가장 어려운 것으로 보입니다. 처음 두 가지 제안은 조금 더 그럴듯합니다.

이러한 다른 아키텍처의 장단점에 대한 좋은 자료가 있습니까?

프로젝트 복사 및 포크 사이의 코드 공유에 대한 장단점은 무엇입니까?

Answer 1

포킹은 일반적으로 처음에는 더 빠른 결과를 얻을 수 있지만, 거의 항상 유지 보수에 와서 물린 것입니다. 한 포크의 버그 수정 및 기능 향상은 다른 포크에서 길을 잃고 결국 전체 포크를 버릴 수 있습니다. 그리고 자신의 기능을 "최고의"포크에 다시 대고해야했습니다. 가능하다면 피하십시오.

계속 진행 : 세 가지 옵션이 모두 작동 할 수 있지만 건축 복잡성, 유지 보수 비용, 배포, 커뮤니케이션 간접비 및 필요한 리팩토링 금액 측면에서 트레이드 오프가 있습니다.

---

1. 각 시장은 별도의 프로젝트입니다

여러 시장에서 동시에 개발하려는 경우 좋은 솔루션입니다.

장점 :

• B에 대한 진행중인 작업을 방해하지 않고 시장 A의 개발자가 A 빌드를 깨뜨릴 수 있습니다.
• 시장 A에 대한 변화가 시장 B에 대한 버그를 일으킬 가능성이 훨씬 낮습니다.

단점 :

• 공유 코드를 분리하려면 시간이 걸립니다.
• 병렬 빌드를 설정하려면 시간을 내야합니다.
• 공유 코드에 대한 수정은 이제 두 팀 모두에 영향을 미치기 때문에 더 많은 오버 헤드를 갖습니다.

2. 기존 프로젝트를 확장하여 여러 시장을 대상으로합니다

꽤 오랫동안 잘 작동하도록 만들 수 있습니다. 소규모 팀과 함께 한 번에 한 시장을위한 릴리스를 위해 노력하려는 경우 가장 좋은 방법 일 수 있습니다.

장점 :

• (1) 또는 (3)으로 이동하더라도 라이센스 작업은 아마도 어쨌든 가치가있을 것입니다.
• 단일 코드베이스는 모든 시장에서 리팩토링을 허용합니다.

단점 :

• 시장 A를 위해 무언가를 위해 노력하더라도 시장 B, C 및 D 코드를 제작하고 배송해야합니다. 클래스
• 하나의 시장 위험으로 변경되는 다른 시장의 코드를 위반합니다.
• 한 시장의 변경 사항은 다른 시장을 다시 테스트해야합니다.

3. 플러그인으로 부모 애플리케이션 및 프로젝트를 재 설계하는 것

기술적으로 달콤한 느낌이 들며 더 많은 코드를 공유 할 수 있습니다.

장점 :

• (1)의 모든 장점, 잠재적으로 :
  • 공유 및 시장 별 코드의 명확한 분리
  • 공개 API로 이동할 수있어 고객에게 일부 작업을 오프로드하거나 수익성있는 서비스 프로젝트를 판매 할 수 있습니다.

단점 :

• (1)의 모든 단점은 더 많은 리팩토링이 필요합니다.

---

나는 (2) 라이센스와는 별도로 당신이 지금 자신을 찾는 곳이라고 생각합니다. 잠시 동안 거기에 머물러 있어도 괜찮다고 생각하지만 (1)으로 이동하는 데 약간의 노력을 기울이고 있습니다. 예를 들어, 공유 코드가 모두 함께 구축되어 있어도 시장의 의존성이 시장의 의존성을 확인하려고하더라도 별도의 프로젝트로 옮깁니다. 공유 코드로의 코드는 모두 일방적입니다.

당신이 (1) 또는 (3)에 의존하는지 여부는 의존합니다. 대부분은 "담당자"(공유 코드 또는 시장 별 코드)에 달려 있습니까? 플러그인과 일부 공유 구성 요소를 구성하는 컨트롤러 클래스 사이의 라인은 매우 흐릿합니다. 제 조언은 코드가 필요한 것을 말해주게 될 것입니다.

Answer 2

1) 아니! 동일한 코드 기반의 다른 분기를 관리하고 싶지 않습니다 ... 코드가 일반적이기 때문에, 당신은 눈에 띄는 변경을 원할 것이고, 한 프로젝트는 "현재"다른 프로젝트는 "다른 프로젝트만큼 중요하지 않습니다. , 그리고 당신은 다른 지점보다 더 빨리 성장할 것입니다 .... 눈덩이를 삽입하십시오.

2) 이것은 산업 표준 에이 점입니다. 큰 구성 파일, 라이센스/구성에 따라 물건을 제한합니다. 그것은 앱을 약간 번거롭게 만들 수 있지만, 코드가 상호 배타적 인 것들에 대해 불평하고 모든 개발자가 새로운 기능과 전체 애플리케이션에서 어떻게 파급되는지에 대해 지속적으로 의사 소통하고있는 한, 잘 수행해야합니다. 이것은 또한 걱정이된다면 해킹하기 가장 쉬운 일입니다.

3) 이것은 또한 '작동'할 수 있습니다. C#을 사용하는 경우 플러그인은 비교적 간단합니다. 의존성 지옥에 대해서만 걱정하면됩니다. 플러그인이 원형 상호 의존적이 될 가능성이있는 경우 (즉, A가 필요) a가 필요합니다. a)는 빠르게 폭발하여 #2로 다시 되돌아갑니다 (아주 쉽게).

당신이 가진 최고의 자원은 아마도 다른 프로젝트에 대한 동료의 과거 경험과 여기에있는 사람들의 경험이 여기 또는 슬래시 도트 또는 어디에 있든 경험 일 것입니다. 확실히 가장 저렴합니다.

공유 코드의 장점 : 하나의 변화는 모든 것을 변경합니다. 통합 데이터 모델. 진실은 하나뿐입니다. (모든 사람이 같은 페이지에있을 수있는 훨씬 쉽습니다)

공유 코드의 단점 : 하나의 변경 사항은 모든 것을 변경합니다. 조심하십시오. 하나의 버그가 있으면 모든 것에 영향을 미칩니다.

복사/포킹 장점 : 일반적으로 특정 고객에 대한 특정 기능을 구현하는 데 더 빠릅니다. 가정 A가 D가 아닌 시장 B와 C에만 적용 가능하다는 것을 알면 해킹보다 빠릅니다.

복사/포크의 단점 : 코드의 응집력 부족으로 인해 하나 이상의 복사 프로젝트가 결국 실패합니다. 위에서 말했듯이 : 스위프 변화는 훨씬 더 오래 걸립니다.

행운을 빕니다.

Answer 3

당신은 "복사 및 포크"라고 말했습니다. 아마도 당신은 아마도 당신이 이것을 "포크"를 SVN과 같은 개정 제어 시스템의 지점으로 관리하는 것을 고려하지 않았을 것이라고 생각하게합니다. 이렇게하면 다른 산업을 수용하기 위해 지점을 리팩토링하면 수정 제어 시스템의 도움으로 이러한 변경 사항을 메인 트렁크로 다시 병합 할 수 있습니다.

모든 변형이 구성 파일 (또는 SQLITE Config Database)으로 제어되는 단일 앱으로 이동하는 장기 전략을 따르고 있다면이 접근법이 도움이됩니다. 두 산업 모두에 대해 일반화했다고 확신하기 전까지는 아무것도 합병 할 필요가 없으므로 필요한 한 두 개의 고유 한 시스템을 구축 할 수 있습니다. 그러나, 당신은 하나의 소스 코드 트리, 레거시 산업의 트렁크, 각 새로운 산업마다 하나의 지점에 있기 때문에 모퉁이로 뒷받침하지 않습니다.

회사가 여러 산업을 실제로 원한다면 구성 데이터베이스 솔루션이 귀하의 모든 요구를 충족시킬 것이라고 생각하지 않습니다. 여전히 어떤 종류의 특수 코드 모듈이 필요합니다. 플러그인 아키텍처는 특히 Python과 같은 스크립팅 엔진을 앱에 포함시킬 경우 도움이되기 때문에 적용해야합니다. 그러나 "수천 개의 클래스"척도에 들어갈 때 플러그인이 모든 코드 변형 요구 사항을 충족 할 수 있다고 생각하지 않습니다.

오늘날 새로운 산업을 위해 별도의 앱을 구축 할 수있는 실용적인 접근 방식을 취해야하지만, 개선 사항을 기존 앱으로 병합하는 것이 비교적 쉽습니다. 수천 개의 클래스와 여러 산업이있는 단일 트렁크의 너바나에 도달 할 수는 없지만 적어도 복잡성을 길들일 것이며 산업 요구에 실질적인 차이가있는 정말 중요한 변형 만 처리하면됩니다.

내가 당신의 신발을 신고 있다면, 나는 또한 "보고"로 간주 될 수있는 앱의 모든 기능을보고 있으며,이를 고려해야 할 수도 있습니다.