ti-enxame.com

Como lidar com o medo de assumir dependências

A equipe da minha equipe cria componentes que podem ser usados ​​pelos parceiros da empresa para integrar-se à nossa plataforma.

Como tal, concordo que devemos tomar muito cuidado ao introduzir dependências (de terceiros). Atualmente, não temos dependências de terceiros e precisamos permanecer no nível mais baixo da API da estrutura.

Alguns exemplos:

  • Somos forçados a permanecer no nível mais baixo da API da estrutura (.NET Standard). O raciocínio por trás disso é que uma nova plataforma poderá chegar um dia que suporta apenas esse nível de API muito baixo.
  • Implementamos nossos próprios componentes para (des) serializar JSON e estamos no processo de fazer o mesmo para o JWT. Está disponível em um nível superior da API da estrutura.
  • Implementamos um wrapper em torno da estrutura HTTP da biblioteca padrão, porque não queremos depender da implementação HTTP da biblioteca padrão.
  • Todo o código para mapear para/do XML é gravado "manualmente", novamente pelo mesmo motivo.

Sinto que estamos levando isso longe demais. Eu estou querendo saber como lidar com isso, já que isso afeta muito nossa velocidade.

54
robinwit

... Somos forçados a permanecer no nível mais baixo da API da estrutura (.NET Standard)…

Isso para mim destaca o fato de que, não apenas você está se restringindo demais, como também pode estar caminhando para uma queda desagradável com sua abordagem.

O .NET Standard não é e nunca será " o nível mais baixo da API da estrutura ". O conjunto mais restritivo de APIs para .NET é alcançado através da criação de uma biblioteca de classes portátil que se destina ao Windows Phone e Silverlight.

Dependendo da versão do .NET Standard que você está direcionando, você pode acabar com um conjunto muito rico de APIs compatíveis com o .NET Framework, . NET Core , Mono e Xamarin . E há muitas bibliotecas de terceiros compatíveis com o .NET Standard que, portanto, funcionarão em todas essas plataformas.

Depois, existe o .NET Standard 2.1, que provavelmente será lançado no outono de 2019. Ele será suportado pelo .NET Core, Mono e Xamarin. Ele não será suportado por nenhuma versão do .NET Framework , pelo menos no futuro próximo e, provavelmente, sempre. Portanto, no futuro próximo, longe de ser " o nível mais baixo da API da estrutura ", o .NET Standard substituirá a estrutura e terá APIs que não são ' t suportado por este último.

Portanto, tenha muito cuidado com ". O raciocínio por trás disso é que uma nova plataforma poderá chegar um dia que suporta apenas esse nível muito baixo da API ", pois é bem provável que novas plataformas de fato suportam uma API de nível superior ao da estrutura antiga.

Depois, há o problema de bibliotecas de terceiros. JSON.NET, por exemplo, é compatível com o .NET Standard. Qualquer biblioteca compatível com o .NET Standard é garantida - em termos de API - para funcionar com todas as implementações do .NET compatíveis com essa versão do .NET Standard. Portanto, você não obtém compatibilidade adicional ao não usá-lo e criar sua biblioteca JSON. Você simplesmente cria mais trabalho para si e incorre em custos desnecessários para sua empresa.

Então, sim, você definitivamente está levando isso muito longe, na minha opinião.

94
David Arno

Somos forçados a permanecer no nível mais baixo da API da estrutura (padrão .net). O raciocínio por trás disso é que uma nova plataforma poderá chegar um dia que suporta apenas esse nível de API muito baixo.

O raciocínio aqui é bastante inverso. Níveis de API mais antigos e mais baixos têm maior probabilidade de se tornar obsoletos e sem suporte do que os mais novos. Embora eu concorde que é sensato manter-se confortável atrás da "vanguarda" para garantir um nível razoável de compatibilidade no cenário mencionado, nunca avançar é além do extremo.

Implementamos nossos próprios componentes para (des) serializar JSON e estamos fazendo o mesmo para o JWT. Está disponível em um nível superior da API da estrutura. Implementamos um wrapper em torno da estrutura HTTP da biblioteca padrão porque não queremos depender da impulsão HTTP da biblioteca padrão. Todo o código para mapeamento de/para XML é gravado "manualmente", novamente pelo mesmo motivo.

Isso é loucura. Mesmo que você não queira usar as funções de biblioteca padrão por qualquer motivo, as bibliotecas de código aberto existem com licenças compatíveis comercialmente que fazem tudo isso acima. Eles já foram escritos, testados extensivamente do ponto de vista da funcionalidade, segurança e design da API e usados ​​extensivamente em muitos outros projetos.

Se o pior acontecer e esse projeto desaparecer ou parar de ser mantido, você terá o código para construir a biblioteca de qualquer maneira e designará alguém para mantê-lo. E você provavelmente ainda está em uma posição muito melhor do que se tivesse criado o seu próprio, pois, na realidade, você terá um código mais testado, mais limpo e mais sustentável para cuidar.

No cenário muito mais provável de manutenção do projeto, e bugs ou explorações forem encontrados nessas bibliotecas, você saberá sobre eles para fazer algo a respeito - como atualizar para uma versão mais nova gratuitamente ou corrigir sua versão com a correção, se você tirou uma cópia.

51
berry120

No geral, essas coisas são boas para seus clientes. Mesmo uma biblioteca popular de código aberto pode ser impossível para eles usarem por algum motivo.

Por exemplo, eles podem ter assinado um contrato com seus clientes prometendo não usar produtos de código aberto.

No entanto, como você ressalta, esses recursos não são isentos de custos.

  • Tempo para o mercado
  • Tamanho do pacote
  • Atuação

Eu aumentaria essas desvantagens e conversaria com os clientes para descobrir se eles realmente precisam dos níveis uber de compatibilidade que você está oferecendo.

Se todos os clientes já usam o Json.NET, por exemplo, usá-lo em seu produto, em vez de seu próprio código de desserialização, reduz seu tamanho e aprimora-o.

Se você introduzir uma segunda versão do seu produto, uma que use bibliotecas de terceiros e uma compatível, poderá julgar a aceitação de ambas. Os clientes usarão os terceiros para obter os recursos mais recentes um pouco mais cedo ou seguirão a versão 'compatível'?

11
Ewan

Resposta curta é que você deve começar a introduzir dependências de terceiros. Durante sua próxima reunião, diga a todos que a próxima semana de trabalho será a mais divertida que eles tiveram em anos - eles substituirão os componentes JSON e XML por soluções de bibliotecas padrão de código aberto. Diga a todos que eles têm três dias para substituir o componente JSON. Comemore depois que terminar. Ter uma festa. Vale a pena comemorar.

7

Basicamente, tudo se resume a esforço versus risco.

Ao adicionar uma dependência adicional ou atualizar sua estrutura ou usar a API de nível superior, você reduz seu esforço, mas assume riscos. Então, eu sugeriria fazer um análise SWOT .

  • Pontos fortes: Menos esforço, porque você não precisa codificá-lo.
  • Fraquezas: não é tão personalizado para suas necessidades especiais quanto uma solução artesanal.
  • Oportunidades: o tempo de colocação no mercado é menor. Você pode lucrar com desenvolvimentos externos.
  • Ameaças: você pode incomodar os clientes com dependências adicionais.

Como você pode ver, o esforço adicional para desenvolver uma solução artesanal é um investimento na redução de suas ameaças. Agora você pode tomar uma decisão estratégica.

0
Dominic Hofer