Home데브기어 새소식기술자료[기술 아티클 요약] 오래된 델파이 버전 프로젝트에서 마이그레이션과 함정(들)

[기술 아티클 요약] 오래된 델파이 버전 프로젝트에서 마이그레이션과 함정(들)

  • 2021-05-13
  • Posted by: Beomyong Park
  • Category: 기술자료
댓글 없음
    • 원문: Migrating your project from older versions of Delphi. The Pitfalls.
    • 저자: Craig Chapman
    • 링크: https://chapmanworld.com/migrating-your-project-from-older-versions-of-Delphi-the-pitfalls/

델파이 마이그레이션을 고려한다면 미리 읽어보면 좋은 글입니다. (엠바카데로 업그레이드 마이그레이션 센터에서도 권장하는 글입니다)

영어 원문을 읽기 불편한 분들을 위해 요약 정리하였습니다.
이 요약 정리를 읽고나서 원문을 보는 것도 권장합니다.

글을 쓰는 목적과 배경

  • 볼랜드 버전을 포함하여 델파이 2009 이전 버전에서 마이그레이션을 할 때 가장 빠지기 쉬운 함정과 해법을 제시하고자 한다. 
    • 델파이로 작성된 애플리케이션이 많다.
    • 최신 버전으로 마이그레이션 하는 것에 대한 질문을 매일 받는다.
    • 지난 20년이 넘도록, 델파이 마이그레이션 작업은 상대적으로 어렵지 않도록 지켜지고 있다.
    • 그렇다고해서 아무 수고도 들지 않는다는 뜻은 아니다!

목차

  • 주제를 다루기 전에, 현대 델파이 버전의 크로스 플랫폼 마이그레이션에 관해 흔히 잘못 이해하는 것들을 짚어보자.
    • 크로스 플랫폼 기대와 시각적 콘트롤을 크로스 플랫폼으로 마이그레이션
    • 크로스 플랫폼으로 마이그레이션 시, 시각적 콘트롤이외의 추가 고려 사항
    • 크로스 플랫폼 마이그레이션 관련 마지막 한마디와 몇가지 희망
  • 버전 마이그레이션 시 빠지기 쉬운 함정과 해답을 찾아보자. (크로스 플랫폼에 관심이 없다면, 여기부터 읽자)
    • 윈도우 64비트 마이그레이션
    • 유니코드 마이그레이션
    • Real 데이터 타입
    • BDE가 사라졌다!
    • 여전히 Paradox를 사용하고 있는가?
    • 써드파티 컴포넌트
    • 마이그레이션하는 데 얼마나 걸릴까?
  • 결론

크로스 플랫폼 기대와 시각적 콘트롤을 크로스 플랫폼으로 마이그레이션

현대 델파이 코드를 컴파일 할 때 타겟 플랫폼은 윈도우 32비트와 64비트, 맥OS, 안드로이드, iOS이다 (역자 주: 지금은 리눅스도 가능).

  • 하지만 델파이가 당신의 윈도우 애플리케이션을 자동으로 크로스 플랫폼으로 바꿔주지는 않는다. 그 이유는
    • 윈도우 용으로 기존에 작성된 것은 윈32 API를 사용한다.
    • VCL 콘트롤 대부분은 윈32 API를 둘러싼 래퍼이다.
    • 당신의 애플리케이션이 VCL 애플리케이션이라면 역시 윈32 API를 사용하므로 다른 플랫폼에서는 작동하지 않는다.

