Como dizer ao seu chefe que o estilo de programação dele é realmente ruim? [duplicado]

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-lhe a maneira como você o codifica e diga por que você o 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.

Promova o uso de ferramentas de análise estática automatizada e verificação de estilo, como linters e localizadores de erros (em qualquer idioma que você use). Se todos na empresa começarem a usá-los (por exemplo, eles são obrigatórios antes dos checkins), ele não será escolhido.

A razão pela qual estou sugerindo isso é que:

1) As pessoas geralmente preferem censurar ferramentas automatizadas do que seus colegas de trabalho ou subordinados.

2) Essas ferramentas abrangem muitos problemas que podem ser considerados de estilo ruim.

3) Você poderia ajustar as regras por trás do seu estilo ruim além do que está embutido na ferramenta. Por exemplo, imponha um certo estilo de variável.

4) Algumas pessoas percebem que seu código não é tão bom e realmente começam a prestar mais atenção mesmo em coisas que não são cobertas pelos linters.

Algumas empresas bem respeitadas (como o meu próprio empregador) forçam um cheque de fiapos antes do check-in. A visão é que o estilo ruim é a dívida técnica. Você sempre pode usar o "Bem, se X e Y e Z estão fazendo isso, provavelmente é uma boa idéia".

Eu acho que você definitivamente não deveria dizer nada assim diretamente . Tais afirmações podem facilmente causar uma reação defensiva nele, o que quase certamente acabará com qualquer possibilidade para ele aprender, e pode até mesmo causar problemas para você.

Em vez disso, procure (e até tente criar) oportunidades para debater casualmente discutir questões de estilo e idioma de codificação e mencioná-lo as "melhores práticas" que você conhece. Naturalmente, você deve garantir primeiro que o que você sugere é realmente uma prática recomendada amplamente aceita e aceita.

Além disso, tente discutir os mesmos problemas com outros membros da equipe também. É importante compreender o (falado ou não) "consenso" dentro da equipe em relação ao estilo de codificação e qualidade . (Se todos os outros escreverem código limpo e de alta qualidade, você terá um caso muito diferente do que o resto do grupo consiste em programadores reais que orgulhosamente escrevem programas FORTRAN em qualquer idioma.) Eles também podem contar mais sobre o histórico do projeto. e o estilo de codificação do seu chefe, que ajuda você a direcionar melhor seus esforços.

Outra maneira é pedir a ele para pedir Java Efetivo para você, porque você acha que precisa tornar-se um programador melhor. (Caso você ainda não tenha lido, você de fato precisa.) Então você pode falar com ele sobre as maravilhosas soluções e práticas deste livro.

Se ele está aberto para melhorar a si mesmo, ele vai pegar suas sugestões (e o livro). Se não, você pode se retirar sem perder a face e forçar o relacionamento.

Se o seu chefe é legal, pergunte a ele: "Cara, WTF?"

Em todos os casos em que você acha que "o meu é melhor", nunca diga a alguém que você acha isso, mostre-o.

Eu repito, SHOW, não conte.

Você sabe que dizer sobre ações, mais alto, palavras ... é verdade.

Qual a posição do seu chefe? Ele é um desenvolvedor, líder de tecnologia? Quantos outros desenvolvedores existem na empresa? A empresa possui padrões de codificação e revisões de código?

É improvável que você faça com que seu chefe mude os maus hábitos dele (IMHO), mas você pode usar um grupo de colegas ou os padrões da empresa para influenciá-lo. Se o código dele seguir seguir os padrões e os pares forem todos iguais, suas opções serão limitadas.

Aqui está minha recomendação:

• Defina bem o seu caso.
• Se o seu gerente não for receptivo * ao seu ponto de vista, e você achar que está certo, procure pastos mais verdes e não dê desculpas.

Eu recomendo que você busque pastos mais verdes por três motivos:

