2011-08-15 3 views
11

입니다. 이것은 here을 시작한 토론의 연속입니다. 필자는이 분야에서 경험하지 못했던 델파이 소스 코드를 모듈화하는 가장 좋은 방법을 찾고 싶습니다. 나는 너의 모든 제안에 감사 할 것이다.델파이의 모듈 프로그래밍에 대한 최선의 접근법은

내가 이미 작성한 것을 게시 해주십시오. there.

제가 일하는 회사에서 개발 한 소프트웨어는 100 개 이상의 모듈로 구성되어 있습니다 (대부분 다른 장치 용 드라이버와 비슷합니다). 대부분의 경우 동일한 코드를 공유합니다. 대부분의 경우 클래스입니다. 문제는 이러한 클래스가 항상 별도의 독립 실행 형 PAS 단위로 배치되지 않는다는 것입니다. 나는 공유 된 코드가 종종 모듈에 특정한 코드를 포함하는 유닛에 들어간다는 것을 의미한다. 즉, 공유 클래스에서 버그를 수정하면 정의 된 PAS 장치를 모든 소프트웨어 모듈에 복사하고 다시 컴파일하는 것으로는 충분하지 않습니다. 안타깝게도 고정 된 코드 조각을 복사하여 각 모듈에 하나씩 적절한 단위와 클래스로 붙여 넣어야합니다. 이것은 많은 시간이 걸리고 이것은 가까운 장래에 정확한 접근 방식을 선택하여 제거하고 싶습니다. 제발 도와주세요.

EXPL과 함께 배포 된 BPL을 사용하면 좋은 해결책이 될 것이라고 생각했지만 이전 논의에서 언급 한 것처럼 일부 단점도 있습니다. 최악의 문제는 각 EXE에 여러 개의 BPL이 필요한 경우 기술 지원 담당자가 어떤 EXE에 BPL이 필요한지 파악하고 최종 사용자에게 적절한 파일을 제공해야한다는 것입니다. 소프트웨어 업데이터가 없으면 기술자와 최종 사용자 모두에게 많은 도움이 될 것입니다. 그들은 분명히 길을 잃고 화를 낼 것입니다 : - /.

또한 호환성 문제가 발생할 수 있습니다. 하나의 BPL이 여러 EXE에서 공유되는 경우 해당 BPL의 수정으로 인해 하나의 EXE에는 좋고 다른 일부에는 적합하지 않을 수 있습니다.

많은 프로젝트에서 버그를 빨리 수정하려면 어떻게해야합니까? 나는 다음 접근법 중 하나를 생각한다. 더 좋은 아이디어가 있다면 알려주세요. 그 중 하나의 버그 수정이있을 때 별도의 독립 PAS 단위로

  • 넣어 공유 코드, 그래서, (이전 파일을 덮어 쓰기) 모든 프로젝트에 복사에 충분하다 그들 모두를 다시 컴파일. 즉, 각 단위가 사용되는 프로젝트의 수만큼 복사됩니다.

이 솔루션은 거의 수정되지 않은 코드에 관한 한 괜찮은 것으로 보입니다. 그러나 우리는 또한 일반적으로 수정을 거치는 일반적인 사용 기능과 절차가있는 단위를 가지고 있습니다. 누군가이 파일에 새로운 기능을 추가 할 때마다 동일한 프로 시저 (너무 많은 프로젝트를 복사하고 다시 컴파일하는)를 수행하는 것은 불가능합니다.

  • 모든 공유 코드에 대해 BPL을 만들지 만 EXE가 독립형이되도록 EXE에 연결하십시오.