비록 델파이가 이 문제에 대한 마법같은 해결책을 제공하지 않지만, 도움이 되는 몇가지 도구와 방법이 있다.

  • FMX 프레임워크 (크로스 플랫폼 애플리케이션을 작성하는 새 프레임워크, FMX = FireMonkey X-platform, 파이어몽키)
    • 윈32 API 및 컨트롤에 의존하지 않는다.
    • 대신 OpenGL 또는 DirectX를 사용하여 렌더링 컨텍스트에 맞는 API에 직접 컨트롤을 렌더링한다.
    • FMX 프레임워크에는 델파이의 대부분의 VCL 컨트롤들을 꼭닮은 컨트롤들이 있다. (예,TEdit,TButton,…)
  • Mida 변환기
    • 웹 전환 등 유료 버전 안내: http://midaconverter.com/
    • 약점: Mida 변환기는 복사 / 바꾸기를 하는 매크로 도구에 지나지 않는다. 따라서, VCL에 들어있지 않은 컨트롤 (예 : 써드파티 컨트롤)을 마이그레이션 하지 못한다.
  • 써드 파티 컴포넌트라서 Mida 변환기로 전환할 수 없다면
    • 해당 컨트롤의 FMX 버전이 있는지를 찾거나
    • 아니면 다른 써드파티 공급 업체의 FMX 컨트롤로 교체해야한다.
    • FMX 컴포넌트 공급업체 예: TMS소프트웨어; https://www.tmssoftware.com/site/tmsfmxpack.asp

크로스 플랫폼으로 마이그레이션 시, 시각적 콘트롤이외의 추가 고려 사항

