Os perigos da dependência de código de terceiros

Se você assinar um serviço de um link nesta página, a Reeves and Sons Limited pode ganhar uma comissão. Veja nosso Declaração de ética.

Existem algumas coisas realmente boas sobre o modo como o software funciona na Internet. Para começar, há uma enorme rede não oficial de milhões de pessoas contribuindo para um enorme repositório de fragmentos de código que ajudam a alimentar mais milhões de aplicativos.

Cada vez que você vê um pequeno link na parte inferior de uma página da Web que diz “Powered by Fulano de Tal”, você está testemunhando esse efeito colaborativo em ação.

E, claro, a principal razão pela qual as pessoas gostam desse compartilhamento e colaboração de terceiros é que isso pode economizar muitas horas de desenvolvimento, porque você não está reinventando algo que já existe.

Mas mesmo com esses grandes benefícios do sistema de compartilhamento de código de terceiros, há muitos motivos pelos quais você pode querer evitar o uso desses fragmentos de código, como veremos em breve…

1. Potenciais riscos de segurança

Como praticamente todo o código que impulsiona qualquer coisa na Web é de código aberto, é justo apostar que, se houver alguma carga maliciosa em um determinado aplicativo, ela será rapidamente descoberta pela comunidade de desenvolvedores e rapidamente corrigida.

Mas muitos desses fragmentos de código são baixados centenas ou até milhares de vezes por dia, e nem toda equipe administrativa está fazendo um bom trabalho em manter um sistema seguro de compartilhamento de código.

Quanto maior e mais complexo for um aplicativo, mais fácil será infectá-lo adicionando algumas linhas de código em algum lugar obscuro. Quase ninguém leva tempo para investigar cada linha de código em um aplicativo, porque geralmente eles assumem que o código pode ser confiável.

Um programador altamente qualificado geralmente pode fazer um bom trabalho ofuscando a natureza maliciosa do código, e apenas outro programador altamente qualificado descobrirá qual é o seu propósito ... se o fragmento de código malicioso for detectado.

2. Você não é dono

Esta é realmente uma combinação de problemas. A primeira é que você pode estar sujeito a vários termos de licenciamento. Quando você tem vários fragmentos de código usados ​​em uma única página da Web ou aplicativo, você pode estar sujeito a vários termos e condições de licenciamento diferentes, e alguns deles podem estar em conflito entre si.

É claro que quase ninguém se preocupa em ler estas tediosas listas de termos e condições, mas isso pode ser potencialmente um erro.

Em particular, seria um erro se alguma condição no contrato de licença fizesse com que você violasse alguma lei em seu país de origem ou no país onde seu servidor está localizado.

A outra questão é que, se você não possui o código, não tem controle sobre ele e pode não entender necessariamente tudo o que ele faz ou como funciona.

Isso significa que se alguém fizer alguma alteração no código, você poderá ficar preso a essa alteração, especialmente se instalar fielmente atualizações, patches, upgrades e novas versões assim que forem lançadas como estáveis, ou se confiar inteiramente na entrega de conteúdo redes para suas soluções de terceiros.

3. Você frequentemente consegue muito mais do que precisa

O código de terceiros geralmente funciona para fazer o trabalho que você deseja, mas às vezes contém todos os tipos de recursos extras que você não precisa e provavelmente nunca usará.

Em alguns casos, você não pode remover esses recursos extras facilmente ou mesmo de todo. Você também pode ter que se comprometer. O recurso pode fazer algo muito próximo do que você pretende, mas não exatamente o que você pretende. Você está negociando coisas incríveis para ter menos trabalho a fazer, e isso nem sempre é uma boa negociação.

4. Múltiplos níveis de dependência de terceiros podem levar a problemas reais

Muitos projetos de código aberto usam os mesmos fragmentos de código de terceiros de maneiras diferentes para produzir seu software. Na maioria das vezes isso não é uma coisa ruim, mas pode causar problemas.

Hoje em dia, muitos desenvolvedores nem mesmo instalam os fragmentos que estão usando, mas os extraem em tempo de execução de redes de entrega de conteúdo sob demanda. O perigo disto foi ilustrado de forma espetacular pelo Incidente do Left-Pad de 2016.

Cada corrente é tão forte quanto o seu elo mais fraco. Este encadeamento de dependências significa que se qualquer elo em qualquer lugar da cadeia for quebrado ou comprometido, toda a cadeia corre o risco de mau funcionamento. Em algumas situações isso pode ser bastante caro.

Ninguém teria suspeitado do poder contido nas 11 linhas de código contidas naquela pequena função benigna chamada Left-Pad, mas quando esse elo específico da cadeia falhou, muitos grandes sites pararam bruscamente.

A maior parte disso era que a maioria das pessoas que usavam o Left-Pad não tinha ideia de que o estavam usando, o que ele fazia ou como resolver o problema. Conforme afirmado no item 2, se você não o possui, pode não necessariamente entendê-lo.

Left-Pad era uma função muito simples que apenas adiciona alguns espaços ao lado esquerdo de uma linha para garantir que a linha tenha o comprimento correto. Agora, a questão aqui é que qualquer programador competente poderia replicar facilmente essa funcionalidade.

Não há absolutamente nenhuma necessidade de qualquer aplicativo depender dessa função de terceiros e, ainda assim, milhares de sites usavam software que o incluía, incluindo Netflix, Facebook e Reddit. Foi apenas um golpe de sorte que neste caso foi uma função muito simples que quebrou a cadeia, e não uma função realmente complicada que tinha sua própria cadeia de dependências.

A linha inferior é se você pode construir você mesmo, você provavelmente deveria!

Em última análise, a decisão sobre o uso de blocos de código de terceiros em seu projeto se resume a uma série de decisões complicadas que nunca devem ser tomadas de ânimo leve. Os fatores que você precisa considerar são segurança, legalidade, custo, tempo e estabilidade.

Para tornar o processo de decisão mais simples, a seguinte condição de teste provavelmente ajudará.

SE qualquer um desses fatores for verdadeiro:

  • a função que você quer é simples
  • você (ou sua equipe) tem a capacidade de criar a função
  • há muito tempo para criar a função
  • sua aplicação precisa de boa segurança
  • você tem preocupações sobre possíveis problemas legais associados ao licenciamento de terceiros
  • é importante que seu aplicativo nunca falhe

Então você deve construir você mesmo,

Talvez seja mais eficiente usar as funções de terceiros, desde que você esteja ciente dos possíveis problemas e tenha uma estratégia em vigor para o que você fará se esses problemas surgirem.

Bogdan Rancea

Bogdan é um membro fundador da Inspired Mag, acumulando quase 6 anos de experiência neste período. Em seu tempo livre, ele gosta de estudar música clássica e explorar artes visuais. Ele é muito obcecado com fixies também. Ele é dono do 5 já.

Comentários Respostas 0

Deixe um comentário

O seu endereço de e-mail não será publicado. Os campos obrigatórios são marcados com *

NOTA *

Este site usa o Akismet para reduzir o spam. Saiba como seus dados de comentário são processados.