올바른 오픈 소스 코드를 선택하기 위한 5가지 팁

Google에서 수행한 연구에 따르면 많은 개발자가 온라인에서 코드를 찾는 데 하루 중 많은 시간이 소요됩니다. 간단한 함수, 라이브러리, 유용한 패키지, 재사용 가능한 구성 요소 또는 유용한 "방법" 블로그 자습서를 찾는 것이 항상 간단한 것은 아닙니다. 찾은 코드를 신뢰할 수 있고 사용할 수 있는지 아는 것은 훨씬 더 까다로울 수 있습니다.

올바른 코드를 찾는 것은 일반적으로 Google이나 다른 검색 엔진의 신에게 의지하고 빠른 승리를 위해 쿼리를 입력하고 손가락을 교차하는 것을 의미합니다. "Javascript에는 고유한 속성이 있습니다"와 같은 간단한 기능 쿼리는 다른 포럼 및 블로그 게시물로 이어질 수 있지만 더 높은 수준의 설명("React component x")은 종종 GitHub 또는 NPM으로 연결됩니다.

그러나 올바른 코드를 찾은 후에도 이를 신뢰하고 사용하는 것은 완전히 다른 문제입니다. 실제로 사용할 수 있는 코드를 이해하는 데 도움이 되도록 고려하는 데 도움이 될 수 있는 5개의 매개변수를 수집했습니다. 올바른 결정을 내리기 위해서는 작업 자체의 특성뿐만 아니라 이러한 매개변수(무엇보다도)를 고려해야 합니다. 다음은 올바른 코드를 선택하기 위해 고려할 수 있는 5가지 키입니다.

#1. 코드를 읽을 수 있나요?

읽기 쉬운 코드는 좋은 주석과 문서 그 이상을 의미합니다. 코드 자체를 읽을 수 있어야 함을 의미합니다. 가독성을 위한 다양한 매개변수는 식별자, 적절한 간격, 명확하게 읽을 수 있는 논리, 잘 이해되는 범위 등에 대한 좋은 명명 규칙이 될 수 있습니다. 결론은 코드를 읽을 수 있어야 합니다. 귀하가 . 코드 조각을 선택하면 작동하지만 작동 방식을 완전히 이해하지 못합니다. 기본적으로 코드 기반에 유지 관리 시한 폭탄을 가져오는 것입니다.

읽을 수 없는 코드의 디버깅, 수정, 업데이트 및 유지 관리는 강력하게 피해야 하는 것입니다. 그것을 피하는 가장 좋은 방법은 가능한 한 애초에 허용하지 않는 것입니다.

#2. 코드가 적극적으로 유지되고 있습니까?

우리는 우리가 선택한 코드가 "살아있기를" 원합니다. 즉, 버그, 문제 및 업데이트가 처리되고 있으며 이 코드를 작성한 개발자가 이 코드를 적극적으로 유지 관리할 것임을 알고 싶습니다. 활동 표시기의 좋은 예는 GitHub의 미해결 문제, pull 요청 및 Pulse 표시기일 수 있습니다. 패키지 관리자는 종속성 및 종속 프로젝트 수와 같은 유지 관리와 관련된 정보를 제공하지만 여전히 이 분야에서 신뢰할 수 있는 지표를 제시하는 데 어려움을 겪고 있습니다.

그러나 인기 있는 대규모 프로젝트가 다른 패키지에 의존하는 경우 문제가 수정될 가능성이 높다고 가정할 수 있습니다(그러나 우리는 모두 왼쪽 패드를 기억합니다). 그러나 스택 오버플로에서 코드를 복사할 때(자체적으로 문제가 있음) 필요할 때마다(및 복사한 모든 위치에서) 직접 업데이트하는 것 외에는 이 코드가 유지 관리된다는 것을 신뢰할 수 있는지 알 수 있는 방법이 없습니다.