델파이에서 지원하는 윈도우 이외의 모든 플랫폼은 어떤 식으로든 유닉스 / 리눅스 변형을 기반, 즉 POSIX 기반이다. 이 때문에 고려해야 할 몇 가지 사항이 있다.

  • POSIX 플랫폼에는 서로 다른 파일 시스템들이 있다. (예: 안드로이드, iOS 또는 맥 기기에는 ‘C :’드라이브가 없다).
    • 애플리케이션에 윈도우 경로를 하드 코딩 한 경우, 동일한 파일을 다른 플랫폼 파일 시스템에서도 찾을 수 있도록 define 조건을 사용하여 코드를 수정해야 한다.
  • 레지스트리가 없다.
    • 일부 플랫폼은 윈도우 레지스트리의 시뮬레이션을 제공하지만 대부분은 그런 것이 없으며 구성 정보는 일반적으로 특정 디렉토리에 저장된다.
    • ‘/ etc’디렉토리는 구성 파일을 저장하는 데 가장 일반적으로 사용되며 미리 지정된 파일 형식이 없다.
    • 어떤 애플리케이션은 .ini 파일 또는 유사한 이름-값 쌍 파일을 사용하고 다른 애플리케이션은 JSON 파일을 사용하고 다른 애플리케이션은 XML 파일을 사용할 수 있다.
    • VCL 애플리케이션이 레지스트리에 있는 구성에 의존하고 있었다면, 다른 플랫폼의 구성 디렉토리에 안의 파일로 마이그레이션해야한다.
    • VCL 애플리케이션이 레지스트리 키 변경을 통해 OS 또는 다른 애플리케이션의 동작을 변경하고 있었다면, 다른 플랫폼에서도 동일한 기능을 할 수있는 방법을 찾아야한다.
  • Kernel32가 없다.
    • 윈도우 API를 직접 호출하고 있었다면, 새 플랫폼에서 동등한 동작을 찾아야한다.
      • 대부분의 경우 FMX 클래스는 답을 제공하지만 애플리케이션이 VCL이라면, FMX가 사용하는 클래스를 사용하지 않을 가능성이 높다.
  • 모든 TCanvas가 동일하게 만들어지지는 않았다.
    • 당신의 코드 또는 써드파티 공급 업체의 코드가 렌더링을 위해 TCanvas를 직접 호출하거나 더 낮은 수준으로 GDI를 직접 호출하는 경우 다른 플랫폼에서 작동하도록이 코드를 마이그레이션해야한니다.
    • FMX 프레임워크도 VCL과 마찬가지로 TCanvas가 있지만 메서드가 모두 동일하지는 않으며 매개 변수 목록도 다르다.
      • 그럴 수 밖에 없는 이유는 VCL TCanvas는 윈도우 GDI 인터페이스로만 렌더링하고 있었기 때문이다.
      • FMX TCanvas는 OpenGL 또는 DirectX와 같은 3D API를 사용하여 렌더링한다. 2D 렌더링의 경우에도 마찬가지이다.
      • 최신 그래픽 카드는 더이상 2D 렌더링을 제공하지 않는다. 다만 2D 그래픽을 3D 공간으로 렌더링 한 다음 특정 위치에서만 보도록 지정함으로써 Z축을 배제한다.
    • 요컨데, VCL TCanvas를 직접 사용하는 코드는 마이그레이션해야한다.
    • 더 자세히 보기: Using the FMX TCanvas; https://chapmanworld.com/2015/08/05/rendering-in-delphi-using-tcanvas-fmx/
  • 데이터베이스 드라이버가 없을 수 있다.
    • 많은 개발자는 TConnection, TTable 및 TQuery (또는 이와 같은 것) 컴포넌트를 사용하여 데이터베이스에 직접 연결하는 데 익숙하다.
      • 이 컴포넌트 세트는 일반적으로 일부 바이너리 드라이버에 의존하며, 안타깝게도 InterBase를 사용하지 않는 한, 타겟으로 삼고있는 ARM-*nix 기반 모바일 플랫폼에 작동하는 드라이버 버전이 없을 수 있다.
    • 모바일 플랫폼에서 작동하는 드라이버가 없다면 애플리케이션에서 데이터베이스에 직접 연결할 수 없다.
    • 혹시 가능하더라도, 인터넷이 언제라도 불안정할 수 있는 모바일 환경에서 직접 연결하기를 원하지 않을 수도 있다.
    • 이 문제에 대한 가장 일반적인 해결책은 REST 기반 웹 서비스를 사용하여 데이터를 JSON 형식으로 노출하는 것이다 (그 다음으로 일반적인 방식은 SOAP 서비스이다).
    • 델파이에는 JSON / REST / SOAP 작업을 위한 여러 컴포넌트가 있으며 JSON 서비스를 TQuery 방식 컴포넌트에서 반영할 수도 있다.
      • 하지만, 어쨌든 이전 데이터 액세스 컴포넌트에서 마이그레이션해서 나와야한다.
    • 더 자세히 보기: JSON/REST with Delphi, http://chapmanworld.com/2015/01/18/json-with-radstudio-delphi-or-c-builder/
    • 더 자세히 보기: Why you shouldn’t connect your mobile application to a database; http://chapmanworld.com/2015/07/02/why-you-shouldnt-connect-your-mobile-application-to-a-database/
    • 더 자세히 보기: BaaS  solutions with Delphi; http://chapmanworld.com/2015/01/18/radstudio-baas-with-kinvey/
    • 더 자세히 보기: Datasnap Tutorial; http://chapmanworld.com/2015/07/15/datasnap-mobile-client-tutorial/
    • 더 자세히 보기: Datasnap and FireDAC exposing MSSQL; http://chapmanworld.com/2015/07/17/datasnap-firedac-and-mssql-tutorial/
  • 모바일 컴파일러에는 몇 가지 차이점이 있다. (델파이는 여러 컴파일러를 사용하여 단일 소스 코드, 여러 대상 플랫폼 기능을 구현한다. 윈도우32 용 컴파일러, 윈도우64 용 컴파일러, 안드로이드, iOS 및 맥 용 컴파일러. 이 모든 컴파일러가 100% 호환되는 것은 아니지만 99.9%로 충분히 좋다.)
    • ARC 메모리 관리 모델
    • Ansi 문자열이 없다.
      • 모바일 컴파일러는 Ansi 문자열을 전혀 지원하지 않는다. StrAlloc(), StrDispose() 등의 함수가 빠진다.
      • Ansi 문자열을 반드시 사용해야한다면 배열이나 버퍼에 넣고 포인터를 사용하여 작업해야한다. 하지만 포기하는 것이 좋다. 그 이유는 최신 OS 또는 최신 소프트웨어가 더 이상 사용하지 않기 때문이다!
      • 유니코드 마이그레이션은 약간 두려울 수 있지만 그다지 무섭지는 않으며 그만한 가치가 있다. (이 페이지의 뒷부분 참조) 
    • 문자열 인덱스가 0부터 시작!
      • 다른 모든 배열 스타일 액세스는 0부터 인덱싱되는데, 유독 기존 파스칼 문자열만 1부터 인덱스가 시작되었었다.
      • 하지만, 델파이 모바일 컴파일러에게는 더이상 1이 아니라 0부터 인덱싱된다. 정들었겠지만, 1부터 시작하는 문자열 인덱스는 잊자. 이제 그만 놓아주어야 할 때이다. 

