마이그레이션 델파이 레거시 프로젝트를 업그레이드하기 & 유지하기

[Kori]

짐 맥키트 (Jim McKeeth)의 "Upgrading and Maintaining Delphi Legacy Projects" 을 번역했습니다. (원문 작성: 2022년 11월, 최종 번역: 2022년 11월)

레거시 프로젝트는 작성되고 나서 오랫동안 지속적으로 가치를 제공하고 있는 코드를 말한다. 이런 레거시 프로젝트를 관리하고, 필요한 새 기능을 추가하고, 지금 그리고 앞으로도 계속해서 새 플랫폼에서 작동하도록 보장하고 싶을 것이다.

이 웨비나는 그것을 위해서 준비되었다. 레거시 프로젝트를 현대화 하는 방법으로 재설계(redesign)와 재작성(rewriting)의 위험(risk)을 서로 평가해 보자. 테스트 가능한 코드를 만들고 테스트 프레임워크를 추가함으로써 재작업의 위험을 최소화하면서도 리팩토링을 해나가는 최고의 접근법에 대해 알아보자.

이 웨비나에 참여하여 짐 매키드가 "델파이 레거시 프로젝트: 전략과 생존 가이드"의 저자인 Bill Meyer와 인터뷰를 통해 레거시와 함께 살고 있는 당신의 삶에서 새 숨결을 느껴보자.

델파이 레거시 프로젝트를  업그레이드하기 & 유지하기 발표자료 다운로드

 

