Home데브기어 새소식기술자료[기술백서] 델파이 마이그레이션 요구 사항 TOP 5

[기술백서] 델파이 마이그레이션 요구 사항 TOP 5

  • 2020-09-21
  • Posted by: Narae Kim
  • Categories: 기술자료, 메인 노출
댓글 없음

[기술백서] 델파이 마이그레이션 요구 사항 TOP 5

엠바카데로의 Al Mannarino와 Mary Kelly는 고객사 수백곳에서 델파이 업그레이드 컨버전 작업을 도왔습니다.Al과 Kelly가 꼽은 마이그레이션 때마다 나오는 요구 사항 Top5와 해당 팁을 5번부터 1번까지 알아봅니다.이 비디오의 주요 내용을 아래와 같이 한글로 번역하였습니다.

 

[두 사람이 선정한 5위]

Al 선정 –  Runtime 오류 해소

마이그레이션 후, 경우에 따라 Runtime 오류가 발생할 수 있다. 이전 버전에 있던 폼의 프로퍼티가 새 버전에서 없어졌다거나, 윈도우에서 더이상 제공되지 않는 오래된 dll을 사용하는 경우에 런타임 오류가 발생한다. 이런 오류는 애플리케이션을 실행하기 전까지는 알 수 없다. 까다로운 경우는 오래된 써드 파티 라이브러리를 사용했는데 이 오래된 컴포넌트가 그리드의 ColumnCount 속성을 폼 디자이너에서 사용했다면 (제작 당시에는 델파이 폼디자이너에 있던 속성) 애플리케이션을 실행하면 “그리드에서 ColumnCount라는 프로퍼티를 찾을 수 없습니다”라는 오류가 발생한다. 소스 코드에서 ColumnCount라는 변수를 찾으려고 해도 소스 코드에서 찾을 수 없는데, 왜냐하면 ColumnCount는 소스 파일 (델파이라면 .pas)이 아니라, 폼 파일(델파이라면 .dfm)에 있기 때문이다.  따라서 dfm 파일을 열어서 ColumnCount를 찾아서 삭제 또는 수정해야 한다.

 

Kelly 선정 – UI 현대화 (윈도우10 포함)

UX는 뜨거운 관심을 받고 있다. 사용자에게 최상의 UI나 UX를 제공하는 것이 매우 중요해졌다. 오래된 애플리케이션은 윈도우 10에서 작동된다고 해도 화면이나 사용 방식이 윈도우 10과 이질적이다. 개발자는 마이크로소프트에서 소개한 새로운 기능을 반영하거나, VCL 스타일을 적용하거나 모바일 환경에 맞게 변화시키고 싶어한다.  마이그레이션 후 사용자가 가장 먼저 만나는 것이 화면이다. 화면을 봤을 때 매력적이지 않다면, 아무리 많은 개선이 있었다고 해도 사용자에게 전달되지 않는다. 개발자는 사용자가 새 애플리케이션을 기쁘게 받아드리기를 바라기 때문에 시작적으로 매력적인 애플리케이션을 제공하고 싶어한다. 10.4에는 여러가지 VCL 스타일들이 들어 있다. 원하는 것을 선택하면 사용자에게 새로운 룩앤필을 적용할 수 있다. (Ball- 화면 변경은 사실 매우 큰 변경 작업이라서 5위보다 순위가 높을 것이라고 생각했었다. 하지만, RAD 스튜디오에서는 스타일을 이용하면 쉽게 반영할 수 있는 문제이므로 5위인 것이 이해된다)

 

 

 

[두 사람이 선정한 4위]

Al 선정 – 미들웨어

오래전 미들웨어는 COM기술을 기반으로 한 Midas가 사용되었다. 하지만 지금은 데이터스냅(DataSnap)과 RAD서버가 사용된다. Midas를 사용하여 구축된 멀티티어 애플리케이션은, 반제품인 데이터스냅이나 완제품인 RAD서버로 마이그레이션하여 COM에 대한 종속성을 없애야 한다. 그리고 전환 방법은 “Midas에서 데이터스냅으로 전환하기” 와 “데이터스냅에서 RAD서버로 전환하기” 기술 백서에 잘 설명되어 있으므로 잘 활용하기 바란다.

 

Kelly 선정 – 미들웨어

애플리케이션을 웹과 모바일로 확장하는 추세이다. RAD서버나 데이터스냅을 도입하게 되면 기존의 애플리케이션 기술과 사용자 기반을 웹과 모바일로 확장할 수 있으므로 요구가 많다고 생각한다.

 

 

 

[두 사람이 선정한 3위]

Al 선정 – 데이터베이스 전환

마이그레이션 시 데이터베이스 마이그레이션은 항상 수반된다. BDE를 사용하는 애플리케이션이 아직도 얼마나 많은지 알고 놀랐다. BDE는 델파이 3,4,5 시절의 엔진이고 당시의 파라독스나 dBAse를 연결할 때 사용되었다. BDE는 지원이 중단된지 15년이 넘었고, 그동안 계속해서 BDE에서 벗어날 것을 권장해왔는데도 불구하고 (각자 나름의 이유가 있었겠지만) 여전히 BDE가 많이 사용되고 있다. BDE는 사용하지 말아야 한다. 왜냐하면 15년 전에 중단되었을 뿐만 아니라, 유니코드와 64bit를 지원하지 못하기 때문이다. BDE는 훨씬 새로운 고성능 컴포넌트인 파이어닥(FireDAC)으로 전환해야 한다. reFind라는 유틸리티를 사용하면 매우 쉽게 자동 전환할 수 있다. reFind는 실행하면 시간 낭비할 필요없이 BDE 구문을 찾아서 FireDAC으로 전환한다.

 