크로스 플랫폼 마이그레이션 관련 마지막 한마디와 몇가지 희망

델파이가 자신의 애플리케이션을 다른 플랫폼으로 마이그레이션 할 것이라는 잘못된 기대를 가진 대부분의 개발자의 경우 중요한 핵심을 하나 놓치고 있는데, 바로 ‘실제로는 애플리케이션을 해당 플랫폼으로 마이그레이션하고 싶지 않다’는 점이다.
당신이 그들 중 하나라면, 지금 이 의견과 함께 하길 바란다.

  • 모바일 화면은 작은데다가 (정밀한 마우스가 아니라) 뭉툭한 손가락으로 작동한다.
  • 모바일 장비는 데스크톱과 비교할 때 리소스 (RAM, 디스크 공간, CPU 등)도 부족하다다.
  • VCL 애플리케이션을 FMX로 그대로 마이그레이션하고 모바일 장비에 배포하면 작은 화면에서 사용할 수 없거나 장비 리소스 부족으로 인해 성능이 끔찍할 수 있다.
  • 대부분의 경우 훨씬 더 현명한 전략은 모바일 애플리케이션을 위한 완전히 새로운 프로젝트를 시작하는 것을 고려하는 것이다.
    • 이 ‘동반자 앱’프로젝트 역시 결국 여전히 파스칼이므로 비시각적 코드의 많은 부분을 여전히 사용할 수 있다.
    • 그리고, 새 프로젝트를 실제로 휴대 기기에서 의미가있는 기능으로만 범위를 제한 할 수 있다.
    • 뿐만 아니라 델파이는 모바일 ‘동반자 앱’을 기존 데스크톱 애플리케이션과 함께 네트워크에 통합할 수 있도록 하는 몇 가지 클래스를 제공한다. 예를 들어,

윈도우 64비트 마이그레이션