나를 위해 그것은 지금 가장 좋은 해결책으로 보이지만 몇 가지 단점이 있습니다. BPL에서 버그를 수정하면 각 프로그래머는 컴퓨터에서 BPL을 업데이트해야합니다. 그들이 그것을 잊어 버렸다면? 그러나 사소한 문제라고 생각합니다. 우리가 변화에 대해 서로 알리는 일을 처리한다면 모든 것이 잘되어야합니다. 어떻게 생각해?

  • CodeInChaos에서 제안한 마지막 아이디어 (제대로 이해했는지는 알 수 없음). 프로젝트간에 PAS 파일 공유. 아마도 공유 코드를 별도의 폴더에 저장하고 모든 프로젝트에서 해당 코드를 검색해야 할 것입니다. 그리고 프로젝트를 수정해야 할 때마다 공유 파일 폴더와 함께 SVN에서 다운로드해야합니다.공유 코드가 변경 될 때마다 해당 코드를 사용하는 각 프로젝트를 다시 컴파일해야합니다.

좋은 해결책을 선택하십시오. 소프트웨어 개발에 대한 어리석은 접근 방식 때문에 버그 수정에 필요한 것보다 훨씬 많은 시간과 돈을 잃고 싶지 않습니다. 지금까지 아무도 그것에 신경 쓰지 않았고 얼마나 많은 문제가 발생했는지 상상할 수 있습니다.

대단히 감사합니다.

+1

같은 기능을 2 부 가지고 있지 않습니다. 이제까지. SVN은 당신이하고자하는 것을 성취하기가 어렵지만 SVN 외관이 필요하다고 생각합니다. 나는 당신이 더 나은 응답을 얻어야하는 프로그래머로 이동하기로 표결합니다. –

+1

@David Microsoft는 Office 제품의 소스 코드에서이 작업을 수행합니다. (Scott Berkun, "프로젝트 관리의 기술") 왜? 한 사본에 버그가있는 경우 다른 제품에는 영향을 미치지 않습니다. – mjn

+0

@mjn 나는 그것을 믿을 수 없다. 나는 당신이 이야기를 약간 비틀어서 다시 말하고 있다고 생각한다. –

답변

5

당신 말 :

  • 이 EXE 파일이 독립되어 있기 때문에, 모든 공유 코드 BPLs를 작성하지만, EXE 파일로 연결합니다.

BPL을 실행 파일에 연결할 수 없습니다. BPL에있는 별도의 단위로 연결하는 것뿐입니다. 그렇게하면 실제로 을 사용하지 않고을 사용하거나 심지어 을 사용하려면 BPL을 필요로합니다.

BPL은 공유 코드로 사용됩니다. 즉, 공유되는 코드를 하나 또는 여러 개의 BPL에 넣고 각 .exes, .dll 또는 기타 .bpl의 코드를 사용합니다. Bugfix (BPL의 공용 인터페이스를 변경하지 않는 경우)는 고정 된 BPL 하나만 재배포하면됩니다.

내가 말했듯이 DLL의 공용 인터페이스를 결정한 다음 변경하지 마십시오. 루틴, 유형 및 클래스를 추가 할 수 있지만 이미 사용중인 기존 클래스, 유형, 인터페이스, 상수, 전역 변수 등의 공용 인터페이스는 수정하면 안됩니다. 그렇게하면 BPL의 고정 버전을 쉽게 배포 할 수 있습니다.

그러나 BPL은 고도로 컴파일러 버전에 의존합니다. 컴파일러의 새 버전을 사용하는 경우 BPL도 다시 컴파일해야합니다. 그래서 컴파일러 버전에 따라 100, 110 등과 같은 BPL 접미사를 지정하는 것이 좋습니다. 컴파일러 버전 15.0으로 컴파일 된 실행 파일에는 접미어 150이있는 BPL을 사용하라는 메시지가 표시되고 버전 14.0으로 컴파일 된 실행 파일은 접미어 140이있는 BPL을 사용합니다. 그러면 서로 다른 버전의 BPL을 평화롭게 공존 할 수 있습니다. 접미사는 프로젝트 옵션에서 설정할 수 있습니다.

다른 버전을 어떻게 관리합니까? 내 ComponentInstaller BPL에 대한이 같은 구조의 디렉토리를 만듭니다 (이것은 당신이 메뉴의 구성 요소에서 델파이/C++ 빌더/RAD 스튜디오 XE IDE에서 볼 수있는 전문가입니다 -> 구성 요소를 설치) :

Projects 
    ComponentInstaller 
    Common 
    D2007 
    D2009 
    D2010 
    DXE 

