"슈퍼"사이트에 대해 고려해야 할 사항은 무엇입니까?

우리 회사는 모든 Tier-1 (즉, 최고급 프로덕션) 애플리케이션과 사이트를 하나의 포괄적 인 코드 기반으로 통합하는 것을 고려하고 있습니다.

이론은 그들의 권한, 디자인 및 전체 기능이 균질화되고 중앙에서 관리 될 수 있다는 것입니다.

각 응용 프로그램을 뒷받침하는 데이터 구조가 매우 다르고 비즈니스 규칙이 각 응용 프로그램마다 복잡하고 고유하며 기존 응용 프로그램의 전체 코드 기반이 매우 이질적이고 매우 무시되기 때문에이 접근법에 대한 우려는 없습니다.

편집 :

현재 환경은 처음 작성된 이후 (주로 회사에 숙련 된 개발자가 없기 때문에) 진정한 사랑을 보지 못한 3 개의 ASP.Net 1.1 사이트와 ASP.Net 1.1 사이트이기도 한 MVC2 응용 프로그램으로 구성되어 있습니다. 작년에 업그레이드되었습니다. 우리는 C #으로 만 ​​작성합니다.

이 회사는 약 50 명의 직원이있는 상당히 작은 회사입니다. 그 중 세 명은 실제 개발자입니다. 관리 (IT 관리도 포함)는 IT 프로젝트의 프로젝트 관리 이외의 IT 배경이나 경험이 없으므로 용어 및 비즈니스 영향에 대한 일부 지식이 필요합니다.

응용 프로그램은 주로 회사에서 판매하는 제품을 지원하기위한 온라인 서비스입니다. 회사는 소프트웨어를 직접 판매하지 않습니다.

따라서이 전체 상황을 합리적으로 구체적이고 대답 할 수있는 질문으로 표현하면 다음과 같습니다. 현재 상태 (예 : 이전 코드 기반, 복잡한 비즈니스 시스템 및 규칙)를 고려하여 모든 시스템을 하나의 포괄적 인 솔루션으로 통합하려고하는 몇 가지 강력한 이유는 무엇입니까? )?

나쁜 생각

이 반응은 다음 가정을 기반으로합니다.

1. 균질화되는 상당히 다른 응용 프로그램이 많이 있습니다.
2. 다른 응용 프로그램에서 작업하는 많은 팀이 있습니다
3. 응용 프로그램을 적극적으로 관리하는 권위 있고 권위있는 소프트웨어 아키텍트는 없습니다.

계속하면 어떻게 되나요?

단일 디자인 방식으로 모든 것을 하나로 모으기위한 초기 통합 노력이있을 것입니다. 이것은 모든 것이 동일하게 작동하고 실행 불가능한 것으로 통조림을 얻는 데 필요한 엄청난 노력을 보여줄 것입니다.

그것이 눌러지면 구성 데이터 (예 : 보안 액세스, 로깅 레벨 등)를 포함하는 일종의 중앙 집중식 저장소가 필요합니다.

"이러한 외부화 된 구성 방식을 기존 애플리케이션에 맞게 개조하지 않는 것이 왜 더 빠를까요?"

잠시 후 다른 누군가가

"그리고 우리는 어쨌든 리팩토링을하고 있기 때문에, 웹 프로세싱은 이와 같은 비즈니스 규칙 프로세싱과 같은 데이터베이스 규칙과 같은 애플리케이션 도메인 각각에 대한 설계 표준을 적용하지 않는 이유는 무엇입니까?"

마지막까지

"오, 여기에는 쉽게 공유되는 라이브러리를 구성하지 않는 일반적인 코드가 많이 있습니다. 매일 밤마다 일정한 간격으로 실행되는 통합 빌드가 필요할 것입니다."

이 시점에서 모든 사람들은 거대한 모놀리스가 건설되지 않았다는 안도의 한숨을 쉬었다.

우리 회사에서이 일을하고 있습니다. 나는 그것이 가능하고 명백한 이점이 있다고 생각하지만 (당신이 언급 한 것), 이것은 절대적으로 최소 5 ~ 7 년 프로젝트 일 것이며 기본적으로 모든 것을 다시 써야합니다. 그런 식으로 사인을 할 수 있다면 그렇게하겠습니다. 그렇지 않다면 악몽 같은 죽음의 행진을 준비하십시오.

구글 은 그렇게하므로 확실히 가능하다 .

BTW 링크는 Google 직원이 코드 기반 관리, 지속적인 통합, 테스트 등을 관리하는 방법에 대한 흥미로운 프레젠테이션입니다.

그러나 구글과 마찬가지로 툴링에 대한 강한 의지가 없다면 당신은 다칠 수 있습니다.

여기서 중요한 질문은 왜 입니까? 고위 경영진이 왜 이것을 원합니까? 그들이 얻고 자하는 저축, 레버리지 또는 다른 이점은 무엇입니까?

