코드 재사용 라이브러리를 어떻게 작성하고 유지 관리합니까?

https://stackoverflow.com/questions/1302141

19-09-2019
|

문제

재사용 가능한 코드의 저장소를 설정하려고합니다. 각 재사용 가능한 코드 모듈에 특정 "성숙도"등급을 갖도록 생각하고있었습니다. 등급은 재사용 가능한 코드가 특정 요구 사항 세트 내에있는 수준으로 정의됩니다. 성숙도가 가장 높은 수준은 사전 정의 된 요구 사항 세트에서 최고 수준의 표준이 될 것입니다.

예를 들어:
수준; 요구 사항; 설명
레벨 0; 코드는 사용하는 것이 합법적입니다. 코드는 상업 산업/여러 계약에서 사용하는 것이 합법적입니까?
레벨 1; 기본 코드 라인 및 레벨 0 요구 사항을 충족합니다. 프로토 타입 코드, 타사 도구 등
레벨 2; 기능 인터페이스 및 주석이 있으며 레벨 1 요구 사항을 충족합니다. 각 클래스 및 기능에 대한 충분한 문서; 주석에서 기능을 결정할 수 있습니다
레벨 3; 코딩 표준을 준수하고 레벨 2 요구 사항을 충족합니다. 정의 된 코딩 표준에 따라 코드 확인 유틸리티 테스트를 통과합니다.
레벨 4; 테스트 사례를 포함하고 레벨 3 요구 사항을 충족합니다. 코드의 모든 기능을 테스트하기에 충분한 테스트 사례가 있습니다.
레벨 5; 재사용위원회의 승인 및 레벨 4 요구 사항을 충족합니다. 재사용 전문가와 동료들이 검토하고 모든 수준의 성숙도를 충족 시켰습니다.

이 성숙도 수준이 계층 적 구조 여야하는지 궁금합니다. 다음 레벨로 이동하려면 이전 수준의 요구 사항을 충족해야합니다 (위에 표시된 바와 같이).

아니면 다음 단계를 충족하기 위해 요구 사항의 하위 집합이어야합니까?

예를 들어, 우리는 Y 요구 사항 중 X를 충족하고 다음 단계로 이동할 수 있습니다 (요구 사항은 위에서 언급 한 것과 동일합니다).

레벨 0은 6 가지 요구 사항 중 0을 충족합니다
레벨 1은 6 가지 요구 사항 중 1 개를 충족합니다
…

서브 세트 접근법에서 볼 수있는 문제는 일부 요구 사항이 가중치가 더 강해야 하며이 접근 방식에서 고려되지 않는이 접근법에서는 구체적으로 시작되기 시작하지 않는 한 B 및 X에서 y를 충족하지 않는 한). 그러나 복잡해지기 시작할 수 있습니다.

누구든지 전에이 작업을 수행 한 적이 있습니까? 그렇다면 라이브러리를 어떻게 설정 했습니까? 당신은 전혀 또는 다른 구조에서 성숙도가 있습니까? 모든 입력은 크게 감사 할 것입니다.

해결책

코드 재사용 저장소를 설정하는 것은 어려운 작업입니다. 주요 어려움은 당신이 그것을 설정하는 방법이 아니라 다양한 라이브러리의 존재를 전달하는 방법 저장소에서. 라이브러리는 사용되는 경우에만 양호하며 알려진 경우에만 사용되며 코드의 품질이 높고 사용자의 요구를 충족하는 경우에만 사용됩니다.

나는 성숙도 수준에 대한 아이디어를 좋아하지만 다른 사람들이 게시 한 것처럼 아마도 약간의 설정/빌드 작업이있을 것입니다. 응용 프로그램 빌드에 대한 비슷한 접근 방식을 생각했습니다. 신뢰도라고 불렀습니다. 애플리케이션 빌드 경기장에서, 신뢰가 낮은 빌드는 단위 테스트를 통과하지 못한 것입니다. 중간 신뢰에는 단위 테스트 전달이 포함될 수 있지만 통합 테스트 등이 포함될 수 있습니다. 이것은 QA와 사용자에게 기대할 수있는 좋은 메커니즘이었습니다. 비슷한 메커니즘이 라이브러리에 적합 할 수 있습니다.

문서 의견은 필수이며, 코드에 넣을만큼 많은주의를 기울여야합니다. 의견은 무엇을, 왜, 어디서, 언제, 어떻게, 어떻게, 무엇을 전달해야합니다. 당신의 빌드 프로세스는 문서를 잘 알려진 위치에 게시해야합니다 (다시 커뮤니케이션은 핵심입니다).

의사 소통 라인을 따라, 때때로 존재하는 것은 아프지 않습니다. 다시! 의사소통.

따라서 최소한 각 라이브러리의 빌드는 다음과 같습니다.

라이브러리 게시 (가입자 알림)
문서를 게시하십시오
단위 테스트를 실행하십시오
성숙도 수준을 게시하십시오

