Os desenvolvedores devem compilar uma biblioteca interna antes do programa real?

Recentemente, um desenvolvedor sênior com quem trabalho fez questão de exigir que os desenvolvedores obtenham a versão mais recente e compilem como parte de seu projeto uma importante biblioteca interna. Isso contrasta com o contra-argumento de que as equipes de projeto devem trabalhar com uma versão estável obtida de um repositório Maven interno no qual o desenvolvedor argumentou que ter o código fonte disponível nas máquinas do desenvolvedor economiza tempo, pois eles podem ler a fonte das bibliotecas código para determinar se a funcionalidade necessária está disponível.

O desenvolvedor sênior tem um argumento válido? Ou está exigindo que os desenvolvedores leiam o código-fonte das bibliotecas, indo contra a filosofia básica do encapsulamento e até mesmo tendo a biblioteca em primeiro lugar?

O argumento deste desenvolvedor sênior não faz sentido para mim.

Eles querem adicionar uma sobrecarga de recuperar e compilar constantemente uma biblioteca interna, para que os desenvolvedores possam ocasionalmente ler o código-fonte? Isso vai desperdiçar muito mais tempo do que fazer com que os desenvolvedores vejam o código-fonte apenas quando precisam verificar se um recurso está disponível.

Essa é uma idéia particularmente ruim se a biblioteca e os clientes estiverem sendo desenvolvidos por diferentes grupos de desenvolvimento e a biblioteca estiver sendo ativamente desenvolvida. Os desenvolvedores do cliente não terão isolamento contra instabilidade na biblioteca.

Não vejo por que o código fonte não pode ser disponibilizado para os desenvolvedores sem forçá-los a fazer parte de sua compilação normal.

A sugestão é

Podemos economizar tempo por desenvolvedores do lado do cliente lendo o código-fonte da biblioteca para determinar se a funcionalidade necessária está disponível

Você poderia fazer uma sugestão alternativa

Podemos economizar tempo documentando a biblioteca para indicar qual funcionalidade está disponível.

Eu não compraria o argumento de que ter a capacidade de ler a fonte localmente é um benefício, mas se a biblioteca estiver em desenvolvimento ativo (possivelmente para adicionar suporte às necessidades do seu projeto), não acho razoável exigir que os desenvolvedores baixe atualizações com frequência (possivelmente várias vezes ao dia). Eu acho que faz sentido para os negócios disponibilizar um binário compilado (e testado por unidade) em vez de exigir que os desenvolvedores compilem a partir da fonte.

Você tem a capacidade em seu projeto de configurar algum tipo de repositório compartilhado onde a versão compilada mais recente estaria disponível? Idealmente, você deseja um servidor de CI que busque e construa de acordo com um cronograma, mas mesmo que seja apenas um recurso de rede que um dos líderes da equipe seja responsável pela atualização periódica, isso pode ajudar. Claro, isso deve estar no prato da equipe da biblioteca, mas obviamente eles não estão interessados, então você terá que pegar a folga deles.

Eu trabalhava para uma grande empresa de software que estava constantemente "alimentando cães" seu próprio software com sistemas internos de negócios.

Eles viram isso como outro nível de teste.

O fato de eu concordar com uma empresa é uma coisa boa.

Eu acho que forçar você a baixar e compilar a versão mais recente é um passo longe demais, a menos que a etapa de compilação seja uma parte importante da oferta de sua empresa de vender ou até terceirizar uma biblioteca.

Embora ter o código fonte disponível possa ser um benefício, se você tiver um agente de criação de IC monitorando o repositório, faz muito mais sentido que esse agente compile essa biblioteca e copie-a em projetos dependentes como externo, do que exigir que os desenvolvedores execute duas etapas diferentes de compilação ao criar sua cópia.

Atualmente, estou trabalhando em um projeto que não está conectado a um agente de construção, que exige a criação de um subaplicativo antes de criar o aplicativo principal. É uma dor séria no meu traseiro; Para fazer uma alteração no sub-aplicativo, preciso primeiro criar o projeto inteiro, depois ir para uma pasta de sub-construção, obter o produto compilado e copiá-lo para uma sub-pasta diferente, antes de criar todo o projeto novamente para garantir que a versão mais recente do sub-aplicativo esteja incluída na compilação do aplicativo principal. NÃO é assim que deve ser feito; no mínimo, deve haver um script MSBuild que automatize esse processo, e eu preferiria que o agente de construção atualize os externos sempre que um novo código for confirmado no tronco.

Como tantas pessoas responderam que não faz sentido que todos construam uma biblioteca interna, apresentarei o ponto de vista oposto que poderia justificar os motivos:

1. Você usa muito a biblioteca e não há documentação. Portanto, todos devem ter a fonte de referência. Se for uma biblioteca usada com muita frequência, ter a referência à mão pode ser útil

   • Claro, alguém poderia dizer que eles devem trabalhar na documentação e, muito provavelmente, seu desenvolvedor sênior está ciente desse fato. Mas vamos encarar a realidade, muitas vezes as equipes de desenvolvimento acabam com uma tonelada de código não documentado; portanto, quando você precisa saber como ele funciona, você acessa a fonte. Você não deveria ter que fazer isso, mas a curto prazo, essa é a melhor alternativa.
   • Geralmente, as melhores pessoas para colocar a documentação em prática são aquelas que conhecem melhor a biblioteca. Infelizmente, essas são as mesmas pessoas que geralmente são as mais ocupadas; portanto, muitas vezes não é tão fácil para elas largar tudo e começar a documentar.

