의존성에 대한 두려움을 다루는 방법

내가 속한 팀은 회사 파트너가 플랫폼과 통합하는 데 사용할 수있는 구성 요소를 만듭니다.

따라서 (타사) 종속성을 도입 할 때는 각별히주의해야합니다. 현재 타사 의존성이 없으며 프레임 워크의 최저 API 수준을 유지해야합니다.

몇 가지 예 :

• 우리는 프레임 워크 (.NET 표준)의 최저 API 레벨을 유지해야합니다. 이에 대한 추론은 언젠가는 매우 낮은 API 수준 만 지원하는 새로운 플랫폼이 도착할 수 있기 때문입니다.
• JSON을 직렬화 해제하기 위해 자체 구성 요소를 구현했으며 JWT에서도 동일한 작업을 수행하고 있습니다. 이것은 상위 레벨의 프레임 워크 API에서 사용 가능합니다.
• 표준 라이브러리의 HTTP 구현에 대한 의존을 원하지 않기 때문에 표준 라이브러리의 HTTP 프레임 워크를 래퍼로 구현했습니다.
• XML과의 매핑을위한 모든 코드는 같은 이유로 "손으로"작성됩니다.

나는 우리가 그것을 너무 멀리 가져 가고 있다고 생각합니다. 나는 이것이 이것이 우리의 속도에 큰 영향을 미친다고 생각하기 때문에 이것을 다루는 방법이 궁금합니다.

... 우리는 프레임 워크 (.NET 표준)의 가장 낮은 API 레벨을 유지해야합니다…

이것은 당신이 잠재적으로 자신을 너무 많이 제한 할뿐만 아니라, 당신의 접근 방식으로 불쾌한 가을을 향하고 있다는 사실을 강조합니다.

.NET Standard는 " 프레임 워크의 가장 낮은 API 레벨 "이 아니며 절대로 사용되지 않습니다 . .NET에 대한 가장 제한적인 API 세트는 Windows Phone 및 Silverlight를 대상으로하는 이식 가능한 클래스 라이브러리를 작성함으로써 달성됩니다.

타겟팅하는 .NET Standard 버전에 따라 .NET Framework, .NET Core , Mono 및 Xamarin 과 호환되는 매우 다양한 API 세트가 생길 수 있습니다. 또한 .NET 표준과 호환되는 많은 타사 라이브러리가 있으므로 이러한 모든 플랫폼에서 작동합니다.

2019 년 가을에 출시 될 예정인 .NET 표준 2.1이 있으며 .NET Core, Mono 및 Xamarin에서 지원 될 예정입니다. .NET Framework의 모든 버전 에서는 최소한 가까운 장래에 항상 지원 될 것입니다. 따라서 가까운 장래에 " 프레임 워크의 가장 낮은 API 레벨 "이 아닌 .NET 표준은 프레임 워크를 대체하고 후자가 지원하지 않는 API를 갖게됩니다.

" 이 이유는 새로운 플랫폼이 이전 프레임 워크보다 더 높은 레벨의 API를 지원할 가능성이 높기 때문에 언젠가는 매우 낮은 API 레벨 만 지원하는 새로운 플랫폼이 도착할 수 있기 때문입니다."

그런 다음 타사 라이브러리 문제가 있습니다. 예를 들어 JSON.NET은 .NET 표준과 호환됩니다. .NET Standard와 호환되는 모든 라이브러리는 해당 버전의 .NET Standard와 호환되는 모든 .NET 구현에서 작동하도록 API 방식으로 보장됩니다. 따라서 사용하지 않고 JSON 라이브러리를 작성하여 추가 호환성을 얻지 못합니다. 당신은 단순히 더 많은 일을 만들고 회사에 불필요한 비용을 발생시킵니다.

그래서, 당신은 분명히 내 견해로는 이것을 너무 멀리 가져 가고 있습니다.

우리는 프레임 워크 (.net 표준)의 최저 API 레벨을 유지해야합니다. 이에 대한 추론은 언젠가는 매우 낮은 API 수준 만 지원하는 새로운 플랫폼이 도착할 수 있기 때문입니다.

여기에서 추론은 오히려 거꾸로입니다. 오래되고 낮은 API 레벨은 새로운 API 레벨보다 더 오래되고 지원되지 않을 가능성이 높습니다. 언급 한 시나리오에서 합리적인 수준의 호환성을 보장하기 위해 "최첨단"을 편안하게 유지하는 것이 합리적이지만 앞으로 나아갈 수는 없습니다.