윈도우 32비트에서 윈도우 64비트로 마이그레이션은 완전히 다른 플랫폼으로 마이그레이션하는 것보다 훨씬 덜 위험한 작업이지만, 내 경험 상 한 가지 함정이 있다.

  • 정수와 포인터가 같은 크기 (32비트)라고 가정하는 것은 델파이 개발자 커뮤니티에서 매우 일반적인 관행이었다.
    • 델파이의 클래스 인스턴스가 실제로는 특별한 포인터라는 점을 고려하면, 클래스를 정수로 형변환하여 정수 배열에 저장할 수 있었다.
    • 이 외에도 VCL의 시각적 클래스에 있는 TAG 속성의 형식이 32 비트 정수였으므로, 형변환을 변칙적으로 이용하면 TAG 속성을 일종의 오브젝트 포인터로 사용할 수 있었다.
    • 만약 당신이 직접 또는 당신이 사용하는 써드 파티 소스에서 이렇게 했다면 문제가 생긴다.
      • 윈도우 64비트에서 포인터는 당연히 64비트 너비이지만 정수 타입은 32비트 너비로 유지된다. 
      • 다른 데이터 타입에 적용하려면 코드를 변경해야한다. 이를 지원하기 위해 새로운 정수 데이터 타입이 몇가지 추가되었다.
      • NativeInt 및 NativeUInt는 정수로 작동하지만 항상 대상 플랫폼의 포인터 너비와 일치하는 새로운 데이터 타입이다.
  • 64비트 용으로 코드 수정을 시작하기 전에 정말로 필요한지 자문 해보자.
    • 64비트 코드에 대한 일반적인 오해가 많으며 업그레이드에 따른 이점이 거의 없는 경우도 많다.
    • 지금은 컴퓨터가 8비트 시대에서 16비트로 또는 16비트에서 32비트로 이동할 때와 같은 같은 상황이 아니다.
    • 애플리케이션을 64비트로 업그레이드하는 가장 일반적인 이유 중 하나는 더 많은 주소를 지정할 수 있는 메모리 공간을 애플리케이션에게 제공하기 위해서이다.
      • 8비트 프로세서를 사용하면 256바이트의 RAM 만 처리할 수 있으므로, 그 이상을 처리하려면 뱅크 전환 작업이 필요하므로 시간이 더 걸렸다.
      • 16비트에서는, 64KB의 RAM을 처리 할 수 있었지만 그 이상을 처리하려면 여전히 뱅크 전환이 필요했다.
      • 32비트에서는 4GB RAM을 처리 할 수 있다! 오늘날에도 이것은 대부분의 애플리케이션에게 충분하며 윈도우32 비트는 어떤 경우에도 애플리케이션에서 2GB 만 사용할 수 있도록 허용하고 나머지 2GB는 커널 공간으로 남겨둔다.
    • 몇가지 예외가 있겠지만, 당신의 애플리케이션이 2GB 이상의 RAM을 사용한다면, 아마 뭔가 잘못했을 수 있다. 예를 들어 데이터베이스에서 수백만 행의 데이터를 끌어 오는 경우 모든 데이터를 RAM에 보관해야할까?
      • 화면에 모두 표시 할 수 있더라도 수백만 개의 행을 한눈에 보고 싶어하는 사람은 없으므로 디스크 파일에 캐시하는 것이 더 나은 전략 일 수 있다.
      • 기본적으로 대부분의 애플리케이션은 주소 지정 가능 2GB-4GB RAM에서 작동되므로 업그레이드 할 필요가 없을 수 있다.
    • 속도는 어떨까?
      • 64비트 프로세서는 32비트 프로세서보다 더 빠르지는 않다.
      • 속도 이점은 더 넓은 정수를 처리 할 수 있다는 점에서 비롯된다. 따라서 애플리케이션이 매우 큰 수를 처리해야하는 경우 64비트로 업그레이드하면 성능이 향상 될 수 있지만
      • 코드에서 64비트 숫자 데이터 타입을 사용하지 않고 있지 않다면, 코드 전체에 있는 32 비트 타입을 해당 64 비트 타입으로 변경해야한다.
      • 동일한 애플리케이션을 64비트를 타겟으로 다시 컴파일한다고 해서 그렇게 되지 않는다.
    • 궁극적으로 업그레이드 할 이유가 전혀 없을 수 있다.
    • 그리고 64비트 실행 파일이 32비트보다 훨씬 크다는 점을 기억하자. 모든 연산과 인코딩이 더 크기 때문이다. 64비트로 가기 전에 꼭 필요한지를 확인하도록 하자.

유니코드 마이그레이션