성숙도 수준에 관해서는, 나는 "레벨 이름"과 레벨의 의미에 대한 설명으로 그것들을 정의 할 것입니다. 레벨 위 또는 아래로 이동하는 것이 무엇을 의미하는지에 대한 기준을 게시하십시오. 실제로, 이제 그것에 대해 생각하기 때문에 아마도 당신은 아마도 당신이 일련의 직교 기준을 원할 것입니다 : 코드 수준, 문서의 레벨, 사용 폴리티 (즉, xyz에 대한 라이센스가 있어야 함) 및 기타 속성이 필요합니다. 그래도 작은 단위로 접근하는 것이 좋습니다. 하루가 끝나면 최종 사용자에게 기능을 제공하는 것이 중요합니다.

재사용 가능한 비트를 자연스럽게 밀어 넣는 사고 방식을 저장소로 전달해야합니다. 개발자는 일반적 으로이 작업을 수행하려면 인센티브가 있어야합니다. 복제 및 피어 리뷰를 찾는 정적 코드 점검 도구는 지금까지만 진행됩니다. 누군가는 실제로 코드를 저장소로 이동하는 작업을 수행해야합니다.

마지막으로 저장소의 설정, 빌드, 유지 보수 및 통신에서 가능한 많은 도구 지원을 사용하는 것이 좋습니다. 그렇지 않으면, 비 코드 아티팩트와 마찬가지로, 비 코드 아티팩트가 날짜가되면 값을 낮추는 일정량의 엔트로피에 직면하게됩니다.

다른 팁

전체 개발 팀이 이러한 지침을 정확하게 따르도록 어렵다고 생각합니다. 특히 가이드 라인이 어떤 식 으로든 해석 될 수있는 경우. 또한 누군가가 테스트를 추가하여 코드를 개선하고 갑자기 다른 프로젝트로 이동해야한다면 큰 고통이 될 것입니다. 그럴 가능성이 높지 않을 가능성이 높습니다. 그러한 코드는 원래 프로젝트에 머무를 것이며 시간이 지남에 따라 성숙도 수준은 의미가 없습니다.

대기업에서 잘 작동하는 방법 중 하나는 다음과 같습니다.

모든 타사 라이브러리는 특수 디렉토리에 전념하며 항상 버전 번호를 포함합니다.
우리 자신의 일반적인 라이브러리는 참조 그들은 다른 것들을 가져야합니다. 예를 들어 유틸리티 코드가 참조하는 경우 Infragistics 라이브러리 그런 다음이 유틸리티 코드가 InfragisticsUtils 도서관.
명확하게 식별 할 수있는 "단위"를 형성하는 우리 자신의 일반적인 라이브러리는 별도의 라이브러리로 들어갑니다. 예를 들어, 가격 증권을 다루는 코드 라이브러리는 별도의 프로젝트입니다.
위의 어떤 것도 만족하지 않는 모든 재사용 가능한 코드는 모두 잡기로 들어갑니다. Utilities 프로젝트.
우리 자신의 라이브러리는 프로젝트가 참조 할 수있는 공유 위치로 편집되어 출시됩니다. 편집 된 바이너리를 참조할지 여부를 결정하는 것은 프로젝트 개발 팀에 달려 있거나 유틸리티 프로젝트를 솔루션에 포함시킬 것인지 결정합니다.

분명히 캐치에서 찾은 코드의 품질 Utilities 라이브러리는 크게 다를 수 있습니다. 이를 완화하기 위해 우리는 단순히 다른 개발 팀의 두 사람이 모든 체크인을 검토하도록 보장했습니다. Utilities. 이곳은 거기에있는 곳이없는 많은 물건을 제거합니다!

훌륭한 코드 저장소에는 CM 도구와 위키 도구가 포함될 것이라고 생각합니다. CM 도구는 코드를 품질별로 구성하므로 레벨 아이디어 (제안한대로)를 사용하여 구성되어야합니다. 위키는 소프트웨어가 할 수있는 일과 그것이 당신을 도울 수있는 방법의 "광고"역할을해야합니다. 이 Wiki는 또한 코드를 사용하는 프로젝트, 그것이 얼마나 유용한 지 등급 및 사용 방법의 예와 같은 정보를 유지할 수도 있습니다. 레벨 가이드 라인에 따라 개발 팀에 대해 걱정하는 사람이라면 자기 정책이 어떻게 작동하는지 지적하고 Wikis와 얼마나 잘 작동하는지에 대한 예를 들어야합니다.

이제 CM 도구의 구조화가 중요합니다. 코드의 품질을 전달하도록 설계되었으므로 사용할 때 얻는 내용을 알 수 있습니다. 예를 들어, 댓글이 거의없는 간단한 클래스를 작성하고 실제로 코딩 표준 (아마도 프로토 타입)을지지하지 않으면 sw_repository level0 examplePrototype에 입력됩니다.

어쩌면 누군가가 그 코드를 가져 와서 댓글을 추가하고 표준에 도달 할 수 있습니다. 그러면 그 사람은 sw_repository level1 examplePrototype에 배치합니다.

그런 다음 같은 사람은 잠시 후에 예제 프로토 타입에 대한 단위 테스트를 만듭니다. 이것은 Level2 등으로 이동합니다.

