[SPRING] 응용 프로그램 마이그레이션 중에 염두에 두어야 할 사항 : ColdFusion에서 Spring으로

응용 프로그램 마이그레이션 중에 염두에 두어야 할 사항 : ColdFusion에서 Spring으로

이 질문은 마이그레이션 프로젝트에 관한 것입니다. 현재 레거시 응용 프로그램은 ColdFusion에 있으며 Spring Framework로 마이그레이션하려고합니다.

그래서 내 주요 질문은 :

어떤 사람들은 이것이 매우 궁금한 질문이라고 생각할 수도 있습니다. 그러나 이것은 첫 번째 마이그레이션 프로젝트이며 마이그레이션 프로젝트에 대한 경험이 전혀 없으며 여기에 유용한 지침이 무엇인지 찾아 보았습니다.

해결법

1. ==============================

   1.마이그레이션 프로젝트에는 위험이 따른다.

   마이그레이션 프로젝트에는 위험이 따른다.

   첫 번째 위험은 "비싸고 고통 스럽다. 처음부터 새로운 아이디어 나 기능을 구현할 수 있습니다. 모든 마케터 / 매니저 / 프로그래머는 구조화 된 방법론을 사용하고 있습니다. 그리고 어쩌구 저쩌구 ... "이 길은 파멸로 이어진다.

   1) 개방 된 양의 일, 그리고

   2) 오래된 시스템이 실제로 무엇을하는지 아무도 모릅니다. (스펙을 최근에 보았습니까?) 따라서 새로운 시스템이 생겨나 고 오래된 시스템이 실제로 작동하는 조직의 큰 고통과 손상을 입어서 재발견하게 될 것입니다. 새로운 소프트웨어로 사실 새 시스템은 오래된 시스템을 따라 잡을 수 없으므로 다시 작성하면 추악한 죽음을 맞이하게됩니다.

   이러한 마이그레이션을 수행하는 올바른 방법은 기능 만 남겨두고 기존 시스템을 변환하는 것입니다. 새로운 장점, 기능, 방법론이 없습니다.

   그 주장은 그 자체로 문제가 있습니다. 조직은 종종 변화를 주어야합니다. 마이그레이션이 진행되는 동안 생존을 위해

   이를 처리하기 위해 자동화 된 마이그레이션 도구가 실제로 필요하므로 "기능 변경 없음"규칙은 실제 변환 중에 만 적용되므로 가능한 한 짧습니다. 마이그레이션 도구 개발자가이 도구를 빌드하고 철저히 변환 도구를 테스트하는 데 시간이 오래 걸립니다. 그 동안 조직은 일반적인 방법으로 레거시 시스템을 향상시킬 수 있습니다. 마이그레이션 도구가 준비되면 트리거를 당겨 코드를 변환하고 문제를 패치 한 다음 효과를 위해 결과 시스템을 테스트합니다.

   일단 시스템이 마이그레이션되면 근본적인 기능이 여전히 정상적인 것으로 알고 급진적 인 구조 조정 또는 재 형성을 고려할 수 있습니다.

   자동화 된 마이그레이션 도구를 선택하는 경우 생성되는 코드가 새로운 환경에서 유지 관리 될 수 있어야합니다. 진정으로 순진한 1 대 1 전환에 이르는 많은 변환기와 그 결과로 생성되는 코드는 새로운 바에서 기존 코드 또는 COBOL에서 Java 로의 변환 후 웃으면 서 "JOBOL"이라고 불리는 것으로 끝납니다. 변환 도구는 언어 구문을 매핑하는 방법에 대해 정교해야합니다. (PL / 1 To Java 변환에 대한이 SO 토론을 읽어 볼 수 있습니다.)

   가장 큰 문제는 "테스트"입니다. 현재 시스템은 완벽한 기능 테스트를 수행하고 있습니다. 맞습니까? 기능 테스트가 없습니까? 새 시스템이 이전 시스템이 올바르게 수행 한 것을 어떻게 구현하는지 확인 하시겠습니까?

   이에 대한 올바른 대답은 레거시 시스템의 입 / 출력 동작에 대한 테스트를 구성하고 레거시 시스템과 마이그레이션 된 시스템 모두에 해당 테스트를 적용하는 것입니다. 이것은 많은 일이며, 누구도 비용을 지불하지 않고 그것을하고 싶어합니다. 마이그레이션이 실패하는 두 번째 방법입니다.

   마지막으로 일어나는 일은 경영진이 이러한 권리를 수행하는 데 필요한 작업을 낭비하고 undertimes입니다. 일반적으로 개발 팀과의 협상은 다음과 같이 진행됩니다.

   Mgr:  How long to do this?
   Team:  Two years...?
   Mgr:  BZZZT!  Wrong answer, try again...
   Team:  One year?
   Mgr:  BZZT! ..
   Team: (Gulping) 6 months?
   Mgr:  OK, get started.
   

   여기서 어떻게 실제 작업에 대한 논의가 없는지 주목하십시오.

   6 개월이 끝날 때 손가락 가리개가 시작됩니다. 매니저 : "나는 너희들에게 물었고, 당신은 6 개월을 말했다 ..."

   너는 거칠게 타고있다. 조심스럽게 준비하십시오. 사람들이 실제로 모든 이슈를 나열하고 믿을만한 견적을 산출한다고 주장하십시오. 처음 마이 그 레이션을하는 경우 그러한 견적을 내릴 근거가 없습니다. 조직이 처음이라면 어떤 견적이 옳은지 판단 할 근거가 없습니다.

   (전체 공개 : 나는 편견을 갖고 있으며, 22 년 동안 자동화 된 마이그레이션 도구를 구축 해왔다. B2 마이그레이션을 확인하라.)

