Como devo corrigir o código de um programador menos experiente?

19

Um pouco de experiência: sou um dos dois programadores do nosso departamento de 10 pessoas (o resto são artistas e administração). Nós dois fazemos toda a codificação necessária para fazer as coisas fluírem bem e desenvolvemos todos os projetos que surgirem. Venho programando há cerca de 4 anos, onde este é seu primeiro trabalho "real" (como ele diz). Geralmente, trabalhamos em diferentes projetos a qualquer momento.

Há alguns meses, desenvolvi um conjunto (de maneira alguma perfeito) de classes que seriam usadas em um projeto posterior. Uma grande parte desse projeto foi delegada a ele (por motivos de cobrança) para projetar e programar uma interface GUI. Como ele era novo, ajudei um pouco no design e pedi ajuda se ele precisava disso com o resto. Ele terminou a interface há algumas semanas, e demonstrou que ela funcionava, embora um pouco lenta.

A próxima parte desse projeto começou, na qual estou trabalhando. Abri a interface para começar com as próximas etapas e imediatamente me deparei com problemas (um pouco lento era um pouco de eufemismo, erros em ações comuns etc.). Procurei no código alguns problemas e estou encontrando O(n^n)chamadas que deveriam ser O(n), digite suposições sem verificação de erro (está em Python), referências à GUI adicionada ao código original e assim por diante.

Agora, eu definitivamente gostaria de ensinar a ele o que estava errado e como corrigi-lo, mas ele já passou para o seu próximo projeto, e isso foi há algumas semanas atrás. Receio que eu diga "Volte e faça o que é certo!" (com ajuda, é claro) é muito duro, e ainda temos outros projetos a serem feitos nesse meio tempo. Devo apenas corrigir o código por enquanto e tentar pegar as coisas no futuro?

code-reviews bug

— TorelTwiddler
fonte

4

No futuro, existe a possibilidade de concordar com as diretrizes de codificação, que impediriam erros como você descreveu?

— Benni 10/10

5

É bom que você não esteja correndo imediatamente para a gerência e contando a ele. Algumas empresas são orientadas pela culpa. À medida que você verifica as correções, encontre uma maneira de agrupá-las e depois faça com que esse cara as veja mais tarde. Por outro lado, mesmo um recém-formado não deve codificar nada que seja, a O(n^n)menos que não exista outra maneira. Se o fizerem, provavelmente obtiveram um C em algoritmos ou não o aceitaram ou tiveram um professor de baixa qualidade. Aproveitar algum tipo de ferramenta para ajudar a encontrar problemas comuns seria bom. Talvez como a próxima tarefa esse cara possa escrever alguns testes de desempenho?

— Job

Um O (n ^ n) sem documentação sobre o motivo simplesmente errado, ponto final. Se você realmente precisa fazer isso, é melhor explicar os comentários.

— Loren Pechtel 10/10

Estava prestes a escrever que "ei, O (n * n) não é tão ruim assim, muitas aplicações exigem ..." mas então percebi que não era um sinal de multiplicação, mas um assassino ^!

— Max

O (n ^ n) pode ser por uma magnitude mais rápido que O (n) se O (n) tiver uma constante enorme e n for pequeno. codinghorror.com/blog/2007/09/… Novamente, n ^ n é extremo: D

— Coder

33

Parece que instituir algum tipo de política de revisão de código pode ser benéfico em vários níveis. Alguns benefícios imediatos:

Você pode influenciar diretamente a qualidade do código dele antes que o código seja confirmado, mantendo assim a qualidade da base do código alta
Impede que você cometa erros semelhantes que outro par de olhos pode pegar
Na ausência de diretrizes de codificação, as revisões naturalmente levam à consistência no estilo de codificação
Compartilhamento de conhecimento. Se houver apenas dois de vocês e um for atropelado por um ônibus ...

Agora, quando você prosseguir e começar a limpar o código dele, use-o como exercício de ensino ao procurar uma revisão desse código. Você revisará suas coisas e ele poderá aprender a fazê-lo melhor da próxima vez.

— nithins
fonte

3

A revisão do código +1 é uma ótima maneira de fazer isso. Eu sugeriria que o escrevesse mais ao longo das linhas de "Você se importaria de dar uma olhada nas alterações que fiz para garantir que não perdi algo" em vez de "Aqui estão as maneiras pelas quais eu melhorei seu código".

— 101311 Steve Jackson

1

+1 Eu diria que a revisão de código é muito melhor do que as "diretrizes de codificação da regra de ouro". Muitas coisas nunca são boas.

— Max

Eu realmente gosto dessa idéia, obrigado. Agora vou ter que pesquisar um pouco sobre boas maneiras de fazer revisões de código!

— TorelTwiddler

1

Na verdade, há um artigo bom e divertido com alguns conceitos básicos disponíveis em mumak.net/stuff/your-code-sucks.html . É principalmente sobre técnicas comportamentais para conduzir revisões de maneira construtiva, o que é extremamente importante para revisões bem-sucedidas.

— Nithins 12/10

@ TorelTwiddler, lembre-se de que as revisões de código são para aprendizado, não para culpar. Saliente as coisas que ele fez bem; portanto, ele sabe que elas são boas ao mesmo tempo em que sugere maneiras de melhorar.

— CaffGeek 28/10

5

Nunca, nunca, nunca corrige seu código; caso contrário, eles não aprenderão nada além de cometer erros, você os pegará e os corrigirá. A tarefa não é concluída até que seja concluída . Tive muita sorte quando comecei profissional e meu supervisor direto checou tudo o que cometi, e se houvesse uma solução melhor ou se eu tivesse cometido um erro bobo, me diria, o que significava que minhas habilidades melhoravam, o que significava que eu melhorava mais rápido e desenvolvia uma pele mais dura.

Deixá-lo deslizar gerará maus hábitos, a correção agora fará com que eles lidem melhor com as críticas e tripliquem a verificação antes de afirmar que estão concluídas.

— Nicholas Smith
fonte

2

Podemos inferir que o projeto "funciona" e foi realizado em um período de tempo razoável (embora com alguns problemas de design flagrantes, mas corrigíveis)? Nesse caso, está em uma forma muito melhor do que muitos projetos que já vi ao longo dos anos.

Acho que mais comunicação ajudaria sua equipe - e isso poderia ser feito com a revisão regular do código.

É bom que você seja sensível a ser "muito severo" e acho que você deve ter em mente que a revisão de código não precisa ser uma experiência desmoralizadora, onde os jovens são interrogados e examinados. Também pode ser uma maneira de os desenvolvedores seniores demonstrarem boas práticas e para que todos confiem um no outro, sendo educados e amigáveis, mesmo na presença de "erros".

As pessoas aprendem bem quando vêem como são realmente as coisas boas. Isso é melhor do que apontar sistematicamente todas as pequenas falhas. O (n ^ n), no entanto, deve ser suave e construtivamente apontado.

— Angelo
fonte

0

Compartilhe seu conhecimento.

Eu ofereceria a ele ajuda em seu novo projeto em troca de algum ensino, de um sénior a um júnior.

Por que não emparelhar a programação nos dois projetos?

— mouviciel
fonte