작은 핵심 기능은 단순히 많이 변경되지 않습니다. 이러한 정신에서 Bit에서 가져온 재사용 가능한 구성 요소는 작성자가 무언가를 변경할 때마다 구성 요소의 버전을 1씩 증가시키는 단순한 증분 버전 관리에 의존합니다. 구성 요소를 "최신 업데이트된" 버전으로 유지한다는 것은 좋은 테스트가 주어지면 유지 관리자가 코드를 적극적으로 유지 관리하는 동시에 코드의 작은 기능이나 구성 요소를 손상시키지 않고 업데이트할 수 있음을 의미합니다.

#3. 코드가 잘 테스트되었습니까?

작동하는 코드를 선택하는 것이 아마도 우리의 최우선 과제일 것입니다. 테스트는 내가 사용하는 코드가 실제로 해야 할 일을 하는지 알 수 있는 좋은 방법입니다. 테스트 설명은 또한 이 코드가 다른 상황에서 어떻게 동작하는지 알도록 도와주는 다양한 사용 사례와 에지 사례를 제시합니다. 테스트를 거친 구성 요소를 사용하면 전체적으로 유지 관리가 더 쉬운 소프트웨어를 만들 수 있으므로 프로덕션으로 롤링하기 전에 변경하려고 할 때 시간과 문제를 절약할 수 있습니다.

웹에서 복사한 스니펫은 일반적으로 테스트와 함께 제공되지 않습니다. 드물게 포럼이나 블로그 게시물에서 복사한 기능에 단위 테스트가 포함됩니다. 패키지와 라이브러리는 매우 잘 테스트될 수 있지만 문제는 이를 신속하게 파악할 수 있다는 것입니다. GitHub에서 라이브러리를 탐색할 때 저장소의 다양한 배지 또는 파일을 통해 이 코드가 얼마나 잘 테스트되었는지 알 수 있습니다. 테스트가 통과했는지 여부를 파악하기 위해 여전히 외부 도구에서 제공하는 지표를 사용해야 합니다. 패키지를 찾는 동안 어떤 패키지가 테스트되었고 테스트가 유용하게 통과되었는지 여부를 알 수 있는 신뢰할 수 있는 방법은 없습니다. 이것은 패키지 검색 가능성과 관련하여 큰 문제입니다. 재사용 가능

패키지를 찾을 때 어떤 패키지가 테스트되었고 테스트가 유용하게 통과되었는지 여부를 알 수 있는 신뢰할 수 있는 방법은 없습니다. 이것은 패키지 검색 가능성과 관련하여 큰 문제입니다. 재사용 가능한 비트 구성요소는 개발자가 이러한 테스트를 추가한 경우 테스트할 수 있습니다. Bit Scope는 Bit 커뮤니티 허브에서 구성 요소를 선택하기 전에(또는 로컬 시스템에서 분산 방식으로 사용하는 경우 CLI를 통해) 녹색 표시기와 테스트 설명이 온라인으로 표시될 수 있도록 테스트를 실행합니다.

#4. 다른 사람이 코드를 사용하고 있습니까?

인기는 우리가 진화적으로 신뢰하는 것입니다. 여론은 우리의 생존에 도움이 되는 결정을 내리는 데 좋습니다. 모든 사람이 나무에서 특정 과일을 먹는 것을 본다면 그것이 우리를 죽이지 않을 것이라는 것을 압니다. 모두가 덤불에서 도망치는 것을 본다면 곧 배고픈 호랑이가 따라올지도 모릅니다. 어느 정도는 2017년에 코드를 선택할 때도 마찬가지입니다.

프로그래밍 포럼 주변에서 정답을 표시하는 "V", 찬성 수 및 보컬 사용자 의견과 같은 다양한 표시를 사용할 수 있습니다. 이는 코드가 제대로 작동할 가능성을 높여주는 우수하고 안심할 수 있는 기능입니다. GitHub의 경우 스타, 협력자 및 기타 소셜 지표에 의존하여 신뢰할 수 있는 느낌을 얻을 수 있습니다. 패키지를 찾을 때 이 패키지의 다운로드 수가 좋은 지표입니다.