1. A longo prazo, é prejudicial para a carreira de um programador perpetuar más práticas. A perpetuação de más práticas gera maus hábitos.
2. Uma loja de programação que não é receptiva a pontos de vista alternativos sufoca a imaginação.
3. Quando você sabe que está perpetuando más práticas e sua equipe não está receptiva a pontos de vista alternativos, sua moral está fadada a afundar, e isso tornará sua vida miserável. Então saia o mais rápido possível.

* Distinção importante: Esperar que alguém seja receptivo ao seu ponto de vista não é o mesmo que esperar que alguém produza seu ponto de vista. Eu sempre aprecio as pessoas que consideram meu ponto de vista, ao passo que tenho pouco respeito por pessoas que são suaves e que se submetem ao meu ponto de vista sem razão ou evidência suficiente para fazê-lo.

Ações falam mais alto que palavras:

Uma abordagem diferente:

• Você precisa liderar por exemplo.
• Verifique se os projetos que você faz são os melhores que você pode fazer.
• Você precisa se destacar em termos de desempenho, menos bugs, etc.
• Uma vez que você possa demonstrar que sua abordagem e estilo são melhores do que seu chefe, a menos que seja muito arrogante, acho que naturalmente essa pessoa seguirá o que for melhor.

Eu apenas daria a ele Ponteiros em pequenas doses, quando você ver ele fazendo algo "ruim"

"Hmm, confira esta abordagem para {apontar para a tela}, gosto de fazer assim por causa do blá blá blá."

Faça isso Não mais do que uma vez a cada dois dias. Ele não aceita a sua sugestão, nunca mais a menciona (por algumas semanas). Alguns vão ficar. E ele vai lentamente melhorar.

Peça ao seu chefe que se compare com outra maneira que você aprendeu. Ele pode ter um motivo legítimo. Você não vai saber até que você pergunte. Pode haver algum padrão antigo de codificação que ela esteja tentando manter ou ela simplesmente não se importará. Não dê qualquer indicação de que o chefe está automaticamente errado. Ah, e faça isso em particular. Isto é para seus propósitos educacionais.

Depende. Se o código que você está revisando for um código totalmente novo, peça para ter revisões de código, pois isso ajudará a "aumentar a velocidade" e mostrará que você está interessado em aprender. O chefe pode achar isso útil, pois demonstrará a ele que você está procurando fazer a coisa certa. Se este for o código antigo que você encontrou por acaso e for forçado a mantê-lo, faça questão de fazer uma refatoração lenta. Uma declaração de tipo aqui e ali enquanto ainda está completando a tarefa. Agora, o problema aqui é que o String YesOrNo pode assumir outros valores como Maybe , o que pode levar a códigos quebrados se você não for cuidadoso.

Tente mostrar-lhe pequenos pedaços de código de amostra de sites / locais / livros respeitáveis, etc., que realizam coisas semelhantes.

A primeira coisa que eu faria é descobrir como ele reage aos críticos. Se eu fosse o chefe - bem, eu não faria nada de errado, faria? - Eu preferiria ser dito na minha cara, tudo de uma vez, mas de uma forma respeitosa. Dependendo do temperamento e da cultura, seu chefe pode ser diferente.

Mas a maioria deles precisa de algum respeito. Uma boa maneira de mostrar que você o respeita é o que foi sugerido antes: Você explica o que quer dizer, mas deixe a decisão para ele: "Essa é a minha razão, mas talvez eu tenha supervisionado alguma coisa. Depois da minha explicação:"

if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null

"o que você sugere?"

E você pode perguntar a uma metaquestão antes: "Sr. X, se eu encontrei algo em seu código, o que é comumente relatado como uma prática improvável - como devo reportar para você? Tudo de uma vez, ou passo a passo? Ou devo evitar mencioná-lo a todo custo? Melhore silenciosamente o código? "

Dependeria da minha relação com a formulação que eu escolheria e qual abordagem.