Kelly 선정 – FireDAC으로 이전

나도 역시 여전히 BDE 사용자가 많아서 놀랐다.  마이그레이션 시에는 반드시 BDE를 제거해야 한다. 특히 윈도우10에서 BDE는 완전히 멸종된 기술이라서 항상 문제가 될 것이다. reFind를 사용하면 쉽게 FireDAC으로 전환할 수 있다. 게다가 파라독스 같은 오래된 DB에서 테이블을 열어서 필터링을 하던 방식을 벗어나야 한다. SQL구문을 활용해 DB를 다루고, 데이터 액세스 방식과 내용에서 보다 효율적인 데이터베이스를 사용하기 바란다. 요즘 데이터 보안이 강조되고, 파일과 데이터 액세스 암호화에 대한 관심이 매우 높다.  FireDAC으로 전환하면 SQL서버, 인터베이스, 오라클 등 견고한 데이터베이스를 사용할 수 있고 이런 DB의 수준 높은 기능을 사용할 수 있게 된다. (Ball – BDE 이외에도 DBExpress와 ADO도 여전히 사용되지만 역시 보안 등의 측면에서 FireDAC으로 전환할 것을 권장한다)

 

 

 

[두 사람이 선정한 2위]

Al 선정 – 유니코드

유니코드는 흥미로운 주제이다. 개발자들은 유니코드 반영이 매우 어려울 것이라고 생각하지만 실제로는 그렇게 어렵지는 않다. 가장 먼저 해야할 질문은 “유니코드가 꼭 필요한 애플리케이션인가 아니면 영어버전으로만 계속 사용해도 충분한가”이다. 만약 영어버전만 사용한다면 String 이나 Unicode String을 사용하지 않고, Ansi string을 사용하면 된다. 하지만 유니코드로 가고 싶다면 Unicode Statistics라는 도구를 사용하라. 이 도구는 유니코드 전환 복잡도를 측정하고, 전환 시 변환되어야 하는 코드를 알려준다.

String을 많이 사용했다고 걱정하는데 오해이다. 전혀 손댈 필요가 없는 경우도 많다. 이것은 string을 어떻게 사용했는가에 따라 달라지는 것이지 코드의 모든 string이 변환되어야 하는 것은 아니다.  컴파일러는 똑똑해서 유니코드 변환이 필요한 곳을 알려준다. 경험 상 유니코드 전환은 생각보다 훨씬 쉽다. 일단 유니코드로 전환하고 나면 영어권 이외로 진출할 수 있다. 컴파일을 하면 컴파일러가 ansi string과 string 타입이 맞지 않는다는 오류를 표시하므로 쉽게 파악할 수 있다. 컴파일러는 타입 캐스팅을 할 수 있지만 확신이 들지 않아서 에러를 표시하는 것이므로 컴파일러가 원하는 타입으로 변환하는 것이 가장 쉬운 방법이다.

 

Kelly 선정 – 유니코드

유니코드 반영은 작업이 크고 가장 어렵다. 예를 들어 C++을 업그레이드 하려다보면 C++03 표준에서 C++17 표준으로 크게 넘어가는 경우가 많다. 이때 언어 표준에서 그동안 어떤 변화가 있었는지를 알아야하고,단순히 에러만 해소하도록 고쳐나가는 것이 좋을 지 아니면 코드 일부를 아예 다시 작성하여 유니코드 반영 뿐만 아니라 C++의 새 기술을 적용하여 향상할 수 있도록 하는 것이 좋은지를 고민하게 된다.

(Kelly – docwiki는 유니코드 전환 시 제공되는 컴파일러의 에러 코드에 대한 설명과 해소법이 제공되므로 활용하면 좋다)

 

 

 

 

[두 사람이 선정한 1위]

Al 선정 – 써드파티 컴포넌트

마이그레이션 준비 시 가장 먼저 해야할 질문은 “사용한 써드파티 컴포넌트가 무엇인가?” 이다. 써드파티 라이브러리와 플러그인 역시 모두 다시 컴파일되어야 하기 때문이다. 소스코드가 있다면 더 쉽다. 소스를 가져와서 다시 빌드하면 된다. 소스코드가 없는 것들은 현재 개발툴에서 작동하는 버전을 사용해야한다. RAD스튜디오(델파이, C++빌더) 개발툴 안에 있는 겟잇 패키지 매니저에서는 써드파티가 250여가지가 제공된다. 여기에서 검색을 하면 해당 개발툴에서 작동이 보장된 버전을 바로 찾아서 설치할 수  있다. 인터넷에서 각 써드파티 마다 새 버전을 검색하고 찾은 것이 현재 개발툴에서 작동되는지를 일일이 확인 하는 수고를 덜 수 있으므로 겟잇 패키지 매니저를 잘 활용하기 바란다. JEDI, 터보파워 등 오픈 소스 써드파티 뿐만 아니라 TMS, Woll2Woll 등 상업용 써드파티의 평가판이 제공된다.

 

Kelly 선정 – 써드파티 컴포넌트

마이그레이션 전에 가장 먼저해야 할 작업은 사용하고 있는 써드파티 컴포넌트를 확인하는 것이다. 소스 코드가 있으면 다시 컴파일을 하고 소스 코드가 없는 것들은 업그레이드된 버전을 찾아야 한다. 만약 두 경우가 아니면 곤란할 수 있는데, 이때는 고생해서 억지로 끼워맞추기 보다는 오히려 TMS, DevExpress, JEDI 등으로 옮기는 것이 더 쉽고, 결과적으로 더 애플리케이션이 더 향상된다.

Post Views: 196