Bit 커뮤니티 허브에 있는 Bit 구성 요소는 다운로드 수, 협력자(범위 수준), 단순 "좋아요" 등(구성 요소의 이 React 범위에 표시됨)을 나타냅니다. 어느 쪽이든, 소셜 메트릭은 좋은 지표이지만 봇은 코드 품질에 대한 절대적인 진실임을 명심하십시오. 사람들은 종종 틀리고, 여론은 우리가 생각하는 것보다 빠르게 변할 수 있습니다.

#5. 코드가 문서화되어 있습니까?

문서화를 통해 코드를 훨씬 더 쉽게 이해하고 사용하고 수정할 수 있습니다. 또한 코드를 작성한 개발자의 생각과 주의를 보여주는 훌륭한 지표이기도 합니다. 스택 오버플로 또는 다른 블로그 게시물에 있는 코드에 대한 문서는 코드 자체의 주석과 코드가 발견된 실제 답변 또는 블로그 모두로 구성될 수 있습니다. 포럼 답변에 포함된 코드에 대한 유용한 설명이 포함된 경우, 코드 자체를 복사하여 붙여넣을 때도 추가할 가치가 있는 문서일 수 있습니다(다시 말하지만 코드를 복사하여 붙여넣지 마세요).

GitHub 리포지토리 및 패키지의 경우 상황이 조금 더 까다롭습니다. 일반적으로 GitHub 또는 NPM에 제공된 readme 및 문서 파일은 문서 품질에 대한 일반적인 표시를 제공합니다. Bit 구성 요소에 대한 문서는 코드 자체 내에서 구문 분석되므로 원자 구성 요소에 대한 실제 설명이 표시되며 React 구성 요소 및 기타의 다양한 기능 및 동작에 대한 인수 및 반환을 포함하는 지정된 서명과 사용 예도 포함될 수 있습니다. 어느 쪽이든 가능하면 문서화된 코드를 선택하는 것이 좋습니다.

GitHub 리포지토리 및 패키지의 경우 상황이 조금 더 까다롭습니다. 일반적으로 GitHub 또는 NPM에 제공된 추가 정보 및 문서 파일은 문서 품질에 대한 일반적인 표시를 제공합니다. Bit 구성 요소에 대한 문서는 코드 자체 내에서 구문 분석되므로 원자 구성 요소에 대한 실제 설명이 표시되며 React 구성 요소 및 기타의 다양한 기능 및 동작에 대한 인수 및 반환을 포함하는 지정된 서명과 사용 예도 포함될 수 있습니다. 어느 쪽이든 가능하면 문서화된 코드를 선택하는 것이 좋습니다.

결정하기

하루가 끝나면 인간의 기억력은 제한적이며 매번 바퀴를 재발명하는 데 별 의미가 없습니다. 그러나 오픈 소스 코드를 찾아 사용할 때 위의 지표는 애플리케이션이 보안, 유지 관리, 작동 및 양호한 상태를 유지하는지 확인하는 데 도움이 될 수 있습니다.

다른 사용 사례는 다른 매개변수에 다른 가중치를 부여하는 것을 의미합니다. 패키지를 선택할 때 패키지가 얼마나 테스트되고, 읽고, 문서화되고, 적극적으로 유지 관리되는지 알기 어려울 것입니다. 온라인 포럼에서 코드를 복사할 때 테스트, 유지 관리 등보다 인기를 우선시할 수 있습니다. 비트 구성 요소는 구성 요소 가져오기 및 재사용과 관련된 정보와 설명, 예제, 다운로드, 종속성, 테스트 설명, 테스트 결과 등과 같은 원자적 기능을 결합합니다. 이러한 다양한 매개변수를 신중하게 고려하여 정보에 입각한 결정을 내리고 작업에 적합한 코드를 찾고 선택하는 미로를 헤쳐나갈 수 있습니다.