끔찍한 유니코드 마이그레이션은 어떻게든 너무 많은 개발자를 두렵게 하고 있는 것 같다!
유니코드는 실제로sms 그다지 두려운 존재가 아니며, 델파이는 유니코드 시대로 넘어온 모든 컴파일러 제품 중에서 가장 쉬운 것 중 하나이다.

  • 몇몇 프로젝트에서는 전혀 변경할 것 없이 컴파일러가 간단히 처리해 줄 것이다. 하지만, 어떤 프로젝트에서는 일부 변경이 필요하고, 또 어떤 프로젝트에서는 많은 변경이 필요할 수 있다.
  • 대부분의 경우 컴파일러는 코드가 계속 예상대로 컴파일되고 작동하도록 문자열 타입을 알아서 정상적으로 강제한다.
  • 그렇게 하는 못할 수도 있는데, 일반적으로 다음과 같은 경우이다.
    • 문자열을 사용하여 바이너리를 저장하고 있다.
      • 어떤 사람들에게는 이것이 미친 생각처럼 보일 수 있을 것이다.
      • 하지만, 델파이의 초기 버전은 바이너리 데이터 (바이트 배열 없음) 저장에 제한이 있었기 때문에 창의적인 델파이 엔지니어는 문자열을 사용하여 바이너리 데이터를 저장하기도 했다.
      • 이런 코드는 이미 오래전에 교체되었어야 한다. 이미 20년이나 고칠 기회가 있었다!
      • 여전히 이런 코드를 사용하고 있다면 이제 어쩔수 없이 수정해야 한다. (컴파일러는 당신이 문자열 타입을 이렇게 잘못 사용하고 있다는 점을 알 수 없으므로 도와줄 수도 없다.)
    • 직렬화(Serialization) 및 역직렬화(Deserialization).
      • 애플리케이션에서 문자열을 직접 직렬화 (즉 바이트 단위로 스트림에 전달)하여 디스크 또는 데이터베이스에 저장했다면, 직렬화 시점에 해당 문자열은 ANSI 이었을 것이다. 
      • 코드를 최신 델파이 컴파일러로 마이그레이션하고 나면, 애플리케이션은 파일에서 문자열을 역직렬화할 때 각 문자가 16비트 너비인 UTF16-LE 유니코드 문자열로 시도한다
        (일부는 32비트 인 것을 저장하지만 복잡한 내용이므로 유니코드에 대한 더 많이 읽어볼 필요가 있다).
      • 따라서 이전에 직렬화된 데이터를 역직렬화로 풀어낼 수 없다.
      • 한가지 해결책은 해당 문자열을 바이트 배열로 읽고 바이트 배열을 현재 RTL에 들어있는 많은 유니코드 변환 루틴 중 하나에 전달하여 ANSI 문자열에서 UTF16LE 문자열로 변환하는 것이다.
    • 이전 API를 호출한다.
      • 윈도우는 오래 전에 유니코드로 전환되었다.
        • 윈32 API가 업그레이드 될 때, 각 API 호출의 새 버전은 뒤에 ‘W’를 붙여서 해당 호출이 와이드 문자열 버전임을 나타낸다.
        • 와이드 문자열은 윈도우에서 사용하는 특수 문자열 타입이지만 그안에 포함된 데이터는 본질적으로 UTF16-LE이며, 현재 델파이의 기본 문자열 타입과 동일한 타입의 데이터이다.
        • 어쨌든 이전 ANSI 기반 API를 호출하면서 문자열 (현재 UTF16)을 전달하는 경우 컴파일러에서 불평할 수 있다.
        • 대부분의 경우 컴파일러는 사용자를 대신하여 변환을 처리하지만 이러한 상황이 발생했음을 알 수 있도록 경고가 생성되며 한두개 매개 변수의 타입을 변환해야 할 수도 있다.
        • 이렇게해서 계속 유지할 수 있지만 가능하면 해당 API을 유니코드 형식으로 마이그레이션하는 것이 이상적이다.
      • 일부 컨트롤은 유니코드에서 다르게 작동한다!
        • 대부분의 VCL 컨트롤은 윈도우 API에서 제공하는 컨트롤을 둘러싼 래퍼이다.
        • VCL을 유니코드로 마이그레이션하는 과정에 많은 ANSI API 호출은 유니코드 API 호출로 대체된다.
          • 최근 TRichEdit 컴포넌트의 ‘SelStart’ 및 ‘SelLength’속성이 작동하는 방식에서 불일치가 있었다.
          • 캐리지 리턴은 유니코드 이전 버전이므로 현재 이러한 속성에서 계산되지 않다.
          • 이 문제에 대한 몇 가지 해결책이있는 블로그 게시물을 여기에 추가했다. http://chapmanworld.com/2015/11/04/trichedit-behaves-differently-under-unicode/ 
      • 델파이를 사용한 유니코드 마이그레이션에 대한 자세한 내용 (여기에서 다루는 것보다 훨씬 더 자세한 내용)
      • http://www.embarcadero.com/rad-in-action/migration-upgrade-center

Real 데이터 타입