2. Quando as pessoas começam a escrever seu próprio código que depende da biblioteca e algo na biblioteca não funciona, em vez de jogar os braços no ar, se a biblioteca for construída localmente, torna-se muito fácil entrar diretamente no código da biblioteca

   • Isso pode ocorrer porque muitas bibliotecas estão longe de serem perfeitas e, embora todos desejemos trabalhar com uma versão "estável", ainda pode haver problemas.
   • Talvez você esteja obtendo maus resultados por entender mal como uma API deve ser usada. Mesmo com a documentação, as pessoas costumam fazer suposições erradas
   • Seu veterano provavelmente está cansado de novas pessoas (e às vezes há muito mais pessoas novas do que aquelas que conhecem o projeto por dentro e por fora) jogando os braços no ar sempre que um acidente / outro erro parece vir de um código de biblioteca. Então, em vez de precisar ir até a sua máquina e depois para o cara sentado ao seu lado, eles querem a opção de responder com estas perguntas: 1) onde exatamente está a falha? qual módulo / arquivo / linha? 2) você depurou? o que você achou?
   • Seus funcionários mais antigos trabalharam com essa base de código (aplicativo e sua biblioteca principal) por tempo suficiente e, potencialmente, ele deve ter notado que, quando o código já está na máquina e está pronto para ser depurado e analisado, isso facilita sua vida e leva as pessoas para aprender a base de código mais rapidamente. Portanto, por esse motivo, ele obriga a assumir o custo inicial da construção da biblioteca em sua máquina.

Não estou dizendo que a decisão dele seja justificada, apenas apontando que a) a questão apresentou um lado da história eb) poderia haver motivos plausíveis.

Esse tipo de teste seria melhor feito de fato. O problema é que isso deve ser feito por testadores, não por desenvolvedores . Nesse sentido, não é seu trabalho nem o de desenvolvedor de bibliotecas.

_{Pelo que você descreve, parece que não há testadores no projeto - se esse for o caso, é um problema de gerenciamento e bastante sério.}

... economiza tempo, pois eles podem ler o código fonte das bibliotecas para determinar se a funcionalidade necessária está disponível

Raciocínio bastante manco. Quando a biblioteca de versões mais recente falha ao compilar com o projeto de versão mais recente, pode haver várias razões para isso - apenas pesquisar o código-fonte lib pode ser uma perda de tempo.

• E se a biblioteca estiver OK e a falha de compilação foi causada pelo erro no código do projeto? Ou, se a falha de compilação foi causada por uma mudança temporária incompatível que deveria ser corrigida um ou dois dias depois? E se uma falha de construção indicar um problema de integração complicado que levará uma semana ou mês para resolver? Para um problema de integração, o uso de uma biblioteca de versão anterior seria uma solução alternativa ou não?
   
  Qualquer que seja o motivo, fazer uma análise preliminar da falha significaria desperdiçar o tempo do desenvolvedor em um trabalho que deveria ser feito pelos testadores.

Outra coisa acima do raciocínio esquecido é inevitável (e bastante dolorosa na minha experiência) as perdas de produtividade que se seguem quando é preciso interromper o fluxo alternando entre atividades de desenvolvimento e controle de qualidade.

Quando há testadores na equipe, essas coisas são realmente simples e podem ser tratadas com muito mais facilidade. O que seu desenvolvedor "sênior" lançou para você é basicamente um requisito de teste preliminar.

Após todas as alterações feitas no projeto ou na biblioteca, verifique se a compilação foi bem-sucedida.

As etapas a seguir são atividades típicas de controle de qualidade: esclarecer detalhes de requisitos, projetar um cenário de teste formalizado, negociar como lidar com falhas de teste.

• Da perspectiva do SQA , essa é uma tarefa rotineira de projetar, configurar e manter um procedimento de teste de regressão bastante simples que pode ser altamente automatizado - provavelmente até o ponto em que apenas a atividade manual criaria e manteria tickets no rastreador de problemas e verificação de Conserta.

O que o Sr Dev está sugerindo faz pouco sentido para mim, na melhor das hipóteses. É bom poder procurar fontes, mas existem maneiras melhores de fazê-lo.

Que Repositório de Artefatos você está usando? Você deve implantar um jar de origem para cada versão ao lado da biblioteca compilada. A maioria dos IDEs permitirá anexar isso à biblioteca compilada para navegação na fonte. O Eclipse com o Maven Plugin fará isso automaticamente.

Se você precisar do código mais recente, poderá implantar instantâneos de versão.

Isso deve acontecer simplesmente no seu script de construção:

1. verifique se uma nova versão está disponível. pule 2 caso contrário.
2. faça o download e compile-o e execute as ferramentas necessárias para gerar uma referência de API a partir do código-fonte localmente. mostra um log de alterações.
3. construa seu aplicativo

Não vejo por que ou como isso é um problema. Além disso, quando algo está faltando na referência, você pode adicioná-lo às fontes e enviar as alterações. É claro que pode parecer um pouco assustador que a biblioteca possa mudar sob seus pés, mas se os mantenedores da biblioteca fizerem seu trabalho corretamente, isso é uma coisa boa.