올바른 종속성 선택: 포괄적인 실용 가이드

당신이 미슐랭 스타를 받은 고급 레스토랑의 셰프라면 검증되지 않은 출처에서 무작위로 야채와 고기를 사겠습니까? 거의 모든 평균 프로젝트의 비용은 수십만 달러, 심지어 수백만 달러로 측정됩니다. 저는 우리 업계도 레스토랑과 같은 접근 방식을 취해야 한다고 생각합니다.

즉시 스스로에게 물어볼 첫 번째 질문: 정말로 새로운 종속성이 필요한가? 언어나 설치된 라이브러리 등 현재 환경을 사용하면 문제가 해결될 수 있습니까? 예를 들어 UUID를 생성하기 위해 추가 라이브러리를 설치할 필요가 없습니다. Node.js와 브라우저는 즉시 이를 지원합니다 : crypto.randomUUID()

두 번째 질문: 전체 라이브러리가 필요합니까? 예를 들어, 드롭다운만 필요한 경우 Bootstrap과 같은 것을 설치할 가치가 있습니까? 어쩌면 Radix UI의 스타일이 지정되지 않은 드롭다운 구성 요소를 사용하여 집중된 단일 라이브러리로 제한하는 것이 더 나을 수도 있습니다.

좋아요. 우리는 몇 가지 후보를 염두에 두고 있습니다. 그렇다면 올바른 것을 어떻게 선택합니까?

아름다운 형식의 README? 잘 알려진 이름인가요? 다른 것보다 더 많은 포크, 별표 및 다운로드가 있습니까? 불행히도 이러한 요소만으로는 충분하지 않습니다. 여기서는 서비스 제공자를 선택합니다. 우리는 발생하는 모든 문제를 신속하게 해결하고, 기능을 최신 상태로 유지하며, 무엇보다도 서비스가 안전하고 신뢰할 수 있기를 바랍니다. 단순한 외부 지표가 항상 품질이나 장기적인 적합성을 나타내는 것은 아닙니다. 저장소 카탈로그에서 찾은 내용을 설치하기 전에 GitHub 저장소를 방문하여 해당 콘텐츠를 분석하는 것이 좋습니다.

나는 지난 몇 년 동안 사용해 온 기준 목록을 준비했습니다. 가장 적합한 라이브러리를 선택하는 데 도움이 되기를 바랍니다. 이를 포괄적으로 고려하는 것이 중요하며 경우에 따라 둘 중 하나를 선택할 때 타협을 해야 합니다.

면책 조항: 나는 아래에 언급된 라이브러리를 비판하거나 사용을 막으려는 것이 아닙니다. 어떤 경우에는 사실적 정확성을 유지하면서 기준 예에 집중하기 위해 의도적으로 이름을 생략했습니다.

1. 보안

사용하는 것이 얼마나 안전합니까? 허구처럼 들릴 수도 있지만, 그렇습니다. 의존성은 위험할 수 있습니다. 예를 들어, 다운로드 수가 50만 건인 라이브러리에 흥미로운 기능이 추가되었습니다 . IP 주소가 특정 범위에 속하면 컴퓨터의 모든 파일을 ❤️으로 바꾸려고 시도합니다.

흥미로운 사실은 이 종속성이 vue-cli 에서 사용되었다는 것입니다. 그러한 문제를 어떻게 발견할 수 있습니까? 문제 페이지를 확인하거나 도서관 이름으로 인터넷 검색을 시도해 보세요. 일반적으로 그러한 정보는 빠르게 나타납니다.

2. 유지관리

마지막 출시는 언제였나요? 릴리스는 얼마나 자주 발생합니까? 정기 릴리스를 통해 문제가 해결되고 업데이트가 끊임없이 변화하는 기술을 지원합니다. 모바일 개발의 맥락에서 정기 릴리스는 프로젝트가 성공적으로 컴파일되도록 보장합니다.

다음은 Go 세계의 예입니다. 18.2K 별이 있는 라이브러리의 작성자는 종속성 유지를 중단하기로 결정하고 이를 보관했습니다. 이는 몇 년 안에 지원 및 업데이트 부족이 문제가 될 것임을 의미합니다. 이제 GitHub를 먼저 확인하지 않고 비슷한 종속성을 설치한다고 상상해 보세요. 일종의 제품 유통기한을 확인하는 것이죠.

다음은 자주 출시되는 좋은 릴리스의 예입니다.

3. 공개/종료된 이슈

1. 공개된 이슈와 닫힌 이슈의 비율은 얼마입니까? 저자는 변경 사항을 얼마나 기꺼이 수용합니까? 언젠가 뭔가 기여해야 할 수도 있습니다. 예를 들어, 이 라이브러리는 매우 인기가 높으며 닫힌 문제의 비율이 98%입니다. 18개만 열려있습니다.

   

   
   