Seu chefe não sabe programar e não deve fazê-lo. Minha experiência me disse que assumir que alguém chamado chefe também é mais experiente ou melhor do que você é uma falácia. Ele pode ser melhor em outras coisas, mas o ponto de gerenciamento e hierarquia é delegar as coisas à pessoa mais apropriada. Um chefe é alguém que teve a chance de começar um negócio, ou entrou em uma posição de gerência, eventualmente, por suas habilidades gerenciais, não necessariamente por suas habilidades de programação.

Eu já tive um chefe que fingiu que eu instalei um computador enquanto estava conectado a um gerador elétrico a gasolina, porque ele alegou que hackers podiam entrar pela rede elétrica enquanto a máquina ainda estava desprotegida. Eu parei imediatamente. Eu aprendi uma lição valiosa na época: o chefe nem sempre está certo, e às vezes desistir é a única resposta valiosa.

Então, para voltar ao seu caso, você pode ter um caso em que apenas procurar outro emprego (sim, crise, yadda yadda ... eu sei) pode ser o melhor remédio. Não perca seu precioso tempo.

Eu vivo na indústria onde não consigo encontrar meus erros de chefe. Então, melhor, eu iria gerar os casos em que os erros aparecem no código e deixá-lo ver o erro, do que eu vou sugerir-lhe as mudanças necessárias e sobre o possível motivo [no seu caso, você tem certeza sobre o motivo. D] do erro. Qualquer desenvolvedor, seja bom ou ruim, não aceitará o erro até que ele veja o erro.

Eu já tive um grande problema com o estilo dos chefes.

Existem dois problemas com isso. Primeiro, acho que nunca disse isso na cara dele, mas imagino que ele soubesse. Ele ficou profissional, eu não, IOW.

Dos três pontos da questão, os diacríticos não são estranhos para todos, e embora eu não usasse esse loop, fico irritado com a família C ... enquanto sintaxe e como (não se encaixa com o meu estilo de recuo, então talvez eu possa ver de onde vem.

Até mesmo a coisa booleana pode ter uma explicação em termos de hábitos trazidos de outra língua (o que não é uma justificativa, é claro).

Eu acho que isso pode funcionar -

1. Peça ao seu gerente que revise seu código, que não apresenta nenhum dos erros que ele cometeu.
2. Em seguida, veja se o seu gerente pergunta por que não "maneira dele"
3. Se ele fizer essa pergunta, você poderá perguntar por que esse seria o melhor caminho.

Desta forma, você fica sabendo porque ele acha que o caminho está correto.

Eu já estive lá antes. Eu fui direto da Uni e depois de cerca de um ano trabalhando para um cara, percebi que sabia muito mais do que ele sobre programação, mas era da sua conta, e ele deu as cartas - e só não queria ofendê-lo de qualquer forma! Decidi que a melhor maneira de contornar isso era discutir os benefícios de ter convenções comuns de codificação em toda a empresa que todos devíamos adotar e ver como ele reagiu. Surpreendentemente, ele achou que era uma ótima idéia, e me pediu para elaborar uma lista de padrões, que nós dois revisamos juntos, e finalizamos, etc.

O importante aqui é que você é apenas um falível como ele é, e só porque alguns de seus modos são estranhos / errados, alguns deles serão melhores que os seus.

Da minha experiência pessoal, no entanto, não funcionou. Apesar de passar dois dias pesquisando e compilando um ótimo documento de padrões e convenções de codificação - ele já estava definido em seus caminhos, não via realmente o benefício em codificar convenções ou escrever código que colocasse menos pressão sobre o servidor - que fazia nossos trabalhos mais rápido e mais fácil, e cortar custos.

No final, saí para encontrar um lugar que levasse o desenvolvimento um pouco mais a sério. Não foi de todo ruim, já que a pesquisa que fiz em convenções de codificação realmente ajuda até hoje.