질의	질문자	응답
델파이 11.2, Arm Win 11과 4K 모니터를 가지고 있다. 오래된 VCL 프로젝트를 열면, 폼이 너무나 작다. 폼 디자이너의 크기를 어떻게 변경하면 되나?	P.R.	High DPI 메뉴 설정을 보라. 위치: Tools>Options>IDE>Form Designer>High DPI
오래된 버전 있던 bdsproj 파일을 여전히 가지고 있다 - 델파이 10.4와 그 이후 버전에서는 이제 삭제해도 안전한가?	R.T.	bdsproj는 2006과 그 이후에 사용된 것이다. 10.4에서는 필요없다.
우리는 종종 오래된 프로젝트를 새 버전으로 마이그레이션을 시도할 것인지 말 것인지를 결정하는 문제로 고민한다. 오래된 앱을 그냥 유지할 것인지 아니면 업그레이드의 고통을 뚫고 앞으로 가야하는지를 결정할 때 조언해줄 장단점이 있나?	J.Z.	비용 효율 분석을 해 볼 수 있다. 하지만, 대체로 기존 애플리케이션이 작동하고 있고 복잡하다면 리팩토링을 하는 것이 일반적으로 더 좋다.
내가 가진 정말 오래된 레거시 프로젝트는 TopSpeed Modula/2와 DOS에서 작동한다.	D.M	와!
이것은 매력적이다. 나는 자칭 "포렌식 개발자"라고 부르면서 경력을 쌓는 동안 레거시 코드 베이스를 만나왔는데, 종종 최소한의 문서만 있고, 코드는 좋지 않고, 최초 개발자는 오래전에 떠난 것들이다, 그 코드 안에 들어가서, 신속하게 방법을 찾아서 수정과 향상 작업을 시작한다.	S.P.	유용한 방법 같다.
우리의 레거시 프로젝트는 델파이 7인데, 10.4로 마이그레이션 했다. 가장 큰 작업은 ansistring을 unicode로 전환하는 것이었다. 이로 인한 잠재적인 버그를 파악할 수 있는 도구가 있나?	O.H.	ReFind와 DelphiParser는 그런 작업을 도와주는 유틸리티이다. 다른 것들도 있다.
지금 델파이 7과 델파이 11.2 사이에서 작업하고 있다. 120개 애플리케이션/라이브러리들을 천천히 마이그레이션하고 있는 중이다. 써드-파티 컴포넌트들이 주로 문제가 된다.	M.S	맞다. 대체로, 써드-파티 컴포넌트 대부분은 전환할 수 있다. 하지만, 교체 해야만 했던 프로젝트 중에도 있다. 그 작업은 쉽지 않다. 하지만, 엄청 어렵지도 않다.
프로젝트 안에 있는 UDC를 파악할 수 있는 좋은 도구가 있나?	R.T.	MMX
Dr.Bob이 쓴 책인 "Clean Code"도 추천한다.	S.P.	맞다, 동의한다!
이런 작업은 정말 지속하기 어렵다. 그저 지루하다.	S.P.	사실이다. 좋은 전략이 도움된다. 하지만, 이 작업에 시간을 쓸 것인지를 먼저 결정해야 한다.
GoF 중 한명인, John Vlissides가 쓴 책인 "Pattern Hatching:Design Patterns Applied"도 있다.	K.H.	좋다.
때때로 엠바카데로는 예전 코드에 대한 호환성을 깨뜨려서 현재 유지하고 있는 프로젝트를 오래된 레거시 프로젝트로 만들어 버린다. 예를 들어, 최근에 TForm과 TDataModule에 있던 OldCreateOrder 프로퍼티가 제거되었다. 이 결정으로 인해 우리 회사의 델파이 개발자들은 레거시 개발자가 되어버렸다. 새 개발은 델파이로 진행되지 않을 것이다. - 경영진은 미래 언젠가 이런 문제가 또 생기기를 원하지 않는다.	P.K.	그 프로퍼티가 변경되어서 어려움을 겪었다니 유감이다. 하위 호환성 유지 측면에서 델파이는 내가 써본 어느 도구나 언어들보다 훨씬 더 뛰어나다. 때때로 주요 변경있기도 하다. 경영진에서 그렇게 결정했다면 충분한 정보가 없어서 그랬을 것이다.
때때로 고용주로서 직원들에게 이런 프로젝트를 향상하기 위해 시간과 노력을 들이라고 지시하기가 어렵다. 오래된 프로젝트들은 종종 새 프로젝트가 대체하기 전까지 생명 연장에만 의존하고 있다 😕	S.P.	정밀한 비용 분석을 통해서 교체보다 업그레이드가 훨씬 더 저렴하다느 것을 보여주어야 한다. 프로젝트를 새로 하는 비용은 거의 언제나 예상보다 실제 비용이 더 크다.
동의한다, 오래된 애플리케이션을 마이그레이션할 때, 주요 이슈는 그 안에 들어있는 컴포넌트들이다. 예를 들면 2010 버전 특별판에는 LMD가 들어있었는데, 이제는 없다. 이제는 구입하거나 다른 것으로 교체해야 한다. Quick Report도 그렇다. 델파이에서 오랫동안 제공해왔는데, 이제는 사실 상 죽었다. 최근 5년 동안 그다지 개발되지 않고 있다. 따라서 이것도 교체해야 한다. 정말 시간 낭비이고 경영진은 이런 작업에 빠지는 것을 정말로 원하지 않는다. 하기 쉬운 일이 아니지만, 그렇게 되어야 한다는 것을 우리는 안다.	D.D.	Quick Report에 연락해보면, 여전히 업데이트되고 있다는 것을 알 수 있다. 하지만, 웹사이트는 업데이트하지 않고 있다. 써드-파티 컴포넌트의 소스 코드를 가지고 있는 경우에는 앞으로 갈 수 있다.
나는 파일 안에서 찾기/바꾸기를 할 때 노트패드++를 주로 사용한다.	S.P.	멋진 에디터이다. 나는 울트라에디트(UltraEdit)로 그런 작업을 많이 한다.
우리는 GExperts를 제거해야 했다. 우리는 델파이 10.4에서 그것이 IDE에 문제를 일으킨다고 믿었기 때문이다. 다른 사람 중에 같은 경험을 한 사람이 있나?	R.T.	그런 문제를 들어본 적은 없다. 아마 그 이슈를 픽스한 업데이트가 있을 수도 있다.
정말 그렇다. 하지만, 경영진 안에서는 영원히 희망이 싹튼다. 새롭고 빛나는 것들이 종종 이기는 것 같다.	S.P.	경영진에게 $$$와 시간을 설명하라. 경영진이 언제나 주의를 기울이는 유일한 언어이다.
오늘 소개한 유틸리티들이 서로 잘 작동하나?	K.H.	함께 있어도 잘 작동한다. 하지만, 각 유틸리티 안에서 사용하지 않는 기능을 끄고, 자신에게 맞추어 쓰고 싶을 것이다. 그렇게 할 수 있다.
울트라에디트(UltraEdit)는 훌륭하다. 하지만 좀 비싸다.	S.P.	무료가 아니다. 하지만, 과도하게 비싼 가격은 아니라고 생각된다. 사용하고 싶은 기능과 그것이 어느 정도 가치를 주는지에 따라 다를 것이다.
GExperts 사이트는 Malwarebytes Browser Guard가 차단한다.	P.W.	99%는 사실이 아닌데도 양성으로 나온다. 하지만 언제나 조심하는 것이 좋다.
몇몇 경우에 - 기존 코드를 깨뜨리는 경우 -제품에 대한 신뢰 역시 깨진다.	P.K.	소프트웨어 개발 세상에 온 것을 환영한다. 나는 많은 다른 언어와 도구를 사용해왔다. 그 어느 것도 완벽하지 않다. 하지만, 솔직히 이런 쪽에서 델파이는 정말 최고라는 점을 알게 되었다.
나는 CnPack과 GExperts를 처음 설치하고 나면, 사용하지 않는 기능을 끄는 것부터 한다.	S.P.	바로 그것이다.
GExperts는 내가 본 것 중에서 다음 찾기 또는 이전 찾기에서 최고의 단축키를 가지고 있다 (Alt+아래 방향키, Alt+위 방향키).	K.H.	나도 열렬한 팬이다.
...종종 나는 써드-파티 델파이 페이지에 접근하려고 할 때 이런 일이 생긴다.	P.W.
GExperts에서 우리는 원하는 단축키를 선택할 수 있다.	K.H.	그렇다.
이제 그만 나가야한다. 훌륭한 통찰력을 제시해주어서 고맙다.	S.P.	다시보기가 제공될 것이다. 또는 책을 읽어볼 수도 있을 것이다.
약 15년 전에 나는 표준 윈도우 실행 파일을 만드는 델파이 5 프로젝트를 ASP.NET으로 다시 개발했다. 그때 비즈니스 로직을 델파이에서 C#으로 전환하는 것이 꽤 쉽다는 것을 알게되었다 (엔더스 헤이즐버그에게 감사를!). 델파이를 고수하는 것보다 다른 플랫폼으로 다시 작성하는 것이 더 낫다는 경험 규칙이 있나? 내가 델파이 5로 작성한 오픈-소스 도구가 하나 더 있는데 사람들이 아직 사용하고 있다. 이것을 델파이 커뮤니티 에디션으로 옮겨야 할 지 아니면 다른 플랫폼 으로 다시 개발해야 하는 지 (아니면 델파이 5로 그대로 둘지)를 논의하고 있다.	W.R
나는 델파이 10.2에 있는 코드 포맷터를 사용하여 델파이 7로 작성된 코드 코드에 서식을 반영하는 것에 익숙하다. 이런 방식이 레거시 프로젝트에서 좋은 방식이라고 볼 수 있나?	H.S.	매우 좋은 아이디어라고 생각한다. 닉 하지스(Nick Hodges)도 그 방식을 권한 것으로 알고 있다. 코드 서식을 일관성있게 유지하는 것은 정말 도움이 된다.
방대한 다시 쓰는 작업은 언제가 시간을 축낸다.	K.H.	그렇다
슬프게도, Quick Report 개발자는 1년 전에 세상을 떠났다. 코로나 바이러스 때문에.	O.A.	그렇다. 지금은 새 개발자가 담당하고 있다. 그들과 이메일을 교환한 적이 있다.
내가 알기로는 Quick Report 주 개발자는 사실 세상을 떠났다. 그래서 새 버전이 쉽게 나오지 않고 있고 작업이 많이 되지 못하고 있다.	A.D.	그렇다. 매우 슬프다. 새 개발자들이 맡아서 작업하고 있다.
알고 있는 것이 좋다.	A.D.
컴포넌트는 축복이자 저주이다. 컴포넌트를 사용하면 직접 만드는 것보다 당장 눈앞의 비용을 절감할 수 있지만, 그후로 그들과 오랫동안 함께 해야 한다.	W.B	사실이다.
두번 측정하고 한번에 잘라라. 목수의 격언.	K.H.	그렇다.
리팩토링을 하려면 너무 많은 문제가 있다는게 가능한가? 25년이 넘은 프로젝트가 있는데 UI, 데이터, 로직이 엉켜있다. 이미 사장된 컴포넌트를 쓰고 있고 사용하지 않는 기능들도 들어 있다. 나는 새로 만들고 싶은 마음이다. 어떻게 결정하면 되나?	D.F.	가능하다. 규모와 투자에 따라 달라진다. 현실에서는, 새로 작성하느라 새로 생기는 버그를 수정하려면 처음에 투입된 시간 만큼을 다시 투입하게 된다.
때때로 코드가 너무 나빠서 다시 작성해야 하는 부분이 너무 많은 코드들이 있다. 내 경험을 말하자면, 우리가 맡았던 어떤 프로젝트는 고객이 회계사에게 기존 시스템을 작성하도록 했던 것인데, 18개월이 지나도록 우리는 여전히 그 엉망진창을 수정하려고 시도하고 있었다... 나는 결국 그만두었다. 그 슬픔 그리고 절대로 끝내지 못할 일 같다고 신음하는 고객으로 인해 지쳤기 때문이다.	A.D.	그 프로그램이 작동하고 있다면, 리팩토링을 하는데 오랜 시간이 걸린다고 하더라도, 리팩토링을 하면서 지속적으로 업데이트와 픽스를 제공할 수 있다. 그 반면에, 다시 작성하게 되면 아무 것도 없이 새로 시작해야 하거나 또는 코드베이스 두 개를 장기간 동안 유지해야 한다.
남아프리카 공화국에서, 이제 곧 떠나야 한다. 국영 전력업체인 ESCOM에서 필요한 전력을 공급할 수 없어서 일정 시간 동안 전국에 걸쳐 부하를 떨어 뜨려야 한다.	D.D.	유감이다. 다시 보기가 제공될 것이다.
25년 되었고, 다양한 기술 수준을 가진 개발자 17명이 참여했다. 개발자 2명이 남았는데 그 중 1 명은 은퇴가 몇 년 남지 않았다. 코드는 약 700,000 줄이다.	D.F.	리팩토링하라. 엄청한 투자가 들어있다. 그것을 버리고 다시 만들고 싶지는 않을 것이다.
터보 델파이 시절에는 컴포넌트를 사용하지 않으려고 최선을 다하고 있다. 컴포넌트들을 쓰기 시작하면 너무 복잡해진다. JVCL도, ASyncPro도 더 이상 필요하지 않다... 필요한 섹션이 있으면 우리가 다시 작성한다.	S.B.	써드-파티 컴포넌트를 사용하는 것에 대해서는 찬성과 반대가 있다. 애플리케이션 안에서 컴포넌트를 과도하게 사용해서는 안된다. 하지만, 몇 가지 중요한 것들을 사용하는 것은 그 가치가 크다.
사실, 경영진은 소프트웨어를 이렇게 보지 않는다. 비록 소프트웨어가 지금도 작동하고 있고, 내 경우에는 22년 동안, 시장에서 사용되고 있고, 돈을 벌어 주고 있어도 경영진은 완전히 마이그레이션하는 작업에 돈을 쓰고 싶어하지 않는다.	D.D.	그 마음을 이해한다. 그런 것이 반복적인 리팩토링을 통해 얻게되는 장점이다.
델파이 현대화 전문가로서, 마이그레이션 프로젝트를 성공으로 이끄는 가장 중요한 이슈는 프로젝트를 할 알맞은 개발자를 찾는 것이다.	O.A.	정말 그렇다.
고맙다. 그만 가봐야 한다 - 나는 경험이 상당히 많은데, 내 경우에는 두 가지 유형의 문제를 만났다. 이후 버전 안에 들어 있는 작업을 다루기 위해 작성된 사용자 정의 루틴들이 아주 많다 (교체 시기가 확실하지 않다). 그리고 더 나쁜 문제는 개발자 중에는 코드 몇 줄을 줄이기 위해 '영리한(clever)' 코드를 작성하려고 하는데 읽기/이해하기가 거의 불가능하다...어쨌든 고맙다.	C.R.	리팩토링을 통해서 점진적으로 차근차근 접근해 갈 수 있다. 이런 "영리한(clever) 코드"는 당신이 리팩토링을 통해서 이런 작은 부분을 다시 작성할 때까지만 살아남을 수 있다.
[괜찮다. 당신이 지금 이것을 다루고 있다고 들었다. :-)]	C.R.
매우 도움이 되었다.	D.F.	기쁘다.
(어떤 경우에) 델파이 새 버전에서 리팩토링/재작성을 시작하지 않고, 오래된 델파이 버전에서 마이그레이션을 "준비"하는 것이 유리할 수도 있나?	H.W	그렇다. 좋은 전략이다. 점진적으로 차근차근 접근하기.
"주석달기, 주석달기, 주석달기" 라고 말해야겠다.	N.B.	:-0
나는 TryStrToInt를 좋아한다. 그 이유는 반환값인 Boolean을 사용해서 분기할 수 있기 때문이다.	K.H.	그렇다.
예전에 "not" 키워드를 사용했는데 역효과가 있었다. 정확한 문맥은 기억나지 않지만, 괄호를 정확하게 사용하지 않았더니 그랬다. 그래서 "not" 보다는 "= false" 가 더 정확한 결과를 내는 것을 알게 되었다.	R.T.	그렇다. 조심하라.
내 기억에 적어도 20년 전부터 TryStrToInt를 사용하고 있다.	K.H.	좋다.
지금까지 최고의 컴포넌트? Virtual Tree View	N.B.	나도 매우 좋아하는 것이다.
이제 나가봐야 한다. 정보와 질문들 고맙다 매우 도움이 되었다.	m.k.	좋다.
유니코드(unicode) 이전 코드, 예를 들어, 델파이 5에서, 유니코드 변수를 사용하는 현재 버전으로 전환하는 것과 관련하여 알려주고 싶은 통찰력이 있는가?	S.M	책에 몇가기 정보가 들어있다. 그리고 많은 자료와 도움말이 여기에도 있다. https://www.embarcadero.com/rad-in-action/migration-upgrade-center
내부에서 개발한 컴포넌트들은 유지보수 하기가 고통스럽다. 팀 안에서는 특히 그렇다. 리포지토리(repo)에서 그냥 당겨오는(pull) 것이 탐원들이 매번 컴포넌트 업데이트를 새로 설치하는 것보다 더 쉽다.	C.M	그렇다! 내부에서 개발한 컴포넌트들이 몇 개 쯤은 있을 것이다. 하지만, 좋은 전략을 가지고 있고 내부 컴포넌트와 써드-파티 컴포넌트 사이에 균형을 유지하는 것이 중요하다.
무료 써드-파티 컴포넌트 라이브러리 또는 오픈 소스 코드는 오랜 시간이 지난 뒤에 유지보수 비용이 발생한다. 이 점이 상업용과 다르다.	O.A.	때때로 사실이다. 하지만, 유지되고 있는 것들도 있다. 나는 사용하고 있는 오픈 소스 프로젝트를 후원할 것을 추천한다.
수많은 힌트와 경고가 나오는 레거시 프로젝트를 컴파일 하는 것보다 더 혼란스러운 것은 없다. 나는 언제나 그것들을 가능한 빨리 없애려고 노력한다. 주로 미래의 나 자신을 위해서.	W.B	그렇다! 내가 누군가의 프로젝트를 돕기 위해 들어가면 가장 먼저 제안하는 것이다.
매우 고맙다, 좋은 웨비나였다!!	W.R	고맙다!
BDE (Borland Database Engine)를 사용하는 코드를 뭔가 현대적인 것으로 마이그레이션하는 도구가 있나?	D.L.	ReFind (델파이에 들어있다)와 DelphiParser (써드-파티)가 그것을 도와준다. 그 외에 다른 도구들도 있다. 여기에 관련 자료들이 있다. https://www.embarcadero.com/rad-in-action/migration-upgrade-center
나는 때때로 implementation 코드 구역은 기능 별로 나열하고, 선언(interface) 코드 구역은 알파벳 순서로 나열한다.	K.H.	멋지다.
쓰레드를 사용하는 앱을 다루는가?	N.B.	아니다. 하지만, Dalija가 그 주제를 정말 잘 다루고 있다. https://dalija.prasnikar.info/
나는 내 클래스 선언 부에서 내 함수와 프로시저를 기능과 알파벳 순서로 나열하고 각 "함수" 위에 주석을 달아서 구분한다. 이렇게 하면 함수를 빠르고 쉽게 찾을 수 있다.	A.D.	그렇다. 좋아하는 방식이면 무엇이든 좋은 것이다. 일관성이 핵심 열쇠이다.
델파이 개발자 부족을 어떻게 해소하려고 하나? 심지어 최고의 델파이 개발자들 조차 늙어가고 있다. 그리고 새 델파이 개발자는 없지 않은가?	O.A.	새 델파이 개발자들이 있다. 단지 개발자를 뽑아서 델파이에서 속도를 낼 수 있도록 하는 것이 중요하다.
OmniThreadLibrary를 가지고 병렬 프로그래밍하기는 Promozh의 책과 프레임워크에 있다.	T.E.	그렇다!
고맙다! 훌륭한 웨비나였다.	R.T.
PDF 책을 방금 구입했다.	T.P.