목표를 달성하기 위해 이러한 문제를 충분히 해결할 수 있다면 , 동일한 단일 결과를 유지하면서도 관련된 단일 코드 기반을 피할 수 있습니다.

우리는 비슷한 과정을 거쳤습니다. 우리는 한동안 주변에 있던 제품을 가지고있었습니다. 작년에 우리는 첫 번째 제품과 95 % 동일한 다른 제품을 출시했으며, 때로는 5 %의 미묘하지만 중요한 차이가 있으며, 이러한 차이는 별도의 팀에서 개발하고 유지해야합니다.

새 제품에 대한 작업을 처음 시작했을 때 이전 팀은 새 제품을 이해하지 못했기 때문에 5 %의 부정적인 영향을 계속해서 받았습니다. 그래서 우리는 코드의 5 %를 완전히 분기하여 첫 번째 릴리스를 정시에 완료 할 수있었습니다.

그런 다음 더 많은 유지 보수 작업이 시작되었고 거의 동일한 코드에서 거의 동일한 변경 사항이 자주 발생한다는 것을 알았습니다. 이전 팀은 이제 새로운 제품에 대해 훨씬 더 잘 이해하고 있으므로 점진적으로 포크를 다시 통합하고 차이점을 표현할 수있는보다 효율적인 아키텍처 방법을 찾고 있습니다.

따라서 데이터 구조가 다르고 전체 코드베이스가 서로 다르다고 말할 때, 내가 묻는 질문은 그러한 방식이어야하는지 또는 순간의 편리함으로 인해 어떻게 진화했는지입니다. 분명히 다른 비즈니스 규칙과 요구 사항을 고려해야하지만 핵심은 이러한 차이를 가능한 작은 모듈로 분리하는 것입니다. 여러 코드 기반에 대해 약간 다른 방식으로 여러 고객에 대해 동일한 기능을 구현하는 경우가 종종 있으면 통합이 실제로 도움이 될 수 있습니다.

많은 응용 프로그램을 동일한 코드 기반 으로 통합 할 수 없을 것입니다. 많은 노력이 필요하고 오래된 무시 된 프로그램의 경우 처음에 예상했던 것보다 훨씬 많은 작업이 필요할 수 있기 때문입니다.

즉, 모든 응용 프로그램이 동일한 코드 저장소 에있는 데 아무런 문제가 없으며 각 응용 프로그램에는 별도의 영역이 있습니다. 이를 통해 전체 코드베이스에 대해 온라인 문서를 하나의 일관된보기로 생성 할 수 있습니다. 이는 일반적으로 최대한 많은 가시성을 원할 때 좋은 일입니다.

이것을 결정하는 사람들은 왜 그것을하고 싶은지, 그리고 거기에 도착하기 위해 얼마나 많은 일을하고 싶은지 고려해야합니다.

엔터프라이즈 개발을 비효율적이고 비싸게 만드는 단 하나의 일이 있다면 모든 것을하는 단일 시스템을 만드는 것이 가능하다는 착각입니다. 시스템의 모든 세부 사항을 이해하고 일주일의 회의 없이도 모든 결정을 내릴 수있는 단일 제품 소유자가있는 경우에는 효과가있을 수 있지만 그런 일은 본 적이 없습니다.

일반적으로 인터넷을 개발하는 것처럼 더 취급한다면 더 나아질 것입니다. 실제로 자신의 코드 외부에서 아무것도 제어 할 수 없다는 것을 인정하면서 자신의 앱을 빌드하십시오. OAuth 및 사용자 설정을위한 간단한 API 및 약간의 공유 CSS로 원하는 거의 모든 일관성을 얻을 수 있습니다.

이것은 SOA의 원래 의도와 매우 유사하지만,이를 호출하면 모든 것을 시도하는 다른 유형의 크고 간신히 작동하는 시스템으로 끝날 것입니다.

나의 첫 번째 생각은 이것이 릴리즈를위한 총 PITA 일 것이라는 것이다.

관리 및 승인의 모든 계층을 피하기 위해 관리 가능한 기능 덩어리로 분할하는 것이 훨씬 합리적입니다.

구성 요소 / 서비스에 공통적 인 요소를 분류하고이를 표준화하는 것이 훨씬 쉽습니다.

Deliverance 와 같은 통합 기술을 사용하여 모든 웹 응용 프로그램의 테마를 비슷하게 지정 하여 다르게 접근 할 수 있습니다 . 기본적으로 각 응용 프로그램은 여전히 ​​분리되어 있습니다. Deliverance는 XSLT 규칙을 사용하여 출력을 디자인 한 정적 HTML 템플릿으로 출력합니다. 이를 통해 비교적 간단한 정적 HTML / CSS 테마를 최소한의 문제로 전체 응용 프로그램 제품군에 적용 할 수 있습니다.