내부 애플리케이션을위한 내부 라이브러리를 개발해야하는 이유

내부 응용 프로그램 개발 전용으로 사용할 내부 라이브러리를 개발해야하는 이유를 이해하는 데 어려움이 있습니다. 조직 외부의 누군가가 작성한 소프트웨어를 사용하려면 헤더 파일과 .a 또는 .so 파일을 보내서 프로젝트에 링크 할 수 있습니다 (동일한 환경에서 컴파일되었다고 가정). .

그러나 헤더 및 구현 파일에 액세스 할 수 있고 소스 트리에 포함시키고 모두 함께 컴파일 할 수있을 때 내부 응용 프로그램에 연결되도록 내부 라이브러리를 개발 해야하는 이유는 무엇입니까?

다시 말해, 일부 소스 코드가 작성된 경우 이진 라이브러리로 컴파일하여 응용 프로그램에 연결하거나 프로젝트의 소스 파일에 포함시키고 정기적으로 컴파일해야하는지 어떻게 결정합니까?

각 프로젝트에 '포함'파일을 말할 때 각 파일을 복사하여 현재 개발중인 프로젝트의 소스 트리에 붙여 넣는 것은 아닙니다. 일반적인 방법으로 프로젝트 파일에 포함될 수있는 공통 소스 코드를 포함하는 디렉토리 / 라이브러리 (모든 프로젝트와 분리)를 개발하는 것을 의미합니다 (예 : #include).

추신 : 나는 여러 데스크탑 응용 프로그램을위한 c / c ++ 개발에 대해 이야기하고 있습니다.

내부 사용 을 위해 라이브러리 및 공유 라이브러리 (.dll 또는 .so 파일) 를 작성하는 데는 여러 가지 이유가 있습니다 .

1. 프로젝트 간 재사용이 훨씬 깨끗합니다.
2. 책임 분리-코드의 일부가 다른 개발자 나 팀에 더 적합 할 수 있습니다.
3. 특정 코드를 찾을 필요없이 다른 팀이 만든 라이브러리를 개선 할 수 있습니다
4. 더 빠른 빌드 시간, 라이브러리가 안정적인 경우 다시 빌드 할 필요가 없습니다.
5. 디스크 공간-프로젝트에서 라이브러리와 헤더 만 가질 수 있습니다
6. 공유 라이브러리를 사용하는 경우 여러 프로그램에서 사용중인 경우에도 RAM에 하나의 사본 만로드하여 메모리를 절약 할 수 있습니다.
7. 일반적으로 라이브러리에 대한 더 나은 문서화 및 테스트로 끝납니다.
8. 사물을 라이브러리로 구성하는 것에 대한보다 깔끔한 디자인과 코드 생각은 각 라이브러리에서 관련 기능 그룹을 생성해야 하며, 애플리케이션의 특정 애플리케이션 과 앱의 일반 코드 를 라이브러리로 분리하는 경향 이 있습니다 .
9. 라이브러리에 독점 알고리즘이있는 경우 계약자 나 외부 팀이 소스에 접근하는 것을 허용하지 않는 등 소스에 대한 액세스를 제한 할 수 있습니다.
10. - 라이브러리 코드가 자랑 것을 원래, 일부 기업은 심지어 오픈 소스 라이브러리로 알려져있다의 일환으로 작성된 응용 프로그램에 다른 라이센스하에 둘 수있다 기여 오픈 소스 커뮤니티의 주요 명성 언젠가 주요 개선 사항을 얻고 뒤.

일부 회사는 도서관을 만드는 프로젝트가 재사용 할 때마다 상환을받는 회계 관행을 가지고 있습니다.

더 크고 사소한 프로젝트에 적용될 수있는 다른 가능한 이유는 다음과 같습니다.

• 컴파일 시간 : 수천 개의 파일, 수천 개의 클래스, 함수 등을 포함하는 거대한 단일 C ++ 프로젝트는 컴파일하는 데 시간이 오래 걸릴 수 있습니다 (몇 줄의 코드를 변경할 때마다 다시 컴파일하려는 경우 생산성이 저하됩니다). 정적으로 링크 된 라이브러리와 동적으로 링크 된 라이브러리는 독립적으로 컴파일되며 소스가 변경되지 않은 경우 다시 컴파일 할 필요가 없습니다.

• 별개의 모듈 또는 하위 시스템의 논리적 분리 : 별개의 기능 영역이 별개의 모듈에 배치되는 경우 일반적으로 큰 시스템을 관리하기가 쉬우 며 개발자는 수천 개의 파일 / 클래스가 포함 된 거대한 폴더 / 프로젝트를 검색하지 않아도됩니다.

• 개발자 / 팀 간의 경계 : 동시에 별도의 새로운 기능을 구축하는 개발자는 각 개발자가 서로 다른 모듈에서 작업 할 수있는 경우 병합 충돌 가능성을 줄일 수 있습니다.

• 라이브 환경으로 공개해서는 안되는 코드 : 예를 들어 개발자 테스트에 라이브 시스템 구성 요소 (하드웨어, API, 원격 시스템, 데이터베이스 등)를 대체하기 위해 사용되는 단위 테스트 라이브러리 또는 '모의'라이브러리

• 컴파일러 플래그 : 이상한 컴파일러 플래그를 기대하는 타사 API와 통합하는 매우 불행한 위치에있는 경우 라이브러리는 타사 API와 나머지 응용 프로그램 사이에있는 "오염 제거 계층"이 될 수 있습니다.

• 선택적 기능 / 최적화 : 대규모 시스템에서 응용 프로그램의 기본 기능에 중요하지 않은 경우 동적으로 링크 된 특정 모듈을 런타임에 메모리에로드하기 전에 응용 프로그램이 대기 할 수 있습니다.

일반적으로 많은 내부 프로젝트는 종종 소규모 마이크로 앱으로 별도의 라이브러리로 분류되지 않는 이점이 있습니다. 작은 개발자로 작은 프로젝트를 수행하는 경우 코드를 라이브러리로 분할하는 것에 대해 걱정할 필요가 없습니다 (아직 ...). YAGNI 원칙을 잊지 마십시오 .

원래 질문으로 인해 다른 답변 대부분이 여기에 오해되었을 수 있습니다. 프로젝트 전체에서 기존 코드 를 복사 하지 않고 reference 와 다른 프로젝트의 동일한 소스 파일을 포함 시키려고하므로 "중복 코드"인수와 다른 많은 인수가 의미가 없습니다.

이것은 때때로 현명한 기술인 경우도있다 . 실제로, 프로젝트 전체에서 재사용하려는 모든 소스 파일을 하나의 개별 포함 폴더에 넣을 때 이미 바이너리 라이브러리가 아닌 소스 코드 라이브러리 인 라이브러리를 이미 빌드했습니다. 특히 C ++에서 템플릿을 사용하여 일반 라이브러리를 만들 때 간단한 포함이 필요하고 별도의 링크 준비가 필요없는 헤더 전용 라이브러리가있는 것은 드문 일이 아닙니다.

그래서 당신의 실제 질문은 언제 소스 코드 라이브러리를 빌드 할 것인지, 또는 사전 컴파일 된 바이너리 라이브러리를 선호 할 것입니까? 이러한면에서 이 사이트에 나이가 대답 , 어쩌면 그것은 당신을 도움이 헤더 전용 libs와의 몇 가지 장점과 단점을 논의했다. 소스 코드 라이브러리의 주요 장점은 라이브러리를 사용하는 응용 프로그램과 동일한 런타임 및 / 또는 호환 가능한 컴파일러 / 링커 플래그로 컴파일 할 필요가 없다는 것입니다. 단점은 추가 컴파일 시간과 소스 코드에 대한 액세스를 제공하기위한 요구 사항입니다 (이것은 분명히 "내부"프로젝트의 종류에는 문제가되지 않습니다).

다른 주석 작성자가 코드를 복제해서는 안된다고 작성할 때 동의합니다. 그러나 귀하의 경우 (또는 함께 일하는 사람들)는 다른 곳에서 복제 되지 않은 코드에 대한 라이브러리를 작성하는 것 같습니다 .

이 경우에는 조기 일반화에 주의하십시오 . 종종 코드 조각을 재사용 할 수있는 느낌이 드는 경우 가 있습니다. 그러나 두 번째 유스 케이스가 이러한 코드를 사용하는 방법에 대한 자세한 내용을 알지 못하면 추가 사례에서 실제로 유용하지 않거나 잘못된 것으로 가정하는 "재사용 성"기능에 추가 시간을 소비하는 것이 매우 쉽습니다. 두 번째 경우.

하나의 유스 케이스에 대해 "라이브러리"를 작성하면 아무런 보상없이 매우 비싼 연습이 될 수 있습니다.

비용 예 :

1. "일반적인"사용 사례를 고려하는 데 소요되는 시간 / 에너지
2. "라이브러리"를 "클라이언트"(자신의 코드)에 배포 할 수있는 시간
3. 다음 사용 사례와 완전히 일치하지 않더라도 "라이브러리"를 사용해야한다는 향후 압력

내 일반적인 규칙은 : 코드가 필요한 장소가 적어도 두 곳 이상이 아닌 한 코드를 라이브러리에 만들지 마십시오.

헤더와 구현 파일에 액세스 할 수 있고 소스 트리에 포함시키고 모두 함께 컴파일 할 수있을 때 내부 응용 프로그램에 연결되도록 내부 라이브러리를 개발 해야하는 이유는 무엇입니까?

"내 소스 트리에 포함시키기 만하면" 코드 가 복제 되기 때문 입니다.

문제는 코드를 복사 한 프로젝트에서 수행 한 개선 (중요 버그 수정 포함)의 이점을 얻지 못하거나 개선 한 내용의 이점도 없다는 것입니다.

최신 버전의 코드를 소스 트리에 정기적으로 복사하여 git 또는 이와 비슷한 서브 모듈을 사용하여 자동화 하여이 문제를 해결할 수 있다고 생각할 수도 있습니다. 그러나 호환되지 않는 API 변경으로 인해 빌드가 계속 중단됩니다. 반면에 라이브러리에는 클라이언트와 협력하지 않고 개발자가 변경할 수없는 "공식"공개 API가 있습니다.

마지막으로 기술적 인 이유가있을 수 있습니다. 코드의 일부를 라이브러리로 유지하여 필요할 때로드하거나 언로드 할 수 있으므로 기능이 필요하지 않을 때 메모리 사용량을 줄일 수 있습니까?

솔루션의 장기 실행 비용에 대해 자세히 설명하겠습니다.

분명히, 라이브러리를 프로젝트에 추가하는 것이 처음이라면 위의 모든 오버 헤드가 있습니다. 워크 플로를 변경해야하는 경우가 종종 있습니다. 때로는 인프라와 일부 팀원도 좋아하지 않을 수도 있습니다 (처음에는). 덜 비용을 부과 그래서 솔루션의 장점은 명백하다 지금 .

그러나 프로젝트가 성장함에 따라 "의사 라이브러리"비용도 증가합니다. A응용 프로그램과 단위 테스터가 사용 하는 "의사 라이브러리"가 있다고 가정합니다 . 에 cpp를 추가 할 때마다 A두 프로젝트 모두에 cpp를 추가해야합니다. 그렇지 않으면 연결되지 않습니다.

"의사 라이브러리"가 다른 "의사 라이브러리"에 의해 사용되면 B어떻게됩니까? 많은 프로젝트에 새 cpp를 추가해야합니다. 그리고 경우 B스위치 또 다른 라이브러리를 사용 하는가? 에 A따라 모든 프로젝트에서 cpps를 삭제해야합니다 B.

실제 라이브러리를 사용한다면이 모든 것이 무료입니다. 문제는 실제 라이브러리로의 이동을 정당화하기 위해 얼마나 많은 cpp가 필요합니까?

그러나 더 많은 담보가 있습니다. 개발자는 새로운 cpp를 필요로하는 모든 프로젝트를 사냥하는이 어리석은 작업을 좋아하지 않으며 기존 파일에 어딘가에 코드 / 클래스를 추가 할 것입니다. 장기적으로.

따라서 "의사-라이브러리"를 사용하는 것이 모 놀리 식 프로젝트를 분해하는 첫 단계가 될 수 있지만, 실제 라이브러리를 활용하여 장점을 활용할 수 있으려면 너무 오래 기다려서는 안됩니다.

그러나 헤더 및 구현 파일에 액세스 할 수 있고 소스 트리에 포함시키고 모두 함께 컴파일 할 수있을 때 내부 응용 프로그램에 연결되도록 내부 라이브러리를 개발 해야하는 이유는 무엇입니까?

라이브러리가 하나의 응용 프로그램 에서만 사용되는 경우 별도의 라이브러리로 필요 하지 않을 수 있습니다.

라이브러리가 3500 응용 프로그램에서 사용하는 경우에 당신은 절대적으로 할 별도의 라이브러리로 필요합니다.

라이브러리에 버그가 있고 수정해야하는 경우 어떻게합니까? 또는 어떤 법적 또는 규제 변화는 그 수단에 따라 제공 이 방법 라이브러리 작품을 변경?

별도의 라이브러리에있는 경우 (잠재적으로) 라이브러리를 수정하고 다시 테스트하고 다시 배포하면 모든 응용 프로그램 이 수정의 이점을 얻을 수 있습니다.

각 응용 프로그램에 "로컬"인 소스 코드에만있는 경우 모든 응용 프로그램을 개별적 으로 변경, 재 구축, 재 테스트 및 재배포해야합니다 . 그것은 훨씬 더 큰 운동입니다.