2. ==============================

   2.CFML 응용 프로그램의 기존 구조에 크게 의존 할 것입니다. Spring의 IoC 부분과 거의 일치하는 CFML을 사용할 수있는 프레임 워크가 있지만, IoC 부분이 아닌 구조화되지 않은 CFML 응용 프로그램에서 Spring Web 로의 마이그레이션을 검토하고 있다고 생각합니다. 한 언어에서 다른 언어로 : CFML에서 Java로.

   CFML 응용 프로그램의 기존 구조에 크게 의존 할 것입니다. Spring의 IoC 부분과 거의 일치하는 CFML을 사용할 수있는 프레임 워크가 있지만, IoC 부분이 아닌 구조화되지 않은 CFML 응용 프로그램에서 Spring Web 로의 마이그레이션을 검토하고 있다고 생각합니다. 한 언어에서 다른 언어로 : CFML에서 Java로.

   현실은 다음과 같습니다. 마이그레이션 프로젝트가 아니며 완전한 기본 재 작성입니다.

   나는 당신이 "이주가 필수 조건"이라고 말한 것을 알고 있습니다. 그러나 나는 당신이 이것을 운전하는 것에 대해 좀 더 설명 할 필요가 있다고 생각합니다. 사람들이 "당신은 미쳤습니다.하지 마세요!" - 귀하가 제공 한 정보가 거의 없기 때문에 아무도 유용한 답변을 제공 할 수 없기 때문입니다.

   ColdFring을 사용하는 잘 구성된 MVC CFML 응용 프로그램이있는 경우 이러한 모델을 마이그레이션하는 방법에 대해 Java 기반으로 모델을 마이그레이션하고 Bean 관리를 위해 ColdSpring 대신 Spring의 IoC를 사용할 수 있습니다. 스프링을 ColdSpring의 부모 빈 팩토리로 설정하여 나머지 CFML 코드가 새로 마이그레이션 된 Bean에 계속 액세스 할 수있게합니다.

   모든 모델 (및 데이터 액세스 계층)을 Java / Spring으로 마이그레이션 한 후에 모든 .cfm 뷰 페이지를 .jsp 뷰 페이지로 변환하고 모든 CFML 컨트롤러 / 리스너를 다시 작성합니다 (어떤 CFML 프레임 워크가 사용 중임)를 Spring 웹 핸들러에 전달한다.

   CFML은 이미 ColdFring을 사용하여 모델을 관리하고있는 잘 구조화 된 MVC 프레임 워크 기반 CFML 애플리케이션을 전제로합니다.

   당신이 시작하는 것은 구조화되지 않은 혼란 (즉, 마이그레이션 지시어가있는 이유입니다)을 생각해 볼 수 있습니다.이 경우 방대한 프로젝트가 방금 더 방대하게됩니다.

from https://stackoverflow.com/questions/2830612/things-to-keep-in-mind-during-application-migration-coldfusion-to-spring by cc-by-sa and MIT license