JSON을 직렬화 해제하기 위해 자체 구성 요소를 구현했으며 JWT에서도 동일한 작업을 수행하고 있습니다. 이것은 상위 레벨의 프레임 워크 API에서 사용 가능합니다. 표준 라이브러리의 HTTP 구현에 의존하고 싶지 않기 때문에 표준 라이브러리의 HTTP 프레임 워크를 감싸는 래퍼를 구현했습니다. XML과의 매핑을위한 모든 코드는 같은 이유로 "손으로"작성됩니다.

이다 광기 . 어떤 이유로 든 표준 라이브러리 기능을 사용하지 않더라도 오픈 소스 라이브러리는 위의 모든 작업을 수행하는 상용 라이센스로 존재합니다. 이미 작성되었으며 기능, 보안 및 API 설계 관점에서 광범위하게 테스트되었으며 다른 많은 프로젝트에서 광범위하게 사용되었습니다.

최악의 상황이 발생하고 해당 프로젝트가 사라지거나 유지 관리가 중단되면 어쨌든 라이브러리를 빌드하는 코드가 있고 유지 관리 담당자를 지정합니다. 그리고 당신은 가능성이 여전히 당신이 현실에 더 돌봐, 청소기, 더 유지 보수 코드를 테스트 한 것이기 때문에, 자신의 압연 줄 것보다 훨씬 더 나은 위치에.

프로젝트가 유지되고 해당 라이브러리에서 버그 또는 악용이 발견 될 가능성이 훨씬 높은 시나리오에서는 무료로 최신 버전으로 업그레이드하거나 버전을 패치하는 등의 작업을 수행 할 수 있습니다. 당신이 복사본을 찍은 경우 수정 프로그램과 함께.

전체적으로 이러한 것들이 고객에게 좋습니다. 인기있는 오픈 소스 라이브러리조차도 어떤 이유로 사용할 수 없을 수도 있습니다.

예를 들어, 오픈 소스 제품을 사용하지 않기로 약속 한 고객과 계약을 체결했을 수 있습니다.

그러나 지적했듯이 이러한 기능에는 비용이 들지 않습니다.

• 시장에 시간
• 패키지 크기
• 공연

이러한 단점을 제기하고 고객과 협의하여 고객이 제공하는 uber 수준의 호환성이 실제로 필요한지 확인하십시오.

예를 들어 모든 고객이 이미 Json.NET을 사용하는 경우 자체 직렬화 해제 코드가 아닌 제품에서이를 사용하면 크기가 줄어들고 개선됩니다.

타사 라이브러리와 호환되는 라이브러리를 사용하는 제품의 두 번째 버전을 소개하는 경우 두 제품 모두를 파악할 수 있습니다. 고객이 타사를 사용하여 최신 기능을 조금 더 일찍 얻거나 '호환'버전을 고수합니까?

짧은 대답은 타사 종속성을 도입해야한다는 것입니다. 다음 스탠드 업 회의에서 다음 주 직장에서 몇 년 동안 가장 즐거웠을 것이라고 모든 사람에게 알리십시오. JSON 및 XML 구성 요소를 오픈 소스 표준 라이브러리 솔루션으로 대체 할 것입니다. 모든 사람에게 JSON 구성 요소를 교체하는 데 3 일이 걸린다고 말합니다. 완료 후 축하합니다. 파티를. 축하 할 가치가 있습니다.

기본적으로 모든 노력과 위험이 있습니다.

추가 종속성을 추가하거나 프레임 워크를 업데이트하거나 더 높은 수준의 API를 사용하면 노력을 줄일 수 있지만 위험을 감수합니다. SWOT 분석을 제안 합니다 .

• 장점 : 직접 코딩 할 필요가 없으므로 노력이 줄어 듭니다.
• 약점 : 손수 만든 솔루션만큼 특별한 요구에 맞게 맞춤 설계된 것은 아닙니다.
• 기회 : 출시 시간이 짧습니다. 외부 개발을 통해 이익을 얻을 수 있습니다.
• 위협 : 추가 종속성으로 고객을 화나게 할 수 있습니다.

수제 솔루션을 개발하기위한 추가 노력은 위협을 낮추는 데 투자하는 것입니다. 이제 전략적인 결정을 내릴 수 있습니다.

구성 요소 라이브러리를 종속성이없는 "핵심"세트 (본질적으로 현재 수행중인 작업)와 "핵심"및 써드 파티 라이브러리에 대한 종속성이있는 "공통"세트로 분할하십시오.

그렇게하면 누군가 "핵심"기능 만 원한다면 가질 수 있습니다.

누군가가 "공통"기능을 원한다면 가질 수 있습니다.

"Core"와 "Common"을 관리 할 수 ​​있습니다. "공통"에 기능을 더 빠르게 추가하고 구현을 제공하는 것이 합리적 일 경우 자체 "핵심"구현으로 옮길 수 있습니다.