Como eu comunico a um colega que o código dele não faz nada? [duplicado]

34

Fique comigo aqui. Quando digo que o código "não faz nada", quero dizer algo como a seguinte função:

void factorial(int n)
{
    int result = 1;
    for(int i = 1; i <= n; ++i)
    {
        result *= i;
    }
}

Claro, essa função cria uma variável local e calcula um valor, mas não faz nada para avançar o programa; não há como usar o resultado do cálculo e ele não tem efeitos colaterais.

Tenha em mente que este é um exemplo inventado para os propósitos da questão, mas o código a que me refiro pode ser mais complicado.

Quando me deparo com esse código, muitas vezes passo um tempo extra e o faço várias vezes, porque tenho medo de estar perdendo alguma coisa. Eu poderia simplesmente pegar o caminho certo, consertar o bug e acabar com isso, mas temo que essa lentidão possa refletir mal em mim e no meu desempenho.

Então, devo seguir a estrada e assumir que a equipe entende ou devo comunicar que o código não faz muito? Se esta é a melhor opção, como faço isso sem ser condescendente ou desrespeitoso?

    
por AwesomeSauce 19.05.2015 / 10:44
fonte

8 respostas

83

A maneira mais fácil é pedir a partir de um ponto de não entender e pedir sua opinião. Não é bom dizer "o seu código é uma porcaria", é outra bem diferente dizer "erm, eu vi isso e realmente não consigo entender o que está fazendo ou por que está fazendo isso. O que você acha?" ou similar - você pode dizer qual é a sua preocupação e pedir que explique isso a você, ou pergunte a eles se você está certo.

Dessa forma, você faz com que eles façam parte da solução e normalmente perceberão o problema e o corrigirão (ou você pode oferecer para fazer isso por eles).

Tenho certeza de que você escreveu um código assim, você não vê até que alguém o aponte e você tem um momento. Trate esse código não como um grande e gritante erro, mas como apenas mais um pequeno detalhe que todos nós fazemos de vez em quando e você será bom.

    
por 19.05.2015 / 12:12
fonte
14

O objetivo de todo o código é, em última instância, afetar o mundo fora do programa de alguma forma. Ninguém se importa com o conteúdo de células de memória ou registros de CPU; eles só se importam com a página impressa ou com as informações exibidas em uma tela. Se o código não insere / gera nada, e não altera o estado do programa de qualquer forma que possa eventualmente causar qualquer E / S, é por definição supérfluo.

Mas como ver isso? A maneira mais fácil é ter testes unitários. Este código não pode satisfazer qualquer teste que verifique os valores reais dos factos a serem computados, uma vez que o único valor que é calculado nunca o torna fora da função. Basta escrever um caso de teste que codifique o que o código deve estar fazendo, e se torna trivial demonstrar que isso não acontece. (Reconhecidamente, essa não é a principal razão pela qual as pessoas geralmente defendem o desenvolvimento orientado a testes, mas funciona muito bem para esse propósito também.)

    
por 19.05.2015 / 11:20
fonte
11

Stay with me here. When I say the code "does nothing", I mean something like the following function

O termo correto para esse tipo de código-fonte é incomplete . Você poderia dizer a outro programador "Ao revisar seu código-fonte, encontrei uma função que está incompleta. Você pode esclarecer sua intenção?"

O trabalho incompleto faz o caminho para os produtos de produção o tempo todo. Existem muitas razões possíveis para isso acontecer.

  • O desenvolvedor pressionou essas alterações por engano.
  • O desenvolvedor precisava simular a funcionalidade até que ela pudesse ser concluída mais tarde.
  • O desenvolvedor não conseguiu concluir o trabalho, mas o empurrou de qualquer maneira.

When I encounter such code, I often spend some extra time and go through it several times, because I worry that I might be missing something. I could just take the high road, or fix the bug and be done with it, but I worry that this slowdown would reflect badly on me and my performance.

Sua autoconfiança e eficiência no trabalho não têm nada a ver com o trabalho produzido por outras pessoas. Os processos, a qualidade do código-fonte, a garantia de qualidade e o estilo de gerenciamento de uma empresa estão fora do seu controle (a menos que seja parte do seu trabalho alterá-los). Tente manter essas coisas separadas de como você percebe seu próprio desempenho e valor.