2. 중요한 문제는 얼마나 빨리 해결됩니까? 한번은 별이 31,000개 있는 ORM을 선택했는데 어느 시점에서 우리를 막는 문제에 직면했습니다. 우리는 해결 방법을 찾아야 했고 결국 다른 솔루션으로 전환해야 했습니다. 불행하게도 거의 4년이 흘렀지만 여전히 문제는 해결되지 않았습니다.

   

   이러한 문제는 댓글이 가장 많이 달린 항목을 기준으로 정렬하여 확인할 수 있습니다.

   
   

3. 창작자가 기여 과정을 구성했나요? 명확하고 정의된 워크플로가 마련되어 있나요? 예를 들어, Next.js 제작자는 기여 과정에 대해 40분짜리 비디오까지 녹화했습니다.

   
   

4. 코드 품질

예, 코드가 많을 수 있지만 코드의 다양한 부분을 검사하는 것은 항상 가능합니다. 프로젝트는 어떻게 구성되어 있나요? 이해하기 쉽고 체계적으로 구성되어 있으며 모범 사례가 적용됩니까? 코드가 나쁘게 작성될수록 향후 프로젝트가 종료될 가능성이 높아집니다. 이 단계에서 많은 소규모 후보자가 탈락했습니다.

5. 테스트 범위

도서관에 시험이 있나요? 테스트 범위는 무엇입니까? 테스트는 어떻게 작성되었나요? 관리자가 병합 요청을 검토하더라도 뭔가 간과될 가능성이 있습니다. 도서관에는 다양한 사람들이 기여하고 있습니다. 일반적으로 테스트 적용 범위 정보는 저장소 상단의 배지에 표시됩니다. 그러나 그렇지 않은 경우 언제든지 프로젝트에서 테스트를 검색할 수 있습니다. 예를 들어, formatjs 라이브러리 제품군은 뛰어난 테스트 범위를 가지며 다양한 유형의 테스트를 포함합니다.

6. 도서관 규모

모바일 애플리케이션은 종속성 크기가 큰 경우가 많으며 전체 앱의 크기가 200MB를 초과할 수 있으므로 셀룰러 네트워크 다운로드 중에 문제가 발생하고 많은 저장 공간을 소비할 수 있습니다. 이는 인터넷 속도가 느려 로딩 시간이 크게 늘어날 수 있는 프런트 엔드 CSR 앱의 경우 특히 문제가 됩니다.

웹 프로젝트의 경우 패키지 크기를 결정하는 훌륭한 도구가 있습니다: https://bundlephobia.com . 물론 서버측 렌더링과 트리 쉐이킹으로 인해 크기가 줄어들 수 있지만 이는 항상 확인되어야 합니다.

널리 사용되는 예는 날짜 조작 라이브러리입니다. dayjs (2.9KB)에서 제공하는 기능이면 충분할 수 있으므로 moment.js (72.1KB) 또는 date-fns (26.8KB)를 설치할 필요가 없습니다.

7. 종속성 수

위에 나열된 모든 점은 프로젝트의 전체 종속성 트리에 있는 종속성 수에 어느 정도 곱해집니다. 전체 종속성 트리를 확인하는 훌륭한 도구: https://npm.anvaka.com

8. 라이선스

이것에 대해 생각해 본 적이 있나요? 나도 마찬가지였다. 예를 들어, MIT 및 Apache 2.0 라이선스는 상업용 프로젝트에서 라이브러리를 무료로 사용할 수 있도록 허용하는 반면, 일부 GPL v2 라이선스에는 특정 요구 사항과 제한 사항이 있습니다. 우리 프로젝트 중 하나에서는 모든 종속성 트리의 라이센스를 확인하기 위해 변호사가 준비한 테이블이 있었습니다. 따라서 라이센스에서 특이한 점을 발견하면 감사 중에 문제가 발생하지 않도록 변호사와 상담하는 것이 좋습니다. legally 유틸리티를 사용하여 기존 npm 종속성에서 모든 라이선스를 추출할 수 있습니다. 추신: 저는 변호사가 아니며 이는 법적 조언이 아닙니다. 라이센스 때문에 뭔가가 적합하지 않을 수 있는 경우는 드물고 특수한 경우이지만 그래도 가능합니다.

끝!

제 글을 읽어주셔서 감사합니다! 피상적이고 빠른 의사결정이 때로는 최선의 선택이 아닐 수도 있다는 사실을 실제 사례를 통해 보여주는 것이 핵심이었습니다. 이러한 기준을 고려하면 보다 현명한 결정을 내릴 수 있습니다.

귀하가 갖고 있는 의견이나 제안 사항을 자유롭게 남겨주세요. 주저하지 말고 댓글로 여러분의 경험을 공유해 주세요. 여러분의 좋아요와 댓글은 제가 새로운 글을 쓰는 데 영감을 줍니다. 즐거운 요리 되세요 :)