버전 마이그레이션에 대한 논의에서 종종 무시되는 것은 오래된 ‘Real’ 데이터 타입이 컴파일러에서 제거되고 ‘Double’데이터 타입을 가리키는 별칭이 되었다는 것이다.
무시되는 이유는 문제가 되는 경우가 매우 드물기 때문이다.
하지만 Real 타입을 사용한다면 주의하자. 왜냐하면, 유니코드 마이그레이션과 마찬가지로 이 작은 변경은 이전 델파이 버전에서 컴파일된 애플리케이션에서 직렬화한 데이터를 역직렬화를 통해 풀어낼 때 문제가 될 수 있다.

BDE가 사라졌다!

당황하지 않아도 된다. BDE는 아직 완전히 사라진 것은 아니지만 더 이상 사용되지 않다.
기본적으로 BDE는 더 이상 델파이와 함께 제공되지 않지만 델파이 구매 후 EDN 계정에서 별도로 다운로드 할 수 있다.
사라진 이유는 BDE가 매우 오래되었고 유니코드 지원이 부족하고 훨씬 우수한 FireDAC로 대체 되었기 때문이다.

여전히 Paradox를 사용하고 있는가?

일부 오래된 애플리케이션은 여전히 Paradox 데이터베이스를 사용하고 있다.

  • Paradox 데이터베이스는 더 이상 지원되지 않으므로 다른 데이터베이스 엔진으로 마이그레이션해야 한다.
    • 데이터베이스 요구 사항을 Paradox로만 다루어왔다면 보다 현대적인 데이터베이스를 활용하기 위해 약간의 SQL 및 DDL도 배우고 싶어질 것이다.
    • SQL 강의는 이글의 범위 밖이므로 온라인에서 훌륭한 튜토리얼을 찾을 수 있으며 가치있는 시간이 될 것이다! 분명하다!
    • Marco Cantu on migrating from Paradox and dBase; http://blog.marcocantu.com/blog/migrating_paradox_dbase.html
    • W3Schools SQL Tutorial; http://www.w3schools.com/sql/

써드파티 컴포넌트

마이그레이션 시, 가장 중요한 것이다!
일부 개발자는 써드파티 컴포넌트를 좋아하고 다른 개발자는 싫어한다.
하지만 당신이 어느쪽이든 적어도 일부 써드파티 컴포넌트를 사용하고 있을 것이다.

  • 써드파티 컴포넌트를 싫어하는 두 가지 가장 큰 이유는 다음과 같다.
    • 공급 업체에 문제가 있다. 업데이트, 버그 수정 등을 제공한다도 신뢰할 수 없거나 완전히 사라 졌을 수 있다.
    • 컴포넌트에 문제가 있다. 잘못 작성된 컴포넌트는 애플리케이션의 안정성과 RAD스튜디오 IDE에 영향을 미칠 수 있다.
  • 그러나 당신이 공급 업체를 신중하게 선택했다면, 유지 관리가 빈번하고 RAD스튜디오 / 델파이를 근본적으로 향상시키는 안정적인 고품질 컴포넌트를 제공하는 우수한 써드파티 컴포넌트 세트를 찾을 수 있다.
  • 해당 컴포넌트의 최신 버전이 있어야 프로젝트를 이전 델파이 버전에서 새 버전으로 마이그레이션할 수 있다.
  • 엠바카데로는 써드파티 컴포넌트 사용을 돕기 위해 IDE 내에서 GetIt을 제공한다. 일부 컴포넌트는 GetIt 안에서 자동으로 설치할 수도 있다.
    • 참조 : RadStudio XE8 gets a component repository!
    • 이 저장소의 컴포넌트 컬렉션은 계속 증가하고 있다.
    • 엠바카데로는 많이 사용하는 컴포넌트를 제조사가 버리거나 포기한 것들에 대해 투자하여 업그레이드를 제공하기도 한다.
    • 엠바카데로는 또한 리포지토리의 컴포넌트가 최신 델파이 버전으로 최신 상태로 유지되도록 보장하고 있으므로 향후 해당 컴포넌트를 다시 찾지 않아도 된다.
    • 역자 주: 지금은 GetIt에 들어있는 컴포넌트가 400여가지 이상으로 늘어났다.
  • 당신이 사용하고 있는 써드파티 컴포넌트가 불행히도 더이상 유지 관리되지 않는다고 하더라도,
    • 당신이 소스 코드를 구매할만큼 현명했다면 해당 코드를 최신 버전의 델파이에서 컴파일하도록 업데이트하는 것이 상대적으로 사소한 작업이다.
      • 예를 들어, SAP가 아직 델파이 XE8 용으로 업그레이드하지 않았기 때문에 나는 최근 Advantage database components 에 대한 업데이트를 게시했다. 이 경우 내가 코드에서 변경해야 했던 것은 현재 컴파일러 버전 번호를 포함하도록 조건부 정의를 변경하는 것 뿐이었다. 그게 전부였다!
  • source forge에서 찾은 컴포넌트를 사용했지만 유지관리가 더이상 되고 있지 않는다고 보인다면,
    • GitHub로 가서 해당 프로젝트가 마이그레이션되었는지 확인하자. 대부분이 GitHub에 있고 변경할 필요나 경고도 없었다. 
  • 마지막으로, 더 이상 유지되지 않고 소스 코드가 없는 써드파티 컴포넌트를 사용했다면,
    • 업그레이드하려면 다른 공급 업체의 동등한 컴포넌트를 찾아서 해당 컴포넌트에 맞게 코드를 수정해야한다.
    • 수십 년 동안 기업은 델파이 커뮤니티에 들어오기도 하고 떠나기고 했다. 따라서 이런 일이 없을 수는 없다.

