O que você diz em uma revisão de código quando a outra pessoa criou uma solução complicada demais? [fechadas]

Outro dia, revisei o código que alguém da minha equipe escreveu. A solução não estava totalmente funcional e o design era muito complicado - o que significa que informações desnecessárias armazenadas, recursos desnecessários criados e basicamente o código possuíam muita complexidade desnecessária, como revestimento de ouro e tentaram resolver problemas que não existem.

Nesta situação, pergunto "por que foi feito dessa maneira?"

A resposta é que a outra pessoa sentiu vontade de fazê-lo dessa maneira.

Depois, pergunto se algum desses recursos fazia parte das especificações do projeto, ou se eles têm alguma utilidade para o usuário final ou se algum dado extra seria apresentado ao usuário final.

A resposta é não.

Então, sugiro que ele exclua toda a complexidade desnecessária. A resposta que eu costumo receber é "bem, isso já está feito".

Minha opinião é que isso não é feito, é de buggy, não faz o que os usuários querem e o custo de manutenção será maior do que se tivesse sido feito da maneira mais simples que sugeri.

Um cenário equivalente é: O
colega passa 8 horas refatorando o código manualmente, o que poderia ter sido feito automaticamente no Resharper em 10 segundos. Naturalmente, não confio na refatoração manualmente, pois é de qualidade duvidosa e não totalmente testada.
Novamente, a resposta que recebo é "bem, isso já está feito".

Qual é a resposta apropriada para essa atitude?

Mentalidade / atitude

• Lidere pelo exemplo
• Advertir em particular (individual, fora da revisão do código)
• Incentive uma mentalidade simples de manter-se entre os membros da equipe

Gerenciamento de equipe

• Gaste mais tempo na especificação de um item de trabalho (como arquitetura, estrutura de tópicos do algoritmo, estrutura de arame da interface do usuário, etc.)
• Incentive os membros da equipe a buscar esclarecimentos sobre o escopo de um item de trabalho
• Incentive os membros da equipe a discutir maneiras de implementar um item de trabalho
• Faça estimativas razoáveis ​​para cada item de trabalho antes de iniciar e faça os melhores esforços para encontrá-los
• Monitore a "melhoria" dos membros da equipe.
  • Depois de ser advertido ou ser mostrado o caminho certo para fazer as coisas, veja se o membro da equipe melhora.

Nível de habilidade

• Aloque algum tempo para sessões de programação em pares ou sessões de treinamento individuais para fazer o melhor uso das ferramentas do desenvolvedor (refatoração, revisão de código)

Gerenciamento de projeto (risco)

• Realize a revisão de código com mais frequência, de forma assíncrona (Nota)
  • Nota sobre "assincronamente"
    • O revisor de código deve receber notificações / convites para revisar as alterações assim que forem confirmadas
    • O revisor de código deve ter a chance de revisar o código antes de qualquer reunião com o desenvolvedor.
    • Se for necessário esclarecer o desenvolvedor, faça-o informalmente em IM / email sem emitir uma opinião negativa

O que você diz em uma revisão de código quando a outra pessoa criou uma solução complicada demais?

Você diz: "você criou uma solução excessivamente complicada".

Então, sugiro que ele exclua toda a complexidade desnecessária. A resposta que geralmente recebo é "bem, isso já está feito".

Se é tarde demais para mudar alguma coisa, por que você está fazendo uma revisão de código?

"Já está feito" não é uma resposta satisfatória. Concluído significa testado e funcionando. Todo código extra que não está fazendo nada de útil deve ser mantido da maneira correta (excluído).

Atribua a ele essa tarefa novamente pedindo para refatorar e otimizar sua solução. Se ele não fizer isso, atribua a ele um programador em pares e espero que ele aprenda algo com o colega.

Então, sugiro que ele exclua toda a complexidade desnecessária. A resposta que eu costumo receber é "bem, isso já está feito".

Essa não é uma resposta aceitável:

• Se é realmente tarde demais para mudar, a revisão do código é, em grande parte, uma perda de tempo, e o gerenciamento precisa saber disso.

