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

Esta é uma pergunta sobre como trabalhar em equipe.

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

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

Escrevendo para mim mesmo //TODOe revisitando essa linha de código posteriormente para verificar se o método foi implementado nesse meio tempo.
Pedir ao membro da equipe correspondente para implementar isso agora .
Lançar um runtimeException personalizado com uma descrição clara do que ainda não foi implementado. (Pelo menos, não precisamos procurar por muito tempo para descobrir o que está faltando)
Adicionando o método necessário à sua classe e escrevendo-os //TODOno corpo da mensagem, possivelmente também envie uma mensagem rápida sobre essa alteração. (Agora não é mais problema meu, mas isso pode causar conflitos irritantes de mesclagem se eles estiverem trabalhando nesse método nesse meio tempo)
Definir classes ou interfaces abstratas para tudo antes de realmente escrever o código que faz o trabalho. (Não funcionou muito bem porque essas interfaces eram frequentemente alteradas)

teamwork

— lucidbrot
fonte

Eu acho que o fluxo de trabalho em que você precisa de um método escrito por outra pessoa não é o correto. Você está trabalhando em um recurso. Se esse recurso exigir um método, você o implementará. Se duas pessoas implementam um único recurso, elas emparelham ou integram e se comunicam com tanta frequência que quase parece que elas são emparelhadas.

— Euphoric

@Euphoric Várias vezes me deparei com uma situação em que um novo recurso muito grande deveria ser desenvolvido em um prazo relativamente curto e, como tal, a interface do usuário, a lógica de negócios e as camadas de API precisavam ser divididas em tarefas diferentes para serem trabalhadas simultaneamente, caso contrário, o prazo nunca poderá ser cumprido. É exatamente nesse ponto que uma pessoa que trabalha na interface do usuário deve declarar apenas métodos e comandos de acesso a dados ao BL como interfaces e deixar que as outras pessoas trabalhem na implementação, enquanto trabalham exclusivamente na interface do usuário.

— 21717 Andy

@ DavidPacker O que você descreve não é a única maneira de resolver esse problema. Fatias verticais, integração frequente, pequenos recursos são soluções melhores do que fatias horizontais, com cada pessoa trabalhando em peças separadas.

— Euphoric

@Euphoric Não posso concordar mais com você. Quando possível, seguimos o caminho de eliminar o novo e complexo recurso de peças não críticas (ou seja, aquelas que apenas melhorariam o UX, mas não são necessárias imediatamente). Infelizmente, às vezes as opções que você mencionou, nem o recurso de remoção, não são possíveis. Os negócios dizem que os desenvolvedores fazem. Portanto, embora seus pontos sejam sólidos, também é provável que alguém encontre e encontre uma situação em que algum tipo de divisão de trabalho de recursos tenha que ser feito para atender às necessidades dos negócios.

— 21417 Andy

que tal falar com ele como ele quer lidar com isso?

— Aganju

Respostas:

É 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 exige que você volte e revise 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. Enquanto isso, seu código não pode ser compilado. 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 recomendada de qualquer maneira ... nunca verifique o código quebrado
As exceções de tempo de execução parecem melhores, mas ainda são tóxicas, porque seu colega programador pode 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, poderá levar a um código de produção quebrado ... más práticas também ... nunca verifique as exceções "não implementadas"
Esperar que seus colegas programadores implementem os métodos ou um stub também é assustador. Ele interrompe seu fluxo de trabalho e o de seus colegas programadores. O que acontece se eles estiverem doentes, em uma reunião ou no intervalo do café, você deseja gastar seu tempo esperando? ... não espere por alguém se não precisar
implementar os métodos ausentes definitivamente a melhor maneira de avançar. Mas o que acontece se sua implementação não satisfizer todo o caso de uso e seus colegas programadores precisarem alterá-lo ou alterá-lo? Como você e eles garantem que ele ainda é compatível com o seu objetivo? A resposta é fácil novamente. Escreva testes que verifiquem, descrevam e documentem suas intenções. Se os testes terminarem, é fácil perceber. Se forem necessárias alterações nesse método que quebrem 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 pelos testes

Para atingir um nível suficiente de teste, sugiro que você dê uma olhada em duas disciplinas.

TDD - desenvolvimento orientado a testes - isso garantirá que você descreva sua intenção e a teste suficientemente. Também oferece a possibilidade de zombar ou falsificar métodos e classes (também usando interfaces) que ainda não foram implementadas. O código e os testes ainda serão compilados e permitirão que você teste seu próprio código isoladamente do código de seus colegas programadores. (consulte: https://en.wikipedia.org/wiki/Test-driven_development )
ATDD - desenvolvimento orientado a teste de aceitação - isso criará um loop externo (em torno do loop TDD) que ajuda você a testar o recurso como um todo. Esses testes só ficarão verdes quando todo o recurso for implementado, fornecendo um indicador automático quando seus colegas concluírem o trabalho. Muito legal se você me perguntar.

Advertência: No seu caso, eu escreveria apenas testes de aceitação simples e não tentaria atrair muito do lado dos negócios, pois seria demais para começar. Escreva testes simples de integração que reúnam todas as partes do sistema que o recurso exige. 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 se aprofundar nesse tópico, verifique os seguintes links:

— Jesko R.
fonte

103

Peça stubs.

Ou escreva você mesmo. De qualquer forma, você e seus colegas de trabalho precisam concordar com as interfaces e como elas devem ser usadas. Esse contrato precisa ser relativamente solidificado para que você possa desenvolver contra stubs - para não mencionar, para criar suas próprias zombarias para os testes de unidade ...

— svidgen
fonte

^^ Isso. Se você estiver usando interfaces adequadamente, não precisará das implementações até que o outro cara termine de escrevê-las.

— Robert Harvey

E para mais comentários de Robert, se você não está usando corretamente as interfaces em um projeto especificamente projetado para ser dividida entre várias pessoas, bem, você vai ter um momento ruim ...

— corsiKa

É uma pena que o Java não tenha arquivos de cabeçalho. No mundo C / C ++, você pode trabalhar com suas APIs e escrever todos os seus cabeçalhos primeiro; a falta de implementação torna-se um problema para o vinculador. (Ligeira simplificação, a ABI também precisa permanecer constante para ser apenas uma questão de vinculador).

— Wes Toleman

@ WesToleman Divertidamente, uma das minhas coisas favoritas sobre Java é que ele não possui arquivos de cabeçalho. As "interfaces" mencionadas por Robert e corsiKa cumprem perfeitamente esse papel. Você trabalha primeiro com as APIs, escreve as interfaces e a falta de implementação concreta não é um problema para o compilador.

— GrandOpener

@WesToleman Isso funciona bem para você? Em meus ouvidos, isso parece muito com o estilo de queda de água, e meu palpite é que você precisa atualizar a interface ainda mais quando perceber que interpretou mal esse "parâmetro importante"?

— netigger

Na sua situação, eu conversaria com o membro da equipe responsável por essa função. Pode ser que eles estejam em posição 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 diz, não o considera mais seu problema. Seu colega então escreve a implementação da função e não considera mais o problema. Quem realmente vai testar se o código que VOCÊ escreveu funciona corretamente?

— Pete
fonte

Você deve solicitar a API para essa função que deve resultar em uma ou mais interfaces. Pode ser uma boa ideia fazer isso juntos, pois você precisará usar essa interface para poder projetar os casos de teste iniciais com base em suas informações. A implementação real pode vir mais tarde (incluindo possíveis alterações na API) #

— Thorbjørn Ravn Andersen