So, should I take the high road, and assume the team understands, or should I communicate that the code doesn't do much? If the latter is the better option, how do I do that without being condescending or disrespectful?

O que você está perguntando aqui não tem nada a ver com programação de computadores.

Eu gostaria de perguntar isso no link

Você provavelmente receberá respostas sobre como trabalhar de maneira eficiente em uma equipe.

  • Coloque 100% do seu esforço no seu trabalho. Ninguém pode culpá-lo se você tentou o seu melhor. Esperar mais do que aquilo que você é capaz de fazer é apenas uma administração tola. Tentar trabalhar rapidamente só faz você falhar mais rápido.
  • Comunique-se construtivamente com os membros da sua equipe. Fale e se expresse.
  • Ouça o que os membros da sua equipe têm a dizer.
  • Não seja um lobo solitário. Ajude a equipe a resolver problemas.
  • Compartilhe abertamente com os membros da sua equipe. Compartilhe suas ideias, pensamentos e preocupações. Não espere até que alguém pergunte. Faça um esforço para compartilhar.
  • Oferta para ajudar. Se você encontrar trabalho incompleto. Ofereça-se para terminá-lo.
  • Seja mais flexível. Em vez de reclamar sobre problemas. Esteja ciente de por que esses problemas existem e aceite-os. A maioria das pessoas estressadas em um projeto o fazem por causa de coisas que não podem mudar.
  • Seja sempre respeitoso, solidário e honesto com os colegas de equipe. Você pode não receber o mesmo em troca, mas aprenderá o valor desses traços.
por 19.05.2015 / 16:37
fonte
1

Se nada sair ou for referenciado fora do escopo do sistema que o código representa, não haverá uso. Você só precisa traçar uma linha em torno de todo o sistema e desafiar o obstinado a apontar onde realmente está cruzando.

    
por 19.05.2015 / 10:50
fonte
1

Peça ao desenvolvedor para guiá-lo pelo código na sessão de revisão de código e pergunte qual foi o processo de pensamento dele em torno dele. Veja se ele reconhece o comportamento supérfluo. Se ele não fizer isso, pergunte a ele especificamente sobre isso. Talvez um pouco mais indireto, mas não tão conflituoso.

    
por 19.05.2015 / 12:35
fonte
1

I worry that this slowdown would reflect badly on me and my performance.

Se a melhoria do código que você encontrar reflete muito em você, então você tem um problema muito maior em sua equipe do que exatamente como você levanta os problemas encontrados! OK, se não estiver quebrado, você não precisa corrigi-lo, mas, para um código redundante genuíno, provavelmente é uma boa ideia simplificá-lo removendo-o. As estimativas de tempo devem basear-se na realidade prática de entender o código durante a sua correção e corrigir os problemas encontrados. Se você está em um modo de crise e não pode fazer isso, a resposta seria "abaixe a cabeça e espere pelo melhor", mas isso deve ser raro.

O código redundante não é o pior problema que você pode encontrar, mas indica um erro no pensamento de quem o escreveu (ou o modificou para se tornar redundante). Por isso, merece pelo menos tanta atenção quanto qualquer outro refator potencial que você descobre no código que você visita, e talvez mais.

should I take the high road, and assume the team understands

Não. Você faz parte da equipe, você não entende, então nem todos entendem. Não assuma que existe um mistério maior para todo mundo. Muito mais provável, ninguém iria querer que fosse assim e todos os outros não perceberam ou não conseguiram melhorá-lo. Ou você está errado. No último caso, você se beneficiará de uma explicação do seu erro, no primeiro caso, alguém se beneficiará ao lidar com ele.

should I communicate that the code doesn't do much?

Dependendo de como a sua equipe se sente em relação à "propriedade" do código, pode ser que o correto seja corrigi-la e (se a alteração não fala por si) discuti-la quando suas alterações forem revisadas. Alternativamente, pode haver alguém na equipe que é a pessoa óbvia para falar sobre isso antes de prosseguir com uma mudança, seja o autor ou alguém com responsabilidade específica. Quando você fala com alguém, seja o dono ou um revisor de código, tudo o que resta é decidir o que dizer.

Se você se sentir confortável atirando direto do quadril:

"Este código não faz nada"

"Você esqueceu de devolver o resultado, devo corrigi-lo?"

"Esta função void não tem efeitos colaterais, para que serve?"

Naturalmente, isso pode ser considerado rude, isso realmente depende do seu relacionamento com a pessoa. Então você pode ser mais diplomático:

"O que esse código faz?"

"O resultado é necessário em qualquer lugar ou podemos pular esta parte?"

"Isso parece errado, então não tenho certeza se entendi tudo"

"Sinto muitíssimo incomodá-lo, mas não consegui entender essas poucas linhas de código. Parece-me que essa função não faz nada, então fiquei me perguntando por que isso acontece. É bem provável que eu tenha entendido errado, ou suponho que possa estar lá para apoiar alguma direção futura, e nesse caso eu queria saber se poderia adicionar alguns comentários para explicar o que ".

Naturalmente, o último exemplo tem uma linha tênue entre obsequiosamente educado e simplesmente condescendente. Algumas pessoas soam bem falando assim, outras soam como sarcásticos.

Pessoalmente, eu costumo ir com "Isso é para não devolver nada?". Estou esperando a resposta "não". É intencionalmente um pouco indelicado / brincalhão, porque com meus colegas atuais eu posso ser, mas eu não iria acusar ninguém de nada além de um descuido. E se a resposta for "sim" com uma razão, então é justo. Outra opção comum para mim é "eu acho que isso deve retornar alguma coisa". Ambas são coisas que eu ficaria feliz em me dizer.

    
por 19.05.2015 / 16:14
fonte
1

Eu teria preferido postar isso como um comentário, infelizmente estou com falta de representante.

No meu mundo, se não puder rastrear diretamente uma parte de um código para um requisito documentado ou um requisito derivado, sinalizarei para uma revisão da equipe que ocorre a cada duas semanas ou conforme necessário.

    // REVIEW: 05/19/2015
    // Can't find the need for this code. Perhaps it's been orphaned? 
    // Need to identify the requirement associated or remove it.
    public static bool WouldYouLikeToDance(this Person you, Person dancePartner)
    {
        // determine minimum acceptable attractiveness
        int minAcceptable = you.SelfWorthAndRespect - (you.CountDrinksConsumed() * 0.10);

        return (minAcceptable <= dancePartner.Attractiveness);           
    }

Acho melhor não confrontá-los diretamente, apenas identificar anonimamente as preocupações e esperar que eles façam o mesmo por você. Durante a revisão do grupo, você pode avaliar a equipe como um controle para garantir que você não esteja erroneamente identificando algo válido. O objetivo geral é a qualidade do código e como um efeito colateral, melhorando o conjunto de habilidades de cada desenvolvedor e da equipe como um todo.

    
por 19.05.2015 / 17:27
fonte
0

Se este código for apresentado durante a revisão de código, parece que você tem pouco problema; apenas forneça feedback de que você não está claro sobre o que ele faz e solicite um teste de unidade.

Se não for durante a revisão de código, talvez você queira pensar não apenas em como corrigir o problema imediato, mas também em procurar uma solução mais profunda em termos de mudança de processo.

Qualquer um dos itens a seguir pode pegar isso:

  • Níveis de aviso adequados em tempo de compilação, juntamente com um requisito de aviso zero no código.
  • Um processo de revisão de código
  • Cobertura suficiente de testes unitários.
  • Comentando padrões

Agora, o simples fato de você ter esse problema sugere que talvez alguns membros de sua equipe não sejam ótimos para ler código. Desgraçado, mas no mundo real é muito comum.

Eu observaria que as práticas acima são úteis até mesmo para uma equipe muito strong (comentar é discutível).

No entanto, o útil sobre as práticas acima é particularmente útil em uma equipe mais fraca; eles fornecem uma estrutura para ajudar a melhorar a qualidade do código sem que isso seja pessoal.

    
por 20.05.2015 / 01:41
fonte