|
철저공략 델파이 7에 나온 내용을 발췌했습니다.
델파이: 왜 그리고 뭘?
"왜 델파이가 좋은 거야?",
"왜 꼭 델파이를 써야 하지?" 라는 질문을 자주 하게 된다. 몇 년간 이 물음의 답변을 찾아 헤매면서 짧은 답변과 긴 답변을 찾아냈다. 짧은 답변은 바로 "생산성"이다. 델파이는 지금가지 우리가 찾아낸 윈도우즈 애플리케이션 개발 도구 중에서 가장 생산적인 도구이다. 당연히 직장 상사나 고객의 관점에서는 이 답이 충분하지 않을것이다. 그렇다면 여기 긴 답변을 들어보아야 한다. 긴 답은 델파이의 생산성을 극대화해 주는 제품의 질(Qualities)과 관련해 표현된다. 소프트웨어 개발 도구의 생산성은 5개의 중요한 속성을 갖게 하는 5각형으로 표현된다. 소프트웨어 개발 도구의 생산성은 5개의 중요한 속성을 갖게 하는 5각형으로 표현할 수 있다.
비주얼 개발 도구 환경의 질
효율적으로 컴파일된 코드 대 컴파일러의 속도
프로그래밍 언어의 힘과 복잡함
데이터베이스 구조의 유연함과 복잡함
프레임워크에 의한 디자인과 사용 패턴(pattern)
비록 배포 문제, 먼서, 써드파티 지원 등 다른 많은 요인들이 얽혀 있지만 델파이 초보자들을 위해 우리가 왜 델파이를 선택하는지 조금 더 쉽고 확실하게 설명할 수 잇는 방법이 될 것이다. 어떠한 카테고리(Category)들은 조금 주관적이지만, 바로 그것이 중요한 점이다.
"바로 여러분은 특정한 도구를 사용해서 얼마나 생산적으로 작업을 하는가?"
비주얼 개발 환경의 질
비주얼 개발 환경은 일반적으로 세 가지 구성요소로 이야기 할 수 있다. 에디터, 디버거, 폼 디자이너가 바로 그것이다.
요즘 나오고 있는 RAD(빠른 애플리케이션 개발) 도구들은 애플리케이션 개발을 할 때 대부분 이 세가지를 이미 조화
시켜놓고 있다. 여러분들이 폼 디자이너로 작업할 때, 델파이는 뒤에서 여러분들이 폼 위에 떨어뜨린 컴포넌트에 관련된
코드를 생성한다. 여러분은 에디터에서 프로그램 동작을 정의하기 위한 추가 코드를 덧붙일 수 있고, 또 이 에디터에서
중단점(BreakPoint), Watch 기능 들을 설정해 애플리케이션을 디버깅 할 수 있다.
델파이의 에디터는 일반적으로 다른 도구들가 동일하다. 프로그래머의 타이핑 횟수를 줄여주는 코드 인사이트(Code Insight)
기술은 아마 최고일 것이다. 그것은 비주얼 베이직에서처럼 타입 라이브러리 정보에 기초하는 것이 아니라 컴파일러 정보에
기초하고 있으므로 보다 다양한 상황에서 도움이 도리 것이다. 비록 델파이 에디터가 몇 가지 훌륭한 환경 설정옵션을
제공하긴 하지만, 필자는 비주얼 스튜디오 편집기가 보다 다양한 설정을 제공하는 것으로 평가하고 있다.
최근의 델파이 디버거는 비주얼 스튜디오에서 볼 수 있던 놀라운 기능들을 제공하고 있다. 리모트 디버깅(Remote Debugging),
프로세스 어태치먼트(Process Attachment), DLL과 패키지 디버깅, 자동 로컬 Watch 및 CPU 윈도우 같은 것들이
바로 그것이다. 또한 델파이는 멋진 통합 개발환경(IDE)를 제공하는데, 디버깅하는 동안 여러분들이 원하는 곳 어디든
놓을 수 있는 도킹 기능과 그 상태를 데스크탑 설정으로 기억시켜주는 기능 등이 있다.
비주얼 베이직이나 자바 개발 환경 같은 인터프리터 개발 환경에서는 일반적으로 디버깅중에 애플리케이션의 행동을 수정
할 수 있도록 코드를 변경 가능하게 해 주는 기능을 포함하고 있다. 아쉽게 도 이런 종류의 기능은 네이티브 코드(Native Code)컴파
일에서는 구현하기가 굉장히 어렵기 때문에, 델파이에서는 지원되지 않고 있다.
델파이나 비주얼 베이직, C++빌더와 파워 빌더 같은 툴에는 RAD 툴의 독특한 특성자 특징인, "폼 디자이너"라는 것이있다.
Visual C++나 볼랜드 C++같은 조금 고전적인 개발 환경에서는 대화 상자 에디터를 제공하는데, 익럿은 "폼 디자이너"
에서만큼 개발 워크플로우(workflow) 에 잘 어울리는 것은 아니다[그림 1.1]을 보면 폼 디자이너 부재가 애플리케이션
개발의 생성성에 얼마나 큰 영향을 주는지 알 수 있다.
오랫동안 델파이와 비주얼 베이직은 서로 우월한 폼 디자이너를 가지고 있다고 줄다리기를 하고 있다. 델파이의 폼 디자이너를
여타 다른 것들과 구분지어주는 특징은, 델파이야 말로 진정한 객체 지향의 골격위에 세워져 있다는 것이다. 그 뜻은 바로
조상 클래스에서 주는 변화는 그 밑의 베이스 클래스에 같이 영향을 준다는 것인데, 이 특징에서 제일 중요한 영향을
주는 것은 바로 비주얼 폼의 상속읻.(visual form inheritance, VFI). VFI는 프로젝트 갤러리에 있는 다른 폼들로
부터 동적으로 상속을 받을 수 있게 해 준다. 상속받을 베이스 폼에 생긴 벼화는 바로 자손 폼들에 영향을 준다.
컴파일러의 속도와 컴파일된 코드의 효율성
빠른 속도의 컴파일은 소프트웨어 개발을 가속화시킬 수 있게 해었다. 앞서 말한 바와 같이 빈번한 "소스 코드의 수정
-> 컴파일 -> 테스팅 -> 수정 -> 재 컴파일 -> 테스팅" 의 반족에 대해 델파이는 매우 능률적인 개발 환경을 제공한다.
컴파일 속도가 더 느려졌다면 개발자는 개발 기간동안 제한된 코드만을 만들 수 밖에 없을 것이다.
런타임(Run-time) 때 능률 향상의 이점은 언제나 명확하다. 더 빠른 실행 속도와 더 적은 바이너리 코드는 언제나
좋은 것일 수 밖에 없다. 아마도 델파이의 기초가 된 "오브젝트 파스칼 컴파일러"의 가장 유명한 특징은 빠른 속도일
것이다. 사실 이것은 윈도우즈에서 가장 빠른 하이레벨 네이티브(Native) 코드 컴파일러일 것이다.
원래의 전형적인 C++에 의한 개발에서 보여지는 엄청나게 느린 컴파일 속도는 몇 년동안 링크와 메모리 정책으로 인해
많은 발전이 있었다. 특히 비주얼 C++와 C++빌덩에서 그러한데, 여전히 C++컴파일러는 델파이 컴파일러에 비해
많이 느리다
컴파일 속도가 의미하는 것은 런타임 효율과 맞바꿀 수 있다는 것일까? 답은 물론 '아니오'이다. 델파이는 C++ 빌더와
공일한 컴파일러 후미(back end)를 사용하기 때문에, 생성된 코드의 효율성은 매우 훌륭한 C++ 컴파일러의 그것과
동일하다. 가장 최근의 신뢰성 있는 벤치마크에서 지부얼 C++는 몇 가지 매우 훌륭환 최적화에 힘입어 여러 경우에서
속도와 크기 효율성에서 1등을 차지했다. 비록 일반적인 프로그램 개발에선 이런 작은 잠점들은 눈에 띄지 않지만,
수치 계산이 주가 되는 코드를 작성할 때 차이가 있을 수 있다.
비주얼 베이직은 컴파일러 기술에 있어 어느 정도 독특한 면이 있다. 인터프리터 방식으로 동작하는 VB를 이용해 개발
하게 되면 컴파일러에 비해 꽤 민감하게 반응한다. 배포할 준비가 되었을 때, VB 컴파일러를 이용하여 EXE 파일을
만들 수 있다. 이 컴파일러는 꽤 느리고 속도 효율은 델파이나 C++ 툴에 비하여 뒤진다. 이 글을 쓰고 있는 즈음에
마이크로소프트의 다음 버전인 비주얼 베이직 닷넷 베타버전은 이 부분을 개선할 것이라고 한다.
자바는 또 하나의 흥미로운 케이스이다. JBuilder나 비주얼 J++와 같은 자바 기반의 툴들은 델파이에 비견할 만한
컴파일 속도를 자랑한다. 실행 속도으 효율에도 불구하고 소수의 사람들은 자바가 인터프리터 언어라는 이유로 기피하는
경우도 있다. 비록 자바가 끊임없는 개선을 거듭하고 있지만 실행 속도만은 실제로 C++ 비하여 뒤떨어진다.
프로그래밍 언어의 능력 대 복잡성
능력(Power)과 복잡성은 개인의 주관에 의해 좌우된다. 그리고 이 특별한 주제는 온라인상의 불꽃 튀는 논쟁의 기수에
섰던 주제이기도 하다. 누군가에게 쉬운 것이 다른사람에게는 어려울 수도 있고, 또 다른 어떤 사람에겐 우아한 것으로
생각 될 수도 있다. 따라서 다음 내용은 독자의 경험과 개인적 취향에 의거한다.
어셈블리는 궁극적으로 가장 강력한 언어이다. 극소수의 사람들만이 그 언어를 다룰 수 있다. 그러나 어셈블리로는 가장 단순한 윈도우즈 프로그램을 제작하는 것도 매우 힘들고, 에러를 발생시킬 소지가 큰 모험이 될 것이다. 비단 그것 뿐만 아니라 팀 환경에서 어셈블리 코드를 기반을 어느 기간 동안 유지하는 것은 거의 불가능에 가깝다. 그 코드는 한 개발자에게서 다른 개발자로 옮겨가고 디자인에 관한 아이디어와 목적이 추가되면 될수록 코드가 컴퓨터용 언어가 아니라 산스크리트(Sanskrit)처럼 보이기 시작할 때까지 더욱 더 미궁 속으로 빠지게 된다. 그러므로 어셈블리가 비록 강력하긴 하지만 모든 애플리케이션을 개발하기에는 너무 복잡하기 때문에, 어셈블리에 매우 낮은 점수를 줄 수 밖에 없다.
C++는 상당히 강력한 또 다른 언이이다. 프리프로세서(pre-processor) 매크로, 템플릿, 연산자 오버로딩과 같은 정말로 강력한 기능의 도움으로 C++ 내에서 자기 자신만의 언어를 디자인 할 수 있다. 만일 이러한 광대한 기능들을 현명하게 사용한닫면, 매우 깔끔하고 유지보수가 용이한 코드를 개발할 수 있을 것이다. 그러나 문제는, 많은 개발자들이 이러한 기능들을 남용한 덕에 정말로 끔찍한 코드를 만들어 내곤한다는 것이다. 사실으 나쁜 코드를 작성하는 것이 좋은 코드를 작성하는 것보다 쉽다. 이것은 언어 자체가 좋은 디자인을 만들어 내는게 아니라 좋은 디자인을 만들어 내는 것은 개발자의 몫이기 때문이다.
복잡함과 강력함 사이의 매우 훌륭한 균형을 이루었다는 점에서 오브젝트 파스칼(Object Pascal)과 자바를 꽤 비슷하다고 느끼곤 한다. 이 두 언어는 개발자에게 논리적인 디자인을 강요하기 위하여 사용 가능한 기능들을 제한하는 방식을 채택하고 있다. 예를 들면, 두 언어 모두 클래스가 다중 인터페이스를 구현할 수 있도록 하기 위해 객체 지향이긴 하지만 쉽게 남용될 수 있는 다중 상속 개념을 사용하는 것은 피하고 있다. 양쪽 다 연산자 오버로딩이라는 위험한 기능 외의 재치는 부족하다. 또한 두 언어 모두 링커에 의해 다뤄지는 세부항목보다는 언어 차원에서 최적화된 소스 파일을 만들어 낸다. 덧붙이자면, 두 언어는 예외 처리, RunTime Type Information(RTTI), 순수한 메모리 관리 문자열과 같은 효율적인 기능이 추가된 강력한 특징상의 이점을 가지고 있다. 그리고 이 두 언어는 어떤 큰 단체에 의해 만들어진 것이 아니고 개인 혹은 작은 단체에 의해 만들어졌다.
비주얼 베이직은 초보 프로그래머들이 쉽게채택할 수 있을 만큼 충분히 쉽게 디자인된 언어로서 그 생을 시작했다(그래서 이름이 비주얼 베이직이다). 그러나 해를 거듭하면서 단점을 보완하기 위해 언어적으로 여러 기능들이 추가되었다. 비주얼 베이직은 점점 더 복잡해져 왔고, 개발자들에게는 세부적인 내부를 공개하지 않을 목적 때문에 비주얼 베이직은 여전히 복잡한 프로젝트를 위해서는 우회해야만 하도록 장벽을 만들어 두었다. 마이크로소프트의 차기 버전인 비주얼 베이직 닷넷은 이전 버전들과의 효환 비용에도 불구하고, 이 영역에 중대한 변화를 가져오고 있다.
데이터베이스 아키텍처의 유연성과 확장성
델파이는 볼랜드의 데이터베이스 규모가 작은 것을 극복하기 위해 어떤 툴보다 더 탄력적인 데이터베이스 구조를 유지하고 있다. 막 설치한 후의 dbExpree는 매우 효율적이긴 하지만(고급 기능을 위한 비용에도 불구하고), 드라이버의 선택은 다소 제한적이다. 비록BDE(볼랜드 데이터베이스 엔진)가 볼랜드에 의해 단계적으로 사라지고는 있지만, BDE는 여전히 넓은 범위의 데이터 소스에 대해 대부분의 프로그램에서 상대적으로 잘 동작한다. 부가적으로, 네이티브(Native) ADO 컴포넌트는 ADO 또는 ODBC를 통하여 서로 통신하기 위한 효율적인 방법을 제공한다. 만일 인터베이스(InterBase) 환경이라면, IBExpress네이티브 인터베이스 컴포넌트들은 그 데이터베이스 서버와 서로 통신할 수 있는 가장 멋진 수단을 제공한다. 만약 이런 연결들 중 어느것도 사용자가 원하는 데이터 접근을 허용하지 안흔다면, 드파티 데이터셋 솔루션을 구입해야 한다. 더욱이, DataCLX는 논리적 또는 물리적으로 모든 데이터 접근 솔류션에 초점을 맞추는 경향이 있다(사실 ADO같은 써드파티 솔루션이 더욱 빠른 것들이 있다).
프레임워크에 의해 통제되는 디자인과 사용 패턴
이 부분은 다른 툴들이 놓치고 있는 소프트웨어 디자인의 거의 독보적인 것이다. 다른 모든 것들이 비슷해지고, VCL이 델파이에서 가장 중요한 부분으로 되어 있다. 디자인 시에 컴포넌트를 잘 다루는 능력, 컴포넌트의 디자인, 객체 지향(object-oriented) 기술을 사용한 다른 컴포넌트로부터 상속, 이것들은 델파이의 생산선에서 가장 중요한 부분이다. VCL 컴포넌ㄴ트를 제작할 때에는 여러가지 경우에 맞는 객체 지향 메소드 로직의 구상에 많은 시간을 소비하게 된다. 비교해 보면 다른 컴포넌트 기반의 프레임워크는 종종 너무 유연성이 없거나, 너무 복잡하게 구성되어 있다.
예를 들어 ActivX 컨트롤은 VCL컨트롤의 디자인타임 이점과 유사한 많은 편의성들을 제공한다. 하지만 조근 다른 수행을 하는 새로운 클래스를 생성할 때에는 ActiveX 컴트롤로부터 상속받을 방법이 없다. OWL, MFC 같은 전통적인 클래스 프레임워크는 일반적으로 생상성 향상을 목적으로 제작자가 엄청난 양의 내부 프레임워크 지식을 가지고 있을 것을 요구한다. 그리고 이것들은 RAD 툴 같은 디자인타임 지원이 부족하다는 제한이 있다. 마이크로소프트의 닷넷(.net) 공통 라이ㅇ브러리는 마침내 마이크로소프트 컴포넌트 기반 개발자 측면으로 볼 때 옳은 방향으로 이끌어 가고 있다. 그리고 그것은 C#, 비주얼 c++와 비주얼 베이직 같은 여러가지 툴들에서도 같이 작업할 수 있게 했다. | 