Como abordo um colega de trabalho sobre a qualidade de seu código? [duplicado]

Question

Como abordo um colega de trabalho sobre a qualidade de seu código? [duplicado]

#1 resposta do (44 votos)
#2 resposta do (14 votos)
#3 resposta do (11 votos)
#4 resposta do (11 votos)
#5 resposta do (11 votos)
#6 resposta do (3 votos)
#7 resposta do (3 votos)
#8 resposta do (1 votos)
#9 resposta do (1 votos)
#10 resposta do (1 votos)
#11 resposta do (0 votos)

47

Eu trabalho em um novo empreendimento em uma grande empresa de software empresarial (mais de 3000 programadores). No meu grupo, temos um monte de projetos e as pessoas geralmente trabalham em vários projetos ao longo de um ano.

Acabei de começar a trabalhar em um projeto que foi mantido anteriormente por um amigo meu (consultor que está conosco há mais de 3 anos) para adicionar alguns recursos. Eu entrei no código e a qualidade era realmente muito pobre. Seja no frontend da interface do usuário ou no back-end de serviços, o código simplesmente não era recuado, havia centenas de linhas comentadas sem motivo aparente, a documentação era basicamente inexistente, os padrões de codificação não eram aplicados consistentemente (por exemplo, mixagem camelCase e under_scored_variables ), os nomes das variáveis eram ininteligíveis, as escolhas de tipos de dados estavam erradas, etc. etc.

Sou muito mais uma pessoa que não é de confronto, então não quero atacar meu colega de trabalho, mas também não quero apenas ir ao meu chefe e reclamar do seu desempenho. Quais são os tipos de coisas que eu poderia dizer para mencionar educadamente que o código é mal estruturado?

EDITAR:

Eu quero esclarecer que, embora eu entenda que há um elemento "Todo mundo é um código ruim" para todos os programadores, quando vejo algo assim (os nomes são escolhidos propositalmente e alguns detalhes foram omitidos / alterados neste exemplo):

public void doCalculate(Object argument) {
  if (argument instanceof String) {
    String argument2 = (String) argument;
    if (argument2 == "DataBase") {
      // do something
    } else {
      long argument3;
      try {
        argument3 = Long.parseLong(argument2);
      } catch (Exception e) {
        argument3 = -1;
      }
      // do something completely unrelated
    }
  }
}

Eu acho que é objetivamente justo dizer que isso não é não uma boa ideia. Além disso, eu não estou lidando com um novato aqui (estou apenas codificando 3 anos agora). Ele tem talvez 20 anos de experiência em mim. O conselho que vocês deram até agora é ótimo; só quero ter certeza de que não estamos falando de uma "linha tênue" aqui.

code-quality communication

por daveslab 11.01.2012 / 18:27

fonte

11 respostas

Tags code-quality communication

Usando getters públicos em vez de privados Como se livrar do cubículo? [fechadas]

score 44 · Answer 1

Peça-lhe para explicar seu código para você

Diga a ele que você nunca viu o X programado dessa forma antes, e pergunte por que ele o codifica dessa maneira. Mostre a ele como você codifica e diga por que você faz dessa maneira (melhores práticas, melhor desempenho, menor chance de erros, mais fácil para outros programadores lerem / manterem, etc).

Certifique-se de preparar todos os seus argumentos com antecedência e concentre-se no motivo pelo qual seu método é melhor, em vez de saber por que o método dele é pior. Depois, veja se ele ainda suporta seu método sobre o seu.

Se ele estiver aberto a melhorias, provavelmente mudará sua maneira de codificar. Se ele ainda preferir usar seu estilo de codificação sobre o seu, provavelmente você não mudará a opinião dele.

Esta é exatamente a mesma resposta que eu dei para a pergunta Como dizer ao seu chefe que seu estilo de programação é realmente ruim? . Eu originalmente votei para fechar esta questão como uma duplicata, porém muitas pessoas pensaram que era diferente o suficiente para warrent reabri-lo. Minha resposta ainda é a mesma, independentemente de você estar conversando com um chefe ou um colega de trabalho.

score 14 · Answer 2

E se, em vez de abordá-lo pessoalmente, você abordar a equipe e propor de forma completamente neutra que a "equipe" crie um padrão / diretrizes de codificação como forma de os membros da equipe trabalharem mais eficientemente com o código da outra.