Common 디렉토리에는 각 버전에서 공유하는 .pas 파일 및 리소스 (비트 맵 등)가 포함되어 있으며 각 Dxxxx 디렉토리에는 BPL의 특정 버전에 대한 .dpk, .dproj 등이 포함됩니다. 각 패키지는 Common 디렉토리의 파일을 사용합니다. 이것은 물론 여러 개의 BPL에 대해 동시에 수행 할 수 있습니다.

버전 시스템을 사용하면이 작업을 훨씬 쉽게 처리 할 수 ​​있습니다. BPL의 각 버전에 다른 접미사를 지정해야합니다.

실제로 독립 실행 형 실행 파일을 원한다면 BPL을 사용하지 않고 단순히 별도의 단위로 연결하면됩니다. "BPL로 컴파일"옵션이 이것을 제어합니다.

+0

경험을 공유해 주셔서 감사합니다. 다시 한 가지 질문을 드리겠습니다. 귀하의 예는 동일한 BPL의 여러 버전을 기반으로합니다. 각 BPL 버전은 .pas 파일과 동일한 디렉토리를 사용합니다. 그러나 공통 디렉토리에서 일부 유닛을 참조하는 완전히 다른 코드로 다른 BPL을 작성하겠습니다. 이제는 프로젝트에 첨부 된 파일을 직접 참조해야합니까? 아니면 프로젝트의 요구 사항 목록에서 참조하는 공통 BPL 중 하나만 사용해야합니까? 어떤 방법을 더 잘 고려하십니까? –

+4

단위는 동시에 * * 1 * 및 * 1 * BPL에만 있어야합니다. 그러한 유닛을 필요로하는 다른 BPL은이를 포함하는 BPL을 요구해야합니다. 어느 단위가 어디로 가야하는지 조금 더 생각하는 것이 합리적입니다. 실행 가능하고 어떤 단위가 필요한지를 그래프로 그릴 것입니다. 만족할 때까지 재 배열하고 결정하십시오. –

+0

좋아요, 이것은 내가 듣고 싶었던 것입니다. 고맙습니다. –

3

델파이 유닛, 라이브러리 및 실행 파일과 같은 아티팩트를 관리하려고한다는 관점에서 잘못된 위치를 검색합니다.Design patterns 구현을 기반으로 코드 리팩토링으로 돌아서 시작하는 것이 좋습니다.

예. 모든 공통 기능을 하나의 Singleton 클래스에 배치 할 수 있으며 공통 클래스의 인스턴스는 Abstract Factory으로 구성 할 수 있으며 클래스는 직접적인 사용이 아닌 기본 Delphi 구현 인터페이스를 통해 상호 작용할 수 있습니다. 프로젝트의 모든 공통 부분에 대해 Facade을 구현하도록 선택할 수도 있습니다.

물론 구체적인 패턴 및 구현 세부 정보는 프로젝트에 따라 다르며 경우에 따라 적합한 것을 결정할 수 있습니다. 나는이 정맥에서 계획을 세우고 나면보다 자연스러운 코드 구성 방법과 문제 해결 방법을 찾을 수 있다고 생각한다.

몇 가지 다른 것들 : 물론

  1. , 당신은 @CodeInChaos 제안에 따라 대신 수동으로 각 프로젝트에 복사의 모든 프로젝트 사이에 소스 파일의 복사본 하나를 공유해야합니다. 모든 개발자 (동일한 폴더 구조, 라이브러리 위치, 환경 설정)에 필수 인 건물 환경에 대한 표준을 채택하면 유용 할 수 있습니다.
  2. 빌드 및 배포 프로세스를 분석해보십시오. 솔루션이 최신 버전의 코드로 빌드되지 않았고 배포 전에 테스트되지 않은 경우 이상하게 보입니다. ("BPL에 버그 수정을하면 각 프로그래머가 ...").
  3. 독립 실행 형 실행 파일이있는 변형은 테스트 환경 및 프로젝트 배포의 구성을 크게 단순화하므로 더 좋아집니다. 버전 지정을위한 적절한 규칙을 선택하십시오.