레벨을 정의하는 데 약간의 생각이 필요합니다. 예를 들어 프로토 타입 코드에 대한 단위 테스트를 작성했지만 주석과 코딩 표준을 만족시키지 못한 경우에는 레벨 0에 배치됩니다. 그러나 그러한 의견과 표준이 만족되면 Level2로 이동하기가 쉽습니다.

내 라이브러리의 경우 여러 응용 프로그램에서 사용할 수있는 코드를 넣었습니다. 코드가 특정 앱에 특정한 경우 라이브러리로 들어 가지 않습니다. 더 많은 앱이 사용함에 따라 버그가 해결되므로 버그가 즉시 버그가 없을 것으로 기대하지 않습니다. 라이브러리가 성숙하고 다른 앱으로 스트레스를 받으면 버그가 지속적으로 발견되고 고정됩니다. 그것은 결코 버그가 없지만 시간이 지남에 따라 신뢰성에 접근 할 것입니다. 또한 일부 물건에 대한 API가 잘못되었다는 것을 알면 걱정하지 않고 가능한 빨리 API를 리팩토링합니다.

다음은 C ++의 내 라이브러리입니다
http://code.google.com/p/kgui/

수년 동안 Microsoft는 소프트웨어 공장, 그 중 상당수는 재사용 문제를 해결하는 데 전념하고 있습니다.

재사용의 문제는 무엇입니까? 우선, 어렵습니다. 당면한 프로젝트의 즉각적인 요구를 넘어선 도서관과 API를 생각해내는 것은 매우 어렵습니다. 미래를 어떻게 예측합니까? 또한 지식 기반과 활기찬 실습 커뮤니티 역할을하는 중앙 저장소의 문제는 매우 어려운 일입니다. 매우 유연하지만 사용하기 쉬운 것을 어떻게 만드나요? 많은 사람들이 시도하고 실패했습니다. 둘 다 소프트웨어 공장 그리고 소프트웨어 제품 라인 이러한 문제를 해결하려고합니다.

행운을 빕니다!

언급 된 키트 가장 중요한 문제 : 재사용. 아이디어의 나머지 부분은 좋지만 세부 사항 이상은 아닙니다.

내 말은, 나는 나 자신의 재사용 도서관을 유지하는 데 어려움을 겪고 있습니다. 때때로 나는 매우 프로젝트별로 구현을하거나 어떤 아이디어를 위해 N-TH 프로토 타입을 수행하며, 그 중 어느 것도 내 도서관에 들어 가지 않습니다.

코드 재사용 라이브러리가 실제로 성공하면 많은 개발자가 사용하고 관리하는 방식으로 승리보다 사용합니다. 버전 제어 시스템과 버그 추적기가 필요하며 후자는 프로젝트 소유자와 사용자 모두가 사용합니다. 의사 소통과 기여 수단이 필요합니다. 프로젝트를 사용하여 소수의 개발자가 있으면 품질이 크게 향상됩니다. 구현이 향상됩니다. 문서가 작성되었습니다. API 및 기능 디자인은 훨씬 더 높은 수준입니다. 위원회는 좋은 일이지만 실제로 사용하지 않고 코드가 얼마나 좋은지 결정할 수는 없습니다. 코드가 특정 표준을 충족하는지 여부를 결정할 수 있지만 훌륭한 라이브러리에는 충족 표준이 충분하지 않습니다.

당신은 확실히 최선을 다해야합니다. 당신은 수많은 코드 스 니펫이 떠 다니지 않으며, 모두 무언가를 할 수 있습니다. 좋아, 모든 디자인 결정은 장단점이 있지만, 주어진 작업에 대한 하나의 프로젝트로 시작하고 실제로 필요한 경우 분기하는 것이 더 합리적이지만 프로젝트 팀 간의 의사 소통을 유지하고 (부분적으로) 합병을 고려하는 것이 더 합리적이라고 생각합니다. 뒤.

다른 프로젝트의 품질을 분류하는 것에 대해 너무 걱정하지 마십시오. 프로젝트가 나쁘면 사용자/개발자는 더 나은 수준으로 밀어 넣습니다. 대부분의 사람들은 도서관이 좋을 때, 그리고 그렇지 않은 경우 볼 수있을 정도로 영리합니다. 엄격한 규칙으로 참가자들에게 부담을 주려고 노력하기보다는 이러한 공생 효과에 에너지를 넣어야합니다.

내 2 센트 만 ...;)

Will Tracz의 "중고 프로그램 세일즈맨의 고백"과 HP의 재사용 랍비 인 Martin Griss의 물건을보십시오.

나는 당신이 비 문제가 너무 많이 생각하고 있다고 생각합니다.

내 도서관을 어떻게 설정 했습니까? 두 개 이상의 프로젝트에서 동일한 (또는 거의 동일한) 방법을 사용하는 경우 라이브러리로 이동하십시오.

자신의 도서관을 갖는 것은 좋은 접근법으로 간주되지만 수천 개의 줄은 파멸입니다!

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow