Como lidar com um método ainda não implementado que será feito por um co-programador?

45

Esta é uma pergunta sobre como trabalhar em equipes.

Recentemente eu trabalhei no meu primeiro projeto de programação maior (~ 80 classes, Java) com uma equipe de 6 pessoas, embora apenas 4 de nós estivessem continuamente trabalhando no código. Distribuímos o trabalho para ser feito logo no início e em algum momento eu precisei chamar um método que ainda não estava implementado por um dos meus co-programadores. Como é a maneira recomendada de lidar com isso?

Opções que eu vi, embora eu não goste de nenhuma delas:

  1. Escrevendo-me um //TODO e revisitando essa linha de código posteriormente para verificar se o método foi implementado nesse meio tempo.

  2. Solicitando ao membro da equipe correspondente que implemente agora .

  3. Lançamento de uma runtimeException personalizada com uma descrição clara do que ainda não está implementado. (Pelo menos não precisamos procurar muito tempo para descobrir o que está faltando)

  4. Adicionando o método necessário à classe deles e escrevendo-os com //TODO no corpo da mensagem, possivelmente também envie uma mensagem rápida sobre essa mudança. (Agora não é mais meu problema, mas isso pode causar conflitos de mesclagem irritantes se eles estivessem trabalhando nesse método nesse meio tempo)

  5. Definindo classes abstratas ou interfaces para tudo antes de realmente escrever o código que faz o trabalho. (Não funcionou muito bem porque essas interfaces foram alteradas com frequência)

por lucidbrot 28.12.2017 / 18:18
fonte

3 respostas

5

É uma pergunta interessante e a resposta pode ser mais fácil do que você pensa.

Simplificando, escreva testes que validem suas suposições. Não importa se você faz a implementação ou seus colegas programadores

A resposta longa.

Qualquer uma das opções listadas é um pouco passiva e requer que você retorne e revisite o código (se houver) mais cedo ou mais tarde.

  • Os Comentários precisam ser lidos e manipulados por sua contraparte responsável pela implementação. Seu código não pode ser compilado nesse meio tempo. Se você verificar esse estado em um repositório de código, seu pipeline de integração contínua não funcionará, e é uma prática ruim de qualquer maneira ... nunca verifique o código quebrado
  • Exceções em tempo de execução parecem melhores, mas ainda são tóxicas, porque o seu colega programador poderia assumir que a implementação já foi feita sem verificação, deixando o sistema em um estado instável também. Se o método não for acionado com tanta frequência, pode levar a um código de produção desfeito ... prática ruim também ... nunca verifique exceções "não implementadas"
  • Esperando por seus colegas programadores para implementação dos métodos ou um stub também é assustador. Isso quebra seu fluxo de trabalho e o fluxo de trabalho de seus colegas programadores. O que acontece se eles estão doentes, em uma reunião, no intervalo do café, você quer gastar seu tempo esperando? ... não espere por alguém se você não tiver que
  • implementa os métodos que faltam definitivamente é a melhor maneira de avançar. Mas o que acontece se a sua implementação não satisfizer todo o caso de uso e seus colegas programadores precisarem alterar ou alterar isso? Como você e eles se certificam de que ainda é compatível com o que você pretende? A resposta é fácil novamente. Escreva testes que verifiquem, descrevam e documentem suas intenções. Se os testes quebrarem, é fácil notar. Se mudanças nesse método precisarem ser feitas para quebrar seu recurso ... você o verá imediatamente. Vocês dois têm um motivo para se comunicar e decidir o que fazer. Dividir a funcionalidade? Altere sua implementação, etc ... nunca verifique o código que não está suficientemente documentado por testes

Para alcançar um nível suficiente de testes, sugiro que você dê uma olhada em duas disciplinas.

  1. TDD - desenvolvimento orientado a testes - isso fará com que você descreva sua intenção e a teste suficientemente. Também oferece a possibilidade de simular ou falsificar métodos e classes (também usando interfaces) que ainda não foram implementadas. O código e os testes ainda irão compilar e permitir que você teste seu próprio código isoladamente do código de seus colegas programadores. (veja: link )

  2. ATDD - desenvolvimento orientado a testes de aceitação - isso criará um loop externo (em torno do loop TDD) que ajudará você a testar o recurso como um todo. Esses testes só ficarão verdes quando todo o recurso for implementado, dando a você um indicador automático quando seus companheiros concluírem seu trabalho. Bastante arrumado, se você me perguntar.

Advertência: No seu caso, eu só escreveria testes de aceitação simples e não tentaria trazer muito do lado do negócio, já que seria muito para começar. Escreva testes de integração simples que reúnam todas as partes do sistema que o recurso requer. Isso é tudo o que é necessário

Isso permitirá que você coloque seu código em um pipeline de Integração Contínua e produza uma implementação altamente confiável.

Se você quiser ir mais longe nesse tópico, verifique os seguintes links:

por 30.12.2017 / 16:50
fonte
105

Peça stubs.

Ou escreva-os você mesmo. De qualquer forma, você e seus colegas de trabalho precisam concordar sobre as interfaces e como elas devem ser usadas. Esse acordo precisa ser relativamente solidificado para que você possa se desenvolver contra stubs - para não mencionar, para que você possa criar seus próprios mockings para seu teste de unidade ...

    
por 28.12.2017 / 19:28
fonte
6

Na sua situação, eu falaria com o membro da equipe responsável por essa função. Pode ser que eles estejam em condições de priorizar o desenvolvimento dessa função para que você possa começar a usá-la mais cedo.

Eu evitaria sua quarta opção. Você escreveu todo o seu código e, como você diz, você não considera mais o problema. Seu colega então escreve a implementação da função e não a considera mais como um problema. Quem vai realmente testar se o código que você escreveu funciona corretamente?

    
por 28.12.2017 / 18:34
fonte

Tags