Incluindo uma biblioteca para usar uma classe de função / utilitário

5

No meu local de trabalho, tenho notado uma coisa estranha em que os desenvolvedores incluirão bibliotecas maiores para fazer coisas simples. Para ficar claro, somos uma loja da Scala. Aqui estão dois exemplos que ocorreram:

1) Em um projeto, fazemos a análise CSV, que era originalmente uma função de 3 linhas. Devido ao fato de o criador de CSV não gerar consistentemente o formato correto, ele cresceu para abranger vários casos de canto. Um desenvolvedor júnior decidiu trazer o scala-csv para sua descrição dos formatos CSV e para uma classe Exception. Ele não integrou a análise do CSV para usar a biblioteca até ser solicitado. Como ter duas maneiras de analisar o CSv em um sistema é estúpido, optamos por usar a biblioteca.

2) Um desenvolvedor sênior comprou um wrapper de scala para a Joda Time por sua capacidade de compra. Isso foi usado em um caso isolado. Quando solicitado a remover ou integrar a biblioteca completamente, a única desculpa dada foi "bem, podemos precisar dela mais tarde". Eventualmente, a biblioteca foi removida.

Embora ambas as histórias sejam diferentes, elas destacam uma mentalidade estranha de incluir apenas bibliotecas inteiras para funcionalidade de utilitário. Em ambos os casos, tive que intervir e insistir que nos integrássemos à biblioteca e usássemos sua funcionalidade principal ou a removêssemos.

Minha pergunta é se a minha insistência em usar a funcionalidade que uma biblioteca oferece totalmente ou não incluí-la / rolar sua própria abordagem é ruim? Minha preocupação é que carregar uma biblioteca para funcionalidade de utilitários apenas acrescente problemas de dependência sem nenhum benefício. Por exemplo, a versão do Joda, a biblioteca de invólucros, combina com a nossa?

    
por ahjmorton 09.10.2015 / 14:53
fonte

1 resposta

5

Bibliotecas são sobre alavancagem. No primeiro caso, a análise correta do CSV, para todas as muitas (diferentes) interpretações diferentes do CSV, já foi solucionada na biblioteca. É uma coisa perfeitamente boa fazer isso da maneira certa. Seu software é melhor e menor para ele.

A despesa primária da propriedade intelectual, como software de computador, é o custo de manutenção e extensão. Você está tentando comparar o custo de três linhas de software que lida com algumas fontes de dados restritas em relação a uma biblioteca, que requer uma linha de código build.sbt, que lida com quase todos os casos de CSV.

O custo real dessas três linhas é "bem, eu tenho que pré-verificar os dados para ver se eles escapam adequadamente de novas linhas incorporadas e garantir que o arquivo não venha de Joe, que incorpora vírgulas e ... "

Editar: Em relação à inclusão da biblioteca do nariz na porta:

Os desenvolvedores geralmente incluem bibliotecas sem nenhuma outra boa razão do que uma funcionalidade útil que eles podem usar aqui e agora. Existem várias bibliotecas que oferecem utilidade em uma determinada área.

  • Usando apenas, digamos, a funcionalidade de verificação de intervalo do Joda Time / Scala pode ser comparável ao uso de um multímetro como um pequeno martelo. Funciona, mas pode estar faltando o ponto. Por outro lado, talvez você queira migrar mais do seu ambiente para usar a manipulação de tempo muito superior dessa biblioteca. Esta é uma conversa ampla da organização que você precisa ter.
  • Uma situação muito pior surge quando várias bibliotecas diferentes são incluídas com funcionalidade substancialmente sobreposta. Meu favorito é a funcionalidade de verificação de string disponível no Apache Commons, Guava e meia dúzia de outras compilações. Um programador de cada vez Googles para função que faz um trabalho específico, e cada um seleciona uma biblioteca diferente. Essa é uma conversa ainda mais importante em toda a organização.

Toda essa questão está strongmente relacionada ao compartilhamento de classes e algoritmos em toda a sua organização. Requer conversas para descobrir requisitos, análise de duplicações e, mais útil, análise de lacunas.

    
por 09.10.2015 / 15:17
fonte