Quando isso estiver correto, acho que o código com o qual você está preocupado chegará ao topo sozinho.

As revisões de código de peer também ajudam nessa área. Os padrões de codificação não têm muito benefício se ninguém olhar para o código. Mas as revisões de código de peer têm muitos outros benefícios, uma transferência de conhecimento primária, então você deve pressionar para apresentá-las nos dois casos.

Suponho que, mesmo que você tenha mais de 3000 engenheiros, vocês têm subequipes MUITO menores que trabalham juntos como uma unidade

score 11 · Answer 3

Primeiro, todo mundo acha que o código de outras pessoas é uma droga.

Segundo, talvez ele tenha herdado o código de alguém / algum outro lugar OU este foi um protótipo que nunca pretendeu ser o código usado para o projeto atual, mas é claro que acabou sendo usado.

Em terceiro lugar, talvez seu código realmente seja ruim, mas é seu trabalho falar mal de desenvolvedores anteriores? A menos que você tenha criado uma reputação que imponha respeito em torno da empresa, suspeito que, se você reclamar sobre o código da outra pessoa, é você que acabará ficando mal e não será seu amigo. O tempo para dar às pessoas pesar sobre o seu código é quando as revisões de código são mantidas. Pelo menos então faz parte das responsabilidades do seu trabalho.

Eu recomendo que, se você não gostar do código dele, conserte-o ao seu gosto. Então o próximo desenvolvedor virá e reclamará do seu código e provavelmente o alterará de volta para ser mais parecido com o que seu amigo fez.

score 11 · Answer 4

Seu colega de trabalho provavelmente não é a causa raiz do problema em sua empresa. A razão pela qual um código de baixa qualidade entra em produção é a falta de padrões de codificação automaticamente mensuráveis em sua empresa. Neste caso, a luz solar é o melhor remédio.

Você deve conversar com seu líder técnico sobre a implementação de métricas automatizadas de qualidade de código-fonte em seu grupo. O sistema deve funcionar pelo menos uma vez por semana, enviar um e-mail para todos da equipe uma lista arquivo por arquivo de violações padrão de codificação e enviar um resumo executivo para seu chefe. O resumo deve conter o número de violações por projeto.

Na minha experiência, qualquer coisa que seja medida e informada a um chefe melhora com o tempo.

score 11 · Answer 5

...the code simply wasn't indented, there were hundreds of lines commented out for no apparent reason, documentation was basically non-existent, coding standards weren't applied consistently (e.g. mixing camelCase and under_scored_variables), variable names were unintelligible, datatype choices were wrong...

Tanto quanto eu posso dizer, as correspondências acima de # 12, # 9, # 5, # 2 e provavelmente # 7 de Top 12 coisas que podem ser ouvidas se você tivesse um programador Klingon (arquivo) ~~[link original ]~~ :

12. Specifications are for the weak and timid!
11. This machine is a piece of GAGH! I need dual Pentium processors if I am to do battle with this code!
10. You cannot really appreciate Dilbert unless you've read it in the original Klingon.
9. Indentation?! - I will show you how to indent when I indent your skull!
8. What is this talk of 'release'? Klingons do not make software 'releases.' Our software 'escapes,' leaving a bloody trail of designers and quality assurance people in its wake.
7. Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
6. Debugging? Klingons do not debug. Our software does not coddle the weak.
5. I have challenged the entire quality assurance team to a Bat-Leth contest. They will not concern us again.
4. A TRUE Klingon Warrior does not comment his code!
3. By filing this PTR you have challenged the honor of my family. Prepare to die!
2. You question the worthiness of my code? I should kill you where you stand!
1. Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

tlhab 'oS' Iw HoHwI 'So' batlh

É bem provável que a única maneira de evitar o confronto seja um drive de dobra em outro quadrante espacial .

score 3 · Answer 6

Veja um pouco do que estava acontecendo dentro da empresa e da equipe quando este projeto foi escrito. Peça a este colaborador algum feedback sobre como ele pensou que o projeto foi. O estilo dele mudou? Se tivesse a oportunidade, o que ele faria de diferente?

Ele pode concordar com seus padrões, mas não teve o privilégio de aplicá-los durante a criação deste aplicativo ou simplesmente não sabia sobre eles.