• Se essa é realmente uma maneira de dizer "Eu não quero mudar", você precisa assumir que a complexidade extra é MAU para a base de código POR CAUSA dos problemas / custos que ocorrerão mais tarde. E reduzindo o potencial de problemas futuros, o verdadeiro motivo pelo qual você está revisando o código em primeiro lugar.

E ...

... a solução não estava totalmente funcional ...

Isso é possivelmente um resultado direto da complexidade desnecessária. O programador tornou tão complexo que ele não o entende completamente e / ou perdeu mais tempo implementando sua complexidade, e não os pontos de função. Vale a pena apontar para o programador que diminuir a complexidade pode levá-lo a um programa de trabalho mais rápido.

Agora, parece que você não tem o poder (ou talvez a confiança) de "recuar" com isso. Mas, mesmo assim, vale a pena fazer um pouco de barulho sobre isso (sem personalizá-lo), na esperança de que o codificador infrator faça um trabalho melhor ... da próxima vez.

Qual é a resposta apropriada para essa atitude?

Em última análise, chame a atenção da gerência ... a menos que você tenha o poder de consertar você mesmo. (Obviamente, isso não o tornará popular.)

Você estava certo, eles estavam errados:

• princípio quebrado de YAGNI
• princípio quebrado do KISS
• o código é totalmente testado? Se não, então não está feito

Qual é a resposta apropriada para essa atitude?

Faça a revisão correta do código. Se eles se recusarem a implementar as alterações sugeridas sem um motivo, pare de desperdiçar seu tempo analisando um código. Você também pode encaminhar o problema para o chefe deles .

Uma ação que nossa equipe tomou, que melhorou drasticamente a situação nesses casos, foi a mudança para conjuntos de alterações muito menores .

Em vez de trabalhar em uma tarefa por um dia ou mais e depois fazer uma revisão de código (grande), tentamos fazer check-in com muito mais frequência (até 10 vezes por dia). É claro que isso também tem algumas desvantagens, por exemplo, o revisor precisa ser muito responsivo, o que diminui sua própria produção (devido a interrupções frequentes).

A vantagem é que os problemas são detectados e podem ser resolvidos mais cedo, antes que uma grande quantidade de trabalho da maneira errada seja feita.

Você deve se concentrar na causa raiz do problema:

1. A educação dos programadores se concentra no aumento da complexidade dada aos programadores. A capacidade de fazer isso foi testada pela escola. Assim, muitos programadores pensam que, se implementarem uma solução simples, não farão seu trabalho corretamente.
2. Se o programador segue o mesmo padrão que ele fez centenas de vezes enquanto estava na universidade, é assim que os programadores estão pensando - mais complexidade é mais desafiadora e, portanto, melhor.
3. Então, para corrigir isso, você precisará manter uma separação estrita dos requisitos da sua empresa em relação à complexidade, em comparação com o que normalmente é exigido na educação do programador. Um bom plano é uma regra como "o nível mais alto de complexidade deve ser reservado apenas para tarefas projetadas para melhorar suas habilidades - e não deve ser usado no código de produção".
4. Para muitos programadores, será uma surpresa que eles não tenham permissão para fazer seus projetos mais loucos no importante ambiente de código de produção. Reserve tempo para os programadores fazerem projetos experimentais e mantenha toda a complexidade desse lado da cerca.

(na revisão de código, já é tarde para alterá-lo)

Não sei nada que funcione após o código ser escrito.

Antes de o código ser escrito, as pessoas podem discutir maneiras alternativas de fazer isso. A chave é contribuir com idéias uma para a outra, portanto, esperamos que uma razoável seja escolhida.

Há outra abordagem que trabalha com os contratados - contratos de preço fixo. Quanto mais simples a solução, mais $$ o programador mantém.

Você não pode consertar o mundo.

Você não pode nem consertar todo o código do seu projeto. Você provavelmente não pode consertar as práticas de desenvolvimento em seu projeto, pelo menos não este mês.

