종속성의 중요한 기능이 손상되어 개발을 방해하는 경우 어떻게해야합니까?

어제 나는 태그 로 작동하는 라이브러리를 사용하여 물건에 태그 (SE에 대한 질문)를 허용 하는 Rails 5 API 프로젝트를 진행하고 있었습니다 . Rails 5는 현재 알파를 지원합니다. 현재 마스터로 병합되기를 기다리는 버그를 수정하는 PR이 있습니다. 이 버그로 인해 기능 분기가 반쯤 중단되었습니다.로드가 손상되어 라이브러리의 기능을 구현할 수 없었습니다.

빠른 수정으로, 간단히 repo를 복제하고 PR과 동일한 코드로 문제를 수정하고 버그 수정이 마스터로 다시 병합 될 때까지 Gemfile (종속성 버전 제어 파일)을 내 Github 포크로 지정했습니다.

나는 수정이 간단 하고 누군가가 이미 해냈 기 때문에 운이 좋았 으므로 문제를 해결할 수있었습니다. 그러나이 라이브러리가 내 응용 프로그램 개발에 중요한 경우 어떻게해야합니까? 무엇 정지 된 버그를 수정 한 경우 내 개발을위한 대폭적인 문제가 아니었다 다른 사람 이이 시간에했던 것처럼 수정이 신속하게 주변에 오지 않았다, 그래서?

다른 종속 기능을 개발하기 전에이 기능을 완료해야한다고 상상해보십시오 . 해당 상황에서 무엇을하십니까? 나에게있어 태깅이 다음 개발 문구에 절대적으로 중요 하다면, 그 밖의 모든 것이 그것에 의존하고 있지만 태깅 종속성이 내 구성에 버그가있는 경우 어떻게해야합니까? 의존성의 중요한 기능이 (a) 기능의 개발을 방해 할 때 무엇을 하는가?

그리고 몇 시간 또는 며칠 동안 사무실 의자 에서 검을 싸는 것은 선택 사항이 아닙니다 ...

이것이 오픈 소스 소프트웨어를 사용하는 이유 중 하나입니다.

"비싸고 독점적 인 비공개 소스 라이브러리가 갑자기 넘어지면 어떻게됩니까? [대형 소프트웨어 회사]에서이를 해결해 줄 누군가가 있습니까?"에 대해 같은 주장을 할 수 있습니다. 오픈 소스 소프트웨어를 사용하면 적어도 그 버그를 직접 해결할 수있는 기회가 있습니다.

소프트웨어가 오픈 소스 라이브러리에 크게 의존하는 경우 위험을 완화하기 위해 수행 할 수있는 세 가지 작업이 있습니다.

1. 코드베이스에 익숙해 지십시오. 아마도 스스로 기여할 수도 있습니다. 이것이 오픈 소스를 선택한 또 다른 이유입니다.

2. 첫 번째 도서관이 쓰러지면 대체 도서관을 가지십시오. 이것이 바로 인터페이스에 프로그래밍하는 이유입니다. 필요한 경우 구현을 변경할 수 있습니다.

3. 최첨단 기술에 대한 요구와 안정성 요구의 균형을 맞 춥니 다 (즉, 알파 소프트웨어를 사용하지 마십시오). 당신이 무슨 일을하는지 알았어요?

버그 나 기능 부족으로 작업을 중단시킬 위험이 높은 응용 프로그램을 개발하는 솔루션은 위험도가 높은 라이브러리를 사용하지 않는 것입니다. 지루하고 절름발이입니다 ..

당신은 이것이 알파 릴리스라고 말했습니다. 중요한 프로젝트에는 알파 릴리스를 사용하지 마십시오. 1.0은 물론 베타 릴리스조차 아니므로 이런 종류의 일이 예상됩니다. 프로젝트에서이 단계의 핵심은 문제를 찾아 프로젝트를 강화하는 것입니다.

이 상황에서 자신을 찾으면 기본적으로 수행 한 작업을 수행해야합니다 (우리는 정확히 같은 일을했습니다). 그것을 고치고 프로젝트를 홍보하십시오.

그러나 솔루션은 기능 및 API에 대한 이해가있는보다 안정적인 라이브러리를 사용하거나 최소한 안정적인 버전과의 호환성을 유지합니다. 통제 할 수없고 성공해야하는 일에 100 % 의존해야합니다.

일반적으로 사용자가 작성한 어댑터 나 랩퍼 뒤에 타사 라이브러리를 숨기는 것이 좋습니다. 여기에는 두 가지 장점이 있습니다.

• 코드를 변경하지 않고도 타사 라이브러리를 다른 라이브러리와 교체 할 수 있습니다
• 자신의 어댑터 인터페이스에 대해 나머지 코드를 프로그래밍 할 수 있습니다. 라이브러리에 일시적인 문제가 발생하는 경우 자체 스텁 / 가짜 또는 단순화 된 버전의 라이브러리 기능을 연결하십시오. 이러한 방식으로 다운 스트림 기능의 개발 및 테스트 는 차단되지 않습니다 (전체 프로그램의 배포는 여전히 그렇더라도).