마이그레이션하는 데 얼마나 걸릴까?

상황에 따라 다르다. 프로젝트에 따라 크게 다를 수 있다.
마이그레이션 함정에 해당되는 것이 하나도 없을 수도 있고, 불행하게도 모든 함정을 다 가지고 있을 수도 있다. 

  • 내 C++ 고객 중 일부는 코드가 60,000 줄인 C++빌더 프로젝트를 변환하는 데 평균 하루가 걸렸다고 알려왔다.
  • C ++빌더는 델파이와 별개인 제품이지만, 어차피 VCL 및 FMX 기반이며 유니코드 마이그레이션까지 포함한 경우이다.
  • 결국 이런 수치는 모호한 안내가 될 수 있다. 위에 링크된 유니코드 마이그레이션 통계 도구를 사용하자. 그리고 보수적으로 접근하자. 하지만, 마이그레이션을 두려워하지는 말자.

결론

  • 이 중 크로스 플랫폼 마이그레이션에 대해서도 검토할 필요가 있다.
  • 델파이는 이미 20년 동안 업그레이드 되어 왔다는 점을 생각하자. 델파이의 버전 호환성 수준은 매우 높다. 하지만, 델파이 역시 세월을 따라 변화해온 성숙한 제품이다.
  • 현대 델파이는 (적어도 제 생각에는) IDE 중에 누구에게도 뒤지지 않는 많은 기능을 가지고 있다.
    • 기대할 수있는 언어의 모든 최신 기능을 갖추고 있으며 데스크톱, 멀티-티어, 엔터프라이즈, 클라우드 및 모바일 개발 영역에서 역할을 해오고 있다.
    • 최신 버전을 사용하지 않는다면 많은 것을 놓치고 있다!
  • 마이그레이션이 잘 진행되기를 바란다.
        • 원문: Migrating your project from older versions of Delphi. The Pitfalls.
        • 저자: Craig Chapman
        • 링크: https://chapmanworld.com/migrating-your-project-from-older-versions-of-Delphi-the-pitfalls/

12.0 12.1 AI AWS C++ c++빌더 chatgpt DelphiCon ios rad서버 RAD스튜디오 UI UIUX UX uxsummit vcl 개발 개발사례 고객사례 기술레터 기술백서 데브옵스 데이터 데이터베이스 델파이 리눅스 마이그레이션 맥 머신러닝 모바일 새버전 샘플 세미나 안드로이드 웹 윈도우 인공지능 인터베이스 출시 커뮤니티에디션 코드 클라우드 파이썬 파이어몽키 현대화

Post Views: 351