O seu grupo não tem normas ou política de revisão de código ou um problema sério com a aplicação. Você pode estar mantendo uma opinião de um.

score 3 · Answer 7

Eu admito, às vezes sou esse cara. Quando eu for, terei minhas razões, geralmente restrições de tempo, projetos de marcha mortal, instruções como "agora, não perfeito" etc. Muito raramente, é por causa de um dia ruim. Fico feliz em ser questionado sobre quaisquer problemas, isso me dá a chance de me tornar um desenvolvedor melhor. Desde que: a) Você é sensato sobre o que será mudado (não está muito quebrado, concorde em não consertar), e b) você não é um ditador maluco que acredita que o seu caminho é o único caminho.

Para se aproximar de mim, não pergunte "Porquê". Por que é uma palavra de luta, um desafio e, em última análise, é destrutiva. Se você se encontrar usando muito, mude para I. "Por que você chamou este x" torna-se, "eu teria usado índice, é mais descritivo que x."

A melhor maneira é declarar o que você faria ou preferiria. Explique que o que você está vendo não atende a certos padrões e gostaria de vê-lo melhorado. Meu palpite é que 99% do tempo, a resposta será "eu também, mas ........"

score 1 · Answer 8

É improvável que o autor do código volte para corrigir seu código para você por pura boa vontade ou que seu empregador o pague para fazer isso. Então, de qualquer forma, você está rindo.

Se você acredita que a bagunça em que o código está terá um efeito prejudicial em seu desempenho enquanto estiver trabalhando nele, lembre-se de salvar um backup do código original em algum lugar para que você possa provar que estava uma bagunça foi entregue a você. Então, se seu empregador te confrontar mais tarde sobre o seu mau desempenho, você pode cobrir sua bunda.

Mesmo assim, pode parecer para o seu empregador uma desculpa, então tente evitar que isso aconteça, se puder.

score 1 · Answer 9

1

Pense no que é bom mencioná-lo que ele tem um estilo de codificação ruim faria você ou ele?

Talvez seja melhor tentar melhorar os procedimentos de controle de qualidade de sua empresa.

por 11.01.2012 / 18:35

fonte

score 1 · Answer 10

Você precisa descobrir duas coisas: qual é o seu objetivo? Como você gostaria de se aproximar?

Se o seu colega, com mais de 20 anos de programação, tiver uma mente realmente aberta, fale com ele e aponte exemplos específicos, diga por que eles pareciam errados e discutisse alternativas. Porque ele é muito, realmente de mente aberta e ansioso para aprender, ele vai ouvir, uma discussão vai acontecer, e ele vai entender seus pontos e ambos viverão felizes para sempre.

Na minha experiência, porém, o colega provavelmente está programando assim porque ele simplesmente não se importa com estilo. Pode ser porque ele está realmente no trabalho errado, ou pode ser porque, em mais de 20 anos de programação, ele nunca encontrou um motivo para se preocupar com isso - talvez seu código simplesmente funcione e ele siga em frente.

Se o último for o caso, você só vai desperdiçar seu tempo, e você pode ter um impacto em seu relacionamento se isso se transformar em uma discussão. Então, qual é o seu objetivo aqui?

Você quer que ele limpe o código dele para que você possa trabalhar com um código mais agradável? Você quer que ele aprenda e melhore? Você quer se sentir bem em ser um melhor programador? Você quer que seu chefe saiba que você é um programador melhor que ele?

O primeiro não vai acontecer e o terceiro já está estabelecido, embora você provavelmente queira que ele o reconheça também - bom amigo, figura paterna?

Se você realmente quer que ele aprenda e melhore, então descubra como gostaria de ser abordado na situação inversa e faça o mesmo. E descubra o que o incomodaria e certifique-se de não fazer isso.

O quarto é fácil: ou você quer um salário melhor, e então você exige isso apenas na próxima reunião de feedback (não importa o quão bom você é nesta indústria) ou você quer mais responsabilidade e então você continue fazendo um bom trabalho até conseguir.

score 0 · Answer 11

Sugira ao seu chefe que você está vendo algum código maluco e peça a ele para colocar todo o pessoal possível em alguns cursos de programação. Eu acho que ele deve estar ciente de que seus aplicativos estão sendo preenchidos com código de baixa qualidade.