Infelizmente, o que você está enfrentando na revisão de código é muito comum. Eu trabalhei em algumas organizações em que me encontrei analisando 100 linhas de código que poderiam ter sido escritas em dez e obtive a mesma resposta que você: "Já está escrito e testado" ou "Estamos procurando por bugs, não um redesenho ".

É fato que alguns de seus colegas não podem programar tão bem quanto você. Alguns deles podem ser muito ruins nisso. Não se preocupe com isso. Algumas classes com más implementações não derrubarão o projeto. Em vez disso, concentre-se nas partes do trabalho que afetarão os outros. Os testes de unidade são adequados (se você os tiver)? A interface é utilizável? Está documentado?

Se a interface para o código incorreto estiver correta, não se preocupe até que você precise mantê-lo e, em seguida , reescreva-o. Se alguém reclamar, basta chamá-lo de refatoração. Se eles ainda reclamarem, procure uma posição em uma organização mais sofisticada.

Deve haver uma política padrão no projeto que controle os procedimentos e ferramentas de verificação da qualidade da entrega utilizados.

As pessoas devem saber o que devem fazer e quais ferramentas são aceitas para uso neste projeto.

Se você ainda não fez isso, organize seus pensamentos e faça-o.

A revisão de código deve ter uma lista de verificação de itens padrão. Se você obtiver "já está pronto" e não estiver, então pessoalmente, eu não gostaria de ser responsável pelo trabalho desse desenvolvedor como gerente de projeto ou desenvolvedor sênior. Essa atitude não deve ser tolerada. Eu posso entender discutindo sobre como fazer algo ou mesmo tudo, mas uma vez que uma solução seja aceita, a mentira não deve ser tolerada e isso deve ser claramente indicado.

Sua loja precisa aplicar algumas metodologias de design.

• Os requisitos precisam ser definidos claramente.
• Você precisa desenvolver casos de uso que suportem os requisitos.
• Você precisa especificar as funções necessárias para implementar os casos de uso.
• Você precisa especificar quaisquer requisitos não funcionais (tempos de resposta, disponibilidade etc.)
• Você precisa de um RTM (Requiements Tracabilty Matrix) para mapear cada função do sistema de volta a um caso de uso e a um requisito real.
• Elimine qualquer função que não suporte um requisito real.
• Finalmente, em sua revisão de código, sinalize qualquer código que não implemente ou suporte diretamente as funções definidas.

Provavelmente não é muito complicado, porque isso faz a maioria das pessoas se sentir mal depois. Suponho que, quando isso acontece, já tenha sido escrito muito código sem falar uma palavra sobre isso. (Por que é isso? Porque essa pessoa tem autoridade suficiente para que seu código não precise ser revisado na realidade?)

Caso contrário, acho que tornar a revisão de código menos formal, mas mais frequente. E antes de escrever módulos grandes, talvez você deva discutir rapidamente qual abordagem adotar.

Dizer "isso é muito complicado" não leva a lugar algum.

É lamentável, mas as Revisões de Código são, muitas vezes, mais para o futuro do que para o presente. Especialmente em um ambiente corporativo / corporativo, o código enviado é sempre mais valioso que o código não enviado.

Obviamente, isso depende de quando a revisão do código for concluída. Se fizer parte do processo de desenvolvimento, você poderá obter alguns benefícios agora. Mas se o CR for tratado como um post-mortem, é melhor você apontar o que poderia ser feito melhor no futuro. No seu caso (como outros já disseram), aponte o YAGNI e o KISS em geral, e talvez algumas das áreas específicas em que esses princípios possam ser aplicados.

O que significa excessivamente complicado? Você faz uma declaração ambígua e recebe uma resposta ambígua / insatisfatória. O que é excessivamente complicado para uma pessoa é perfeito para outra.

O objetivo de uma revisão é apontar problemas e erros específicos, para não dizer que você não gosta, que é o que a afirmação "excessivamente complexa" implica.

Se você vir um problema (excessivamente complicado), diga algo mais concreto como:

• Alterar a parte X para Y não simplifica o código ou facilita a compreensão?
• Não entendo o que você está fazendo aqui na parte X, acho que você estava tentando fazer isso. Apresente uma maneira mais limpa de fazê-lo.
• Como você testou isso? Você testou isso? Se for excessivamente complicado, isso geralmente levará a olhares em branco. A solicitação de testes geralmente faz com que a pessoa simplifique seu código automaticamente quando não conseguiu descobrir como testar o código original.
• Parece haver um erro aqui, alterar o código para isso resolveria o problema.

Qualquer um pode apontar problemas, especialmente os ambíguos. Há um subconjunto muito menor que pode apresentar soluções. Os comentários de sua revisão devem ser tão específicos quanto possível. Dizer que algo é excessivamente complexo não significa muito, pode até fazer com que outras pessoas pensem que VOCÊ é incompetente por não conseguir entender o código. Lembre-se de que a maioria dos desenvolvedores não tem idéia da diferença entre um design bom ou ruim.

Às vezes, vale a pena, como grupo, focar-se em alguns dos princípios "Ágeis" - eles podem ajudar um grupo ou indivíduo que parece estar um pouco fora do curso.

Focar não precisa significar uma grande reformulação de sua equipe, mas todos devem sentar-se e discutir quais práticas são mais importantes para você como equipe. Eu sugiro discutir pelo menos estes (e provavelmente muito mais):

• Faça a coisa mais simples que poderia funcionar?
• Você não precisará disso (está resolvendo problemas que não estavam na especificação)
• Escreva o teste antes da codificação (ajuda a focar seu código)
• Não se repita

Também revisões ocasionais (semanais?) Do que funciona, do que não funciona e do que ainda é necessário podem ser realmente úteis ... Se nada mais, por que não comprometer-se com uma hora por semana para discutir os valores e práticas da equipe?

Escalada, se você tiver um gerente com espírito técnico. Isso soa como um hábito que precisa ser quebrado.

Se o código não for construído de acordo com as especificações, então, por definição, deve falhar na revisão do código. Eu não entendo o conceito de "bem, fizemos algo que ninguém pediu, e não está funcionando, então vamos deixá-lo lá em vez de fazer algo que alguém pediu que funcione".

Este é um mau hábito para qualquer desenvolvedor entrar. Se ele / ela estava trabalhando com uma especificação de design, não combiná-la sem um bom motivo é um não-não.

Uma palavra: ágil

Certamente não resolve tudo. Mas reinando em suas iterações (1 a 2 semanas, por exemplo), limitando o trabalho em andamento e aproveitando o planejamento / revisão do sprint, você deve evitar esses erros do tipo cascata. Você precisa de uma melhor visibilidade do que está realmente sendo feito - enquanto está sendo feito.

Para um desenvolvimento normal baseado em projetos, recomendo adotar uma abordagem Scrum . Para ambientes de desenvolvimento / integração contínuos, e especialmente se você tiver muitos desenvolvedores trabalhando no mesmo projeto ou em projetos relacionados, considere incorporar elementos do Kanban . Outra abordagem eficaz é aproveitar a programação em pares , uma prática definida da programação Extreme .

Sua situação não é única. E mesmo com equipes pequenas, o processo pode ajudar bastante a evitar a situação em que você está agora. Com visibilidade adequada e uma lista de pendências razoavelmente preparada, perguntas como essas se tornam decisões de planejamento de sprint - poupando você do gerenciamento de dívidas técnicas .

O que eu disse no passado é "esse código é complexo e não estou confiante no que está tentando fazer. É possível simplificá-lo ou escrevê-lo com mais clareza?"

Você codifica após excluir / reverter o código: "Ops, seu código foi removido. Por favor, reescreva-o. Como você já o escreveu uma vez, precisará de menos de vinte minutos para fornecer APENAS o código exigido pela especificação.

"Minha próxima revisão é em 20 minutos.

"Dia bom."

NÃO aceite argumentos!

Feito, IMHO

Chris