Discordância com o líder do projeto sobre os padrões de codificação [fechado]

Então, eu estou trabalhando em um novo projeto junto com meu líder de projeto nos últimos 1 ano.

Inicialmente, tínhamos nossos próprios subprojetos que residiam em repositórios git separados, eu tive pouca interação com o código dele, então o cheiro do código não me incomodou. Cerca de seis meses depois, comecei a manter e adicionar recursos ao código dele, pois estava assumindo um papel maior no projeto.

Agora que sou o desenvolvedor líder dos dois subprojetos (equipe prestes a crescer; ele ainda está acima de mim), essas coisas me incomodam e eu queria cuidar deles, mas foi recusado:

1. Sem chaves, funções em maiúsculas, uso de aspas mistas (dupla e única com lógica oculta), sem usar ===, grandes classes com grandes funções. Bottom line, poderia ser melhor.
2. Confiança na opção do PHP para desativar avisos / avisos. O código está cheio de usos não verificados de variáveis ​​e chaves de matriz. Variáveis ​​são definidas dentro de ifs.

Argumentos para as duas questões acima:

1. Não querendo impor um estilo de codificação às pessoas.
2. Considerado como um recurso de linguagem, que se presta a um código mais curto / mais eficiente.

Acredito que algumas regras precisam ser adotadas e o código deve ser defensivo. Ofereci-me para usar as configurações padrão do PHPStorm para a formatação, usar chaves e uma convenção de nomenclatura aceita pela comunidade.

Quero alinhar os dois projetos para usar as mesmas diretrizes, pois são inseparáveis.

Estou errado? Eu imponho minhas preferências pessoais?

Se você pode defender com firmeza o motivo pelo qual o seu é melhor (e quais são os principais problemas do uso dele), acho que você não está impondo uma preferência pessoal, mas sim tentando definir um projeto para o sucesso.

Se ele pode argumentar mais forte por que o dele é melhor e que tipo de problemas impedirão que o seu não possa, então ele o supera.

A alta gerência decente deve ser capaz de ver o mérito disso, mas esses são os pontos com os quais eles se importarão (e devem): não se é mais fácil para os desenvolvedores ou "não querem forçar todos a trabalhar como um robô" (que é um ponto ridículo, mas não o use como um ponto problemático para a gerência superior). Eles devem se preocupar com a estabilidade contínua do projeto.

Pelo meu comentário acima:

Se ele é o líder do projeto, isso parece implicar que é basicamente a decisão dele.

Esse foi o meu pensamento. Se você quiser alterar o padrão, mas ele não estiver se movendo, a) descobre como se superar, b) vai para outro lugar para trabalhar ou c) tenta as pequenas coisas que você pode fazer sem irritá-lo demais.

Ficar acima dele só funcionará se você defender com firmeza o porquê de haver melhores padrões.

Basicamente:

• você não gosta do estilo de codificação dele. Esse é o seu direito.
• ele acha OK como ela é, e achados de passar dias / semanas / mais justa ajustar o estilo é um desperdício de tempo . Isso é direito dele.

Coloque-se no lugar dele. Quais são os benefícios do seu empreendimento, além de custar à empresa muito dinheiro (seu salário)? Ele é sempre tão exigente? Ele não vê que há coisas mais importantes para fazer agora?

Basicamente, você precisa encontrar algum tipo de compromisso com o qual possa conviver, ou seu relacionamento ficará azedo. Depende também muito de como você se comunica com ele. Coloque seu ego de lado e tente ser útil ... porque, finalmente, você está perguntando a ele as coisas que gostaria, e não algo que ele tenha interesse. Em outras palavras, você está pedindo um favor a ele .

Também geralmente depende de como você pergunta. Exemplos:

O que você quer:

tornando o código mais bonito

O que não dizer:

seu código é péssimo do jeito que é

O que dizer:

Eu realmente apreciaria se eu pudesse tornar os dois projetos consistentes, apenas o básico, e isso me levaria um dia.

O que você quer:

não há mais avisos não verificados

O que não dizer:

seu código é péssimo do jeito que é

O que dizer:

Conheço uma maneira rápida de me livrar disso e daquele aviso. Ao reativá-los, poderíamos detectar mais rapidamente se algo pudesse ser quebrado no futuro.

E por fim:

Eu sei que não é uma prioridade. Para que eu possa fazê-lo com prazer, uma vez que as coisas de alta prioridade estejam fora da mesa.

Ou, se isso não der certo ou você tiver um relacionamento ruim com ele, considere ir embora. Se você não pode resolver as coisas agora, é improvável que melhore no futuro ... e deixe seu ego de lado.

Nota

Eu acho que é mais comum as pessoas mais velhas serem mais brandas. Eles sabem que o código será descartado em uma década ou duas de qualquer maneira (porque a tecnologia muda, APIs também, equipes, parceiros de negócios, requisitos, decisões globais, qualquer que seja ...). Eles têm menos ego e se concentram em tê-lo funcionando, em vez de serem perfeitos. Embora eu tenha a tendência de me aperfeiçoar, não posso culpá-los.

Provavelmente isso vai ser controverso, mas ...

Conversamos e concordamos em discordar e escalá-lo para uma gerência superior

Nunca. Sempre. Faz. Este. SEMPRE. Toda vez que você faz isso, isso nos atrasa uma década. É assim que isso acontece:

• Gerente sênior 1: "Nos pediram para lidar com esse problema blá, blá, blá, algo sobre padrões de codificação e perda de tempo".

• Gerente sênior 2: "E eles estão nos pedindo para resolver suas guerras por território nerd, porque?"

• Gerente sênior 3: "Porque eles são bebês chorões que não conseguem se comunicar e não se importam / entendem o que é o valor comercial? *"

• Gerente sênior 2: "Deve ser isso. Quem está disposto a jogar golfe?"

Depois, você e o seu chefe analisam o desempenho:

"[gerente sênior do seu chefe]: desculpe, mas há alguma preocupação de que você não consiga gerenciar seus subordinados diretos e talvez não esteja seguindo as práticas recomendadas (mesmo que eu não tenha idéia do que você faz, exceto digitar algum mumbo jumbo que torna o software funcional) "

"[gerente sênior para você]: desculpe, mas há alguma preocupação de você não se relacionar bem com seus colegas e ter problemas para seguir as instruções do seu supervisor imediato".

E é por isso que a maioria é mal paga em comparação com o valor que criamos. **

Você precisa A) superar isso ou B) ir para uma loja que tenha os padrões ajustados um pouco mais perto do seu gosto. FWIW, eu faria B (e espero mudar para um idioma que não permita tais atrocidades). Mas nunca remova uma disputa técnica para os processos, a menos que envolva algo ilegal ou potencialmente catastrófico (brecha na segurança). Simplesmente irritante não custa nada.

* Para pessoas que leem isso e entendem mal, não estou dizendo que o OP e seu chefe são assim (percebo que a qualidade / legibilidade do código tem um impacto direto nos resultados da empresa), estou dizendo que eles serão percebidos assim pela gerência não técnica.

** Para pessoas que pensam que meu retrato da alta administração como burros sem noção não é realista, entenda que os gerentes se preocupam (idealmente) em gerenciar pessoas da mesma maneira que nos preocupamos em gerenciar código. Eles podem não ter noção de assuntos técnicos, mas conhecem pessoas, e isso é mais uma razão para trazer a eles uma disputa que A) eles provavelmente não estão qualificados para resolver e B) vocês dois deveriam ter sido capazes de resolver sem ajuda faz você parecer ruim.

*** Sim, percebo que a dívida técnica pode acumular-se a ponto de afundar os negócios. Eu simplesmente não acho que o aparelho irá salvá-lo (dito isso, eu nunca o omito e prefiro fortemente que outros também não).

IMHO, você está enfrentando um desenvolvedor 'está funcionando', e não um que se importaria com o próximo passo atrás deles. Seus argumentos são simplesmente inúteis.

Tudo o que você diz sobre o código dele é apenas uma preguiça bruta da parte dele. Ter projetos seguindo o mesmo padrão de codificação tem a ver com rigor. Você não é um robô; vocês são engenheiros; você deveria ser rigoroso.

Você pode apontar através de alguns exemplos que você está tendo dificuldades para ler o código dele, e isso representa uma enorme perda de produtividade para você, mas não tenho nenhuma idéia real de como levar isso para ele.

Mas provavelmente vou responder a você que algo é o tom:

Está funcionando, não faz sentido mudar

Meu conselho: se ele é realmente franco e não quer dirigir nada, deixe para lá. Aguarde erros / bugs / evolução no seu projeto. Quando vier, basta consertar e reescrever a parte do código modificada / adicionada de maneira adequada; não vá falar com ele sobre isso. Ele não vai impor a você seu estilo de codificação, já que você não é um robô ...

Quando você trabalha em um projeto, precisa definir prioridades.

A prioridade nº 1 é se dar bem com seus colegas de trabalho. A prioridade nº 1 é seguida por uma enorme lacuna. Em seguida, vêm prioridades para coisas como código que está funcionando, testável, testado, documentado, manutenível etc. Em seguida, surge outra grande lacuna e, em seguida, vêm os padrões de codificação.

E alterar o código existente para se adequar aos novos padrões de codificação é realmente baixo na lista de prioridades.

PS. "Micro-otimização" vs "computadores super-rápidos": argumento totalmente errado. O argumento contra a micro-otimização não é que os computadores sejam rápidos, o argumento é que o tempo perdido nas micro-otimizações significa que você não tem tempo buscando economias reais .

PS. Se você precisar de apenas um dia para fazer alterações que melhorem o código, mas incomodar seu colega de trabalho e torná-lo um inimigo, você desperdiçou um dia em algo que é apenas contraproducente.

PHP não é o grupo de elite em nossa profissão. Na verdade, você está criticando o seu sistema de software provavelmente conquistado com muito esforço. Seu padrão profissional é mais alto que o dele.

Então, se você não tem margem para melhorar o código sob suas responsabilidades, resta apenas uma solução: siga em frente .

Não conheço o mercado PHP atual em sua casa, mas você pode primeiro diversificar um pouco. Aprenda também uma linguagem exagerada ou um nicho como o C #.

Você pode não conseguir um emprego tão bom, mas irá além, profissionalmente. Portanto, tenha paciência e faça um auto-estudo. Dinheiro seguro. Em seguida, peça uma margem de manobra em seus projetos ou aceite uma oferta de emprego.

Acho difícil acreditar que o número 1 seja sua verdadeira razão para não querer alterar os padrões de codificação. Se você possui a base de código, deve poder aplicar os padrões de codificação com os quais (e outros desenvolvedores) concordam. Se você chegar a um consenso com os outros desenvolvedores (supondo que o líder não esteja mais realizando nenhum trabalho de desenvolvimento), não há motivo para ele realmente se importar, exceto por este:

A correção do estilo da base de código é o melhor uso do seu tempo agora?

Tenho certeza que você tem entregas. Quanto tempo vai custar para melhorar e melhorar o estilo em todos os lugares da outra base de código? E se você introduzir erros corrigindo o estilo incorretamente? Do tio Bob:

É claro que códigos ruins podem ser limpos. Mas é muito caro. À medida que o código apodrece, os módulos se insinuam, criando muitas dependências ocultas e emaranhadas. Encontrar e quebrar antigas dependências é uma tarefa longa e árdua.

Melhorar o estilo de código como esse quase nunca é um bom uso do tempo como um item de sprint independente . O jeito que eu gosto de fazer esse tipo de aprimoramento é o que chamo de "Política do Bom Vizinho": não saia fixando todo o estilo e estrutura lógica que puder encontrar, porque você provavelmente investe o tempo que quiser e ainda o fará não ser feito. Em vez de: sempre que estiver fazendo uma alteração em uma parte do código, corrija o estilo enquanto estiver lá e deixe-o melhor do que o encontrou. Se você está tentando implementar um recurso porque o código foi mal projetado, corrija o estilo para desbloquear a si mesmo em vez de bater com a cabeça nele.

Dessa maneira, cada alteração:

1. Tem uma motivação comercial além da motivação do perfeccionismo técnico
2. Não será visto como um grande investimento de tempo (porque não é!)
3. Estabelecerá bons hábitos estilísticos justamente porque você e sua equipe farão isso ao longo do tempo
4. Não apresentará um grande risco para a base de código, porque você não está mudando muito de uma só vez

Daqui a alguns meses, você observará que o "pacote terrível" não é mais tão ruim e seu chefe verá que a equipe dele está mais feliz. Mas, como não foi um confronto direto, já será feito, e ele não terá do que reclamar porque você não perdeu tempo (na mente dele) adicionando um grande projeto de refatoração à lista de tarefas. Ele provavelmente nunca lhe dirá que você estava certo, mas esse não é o objetivo de qualquer maneira (certo?).

Faça essas perguntas sobre sua liderança.

• Eles estão acostumados a trabalhar sozinhos ou com uma equipe muito pequena?
• Eles codificaram principalmente nessa loja?
• Eles estão acostumados a tomar decisões?
• Eles estão acostumados a "apenas fazer"?
• Eles escreveram a maior parte do código?

Se as respostas forem "sim", então vou pintar uma imagem de um tipo específico de programador líder. Se combinar com o que você experimentou, talvez ajude a entrar na cabeça deles. Caso contrário, ignore esta resposta .

É alguém que está lá desde o primeiro dia, passou anos no mesmo trabalho trabalhando na mesma base de código, está acostumado a fazer o que quer e não tem muita experiência com outras maneiras.

Eles não consideram outras pessoas quando escrevem código, já que tudo faz sentido para elas. É claro que sim, eles escreveram ou passaram anos entendendo.

Eles consideram o estilo de codificação uma preferência pessoal, não uma ferramenta para reduzir a manutenção e os bugs. Ao discutir sobre o estilo de codificação, eles se esforçam para ouvir seus argumentos, porque provavelmente nunca pensaram muito sobre por que fazem as coisas do seu jeito. O que eles ouvirão é "Quero fazer do meu jeito" ou "Quero fazer do jeito novo, chique e moderno".

Eles estão definidos em seus caminhos. Porque eles fazem da mesma maneira há muito tempo todas as suas ferramentas e editores e o cérebro micro-configurado exatamente com o seu estilo. Qualquer desvio desse estilo entrará em conflito com esse modo de trabalho cuidadosamente organizado, mas muito frágil. As tentativas de mudar gerarão reclamações sobre seus editores, ferramentas, a maneira como eles gostam de trabalhar ou sobre "ser difícil de ler". Eles rejeitam a mudança porque se envolveram tão fortemente no status quo que não podem mudar.

É alguém que nunca aprendeu corretamente engenharia e arquitetura de software. Eles meio que batem juntos o que quer que funcione.

Você tem um problema pessoal, não tecnológico.

Você terá que treinar novamente sua liderança ou precisará sair.

Ir para a administração é o último recurso . Ambos pelos motivos apontados pelo @JaredSmith e porque você perderá. Esse cara passou anos ganhando dinheiro com eles. Ele escreveu a empresa deles. Ele foi extinto em numerosos incêndios. Para você, ele é um chef de cowboy fazendo espaguete. Para eles, ele é um herói que construiu e salvou a empresa.

Para treinar novamente, você terá que ...

• Ganhe sua confiança.
• Descobrir como ele pensa.
• Aborde seus medos sobre a mudança.
• Facilite a mudança.
• Mostre como isso é melhor para ele .

Leve o estilo dele a sério e entre na cabeça dele. Pergunte a ele sobre isso. Por que ele faz as coisas do jeito que faz? O que ele vê quando o lê? Como ele interage com suas ferramentas? Como ele se move através do código? Conhecer todas essas coisas permitirá que você entenda e resolva as objeções dele.

Encontre a raiz objetiva de suas objeções subjetivas, torne-as acionáveis. "É difícil de ler" é subjetivo e não fornece informações. Você não pode fazer nada sobre isso. "Eu sou daltônico e o destaque da sintaxe não funciona" é objetivo, fornece informações e você pode fazer algo sobre isso. Eu recomendaria um livro chamado Getting To Yes para mais informações.

Depois de encontrar o problema raiz, o problema real que ele está enfrentando, veja se você pode corrigi-lo ou mitigá-lo. Então não é um problema. Eles provavelmente ainda terão problemas emocionais com a mudança, mas pelo menos não podem mais argumentar que é um problema real.

Faça um pouco de cada vez. É alguém que faz da mesma maneira há anos. Ele está acostumado a ver certos padrões no código e usá-los para entendê-lo. Mudar repentinamente todos esses padrões será confuso. Por mais frustrante que seja para levá-los a devagar com as boas práticas conhecidas, você deve orientá-lo.

Defenda um estilo comunitário padrão. Isso elimina o argumento de que se trata de preferência pessoal e pressiona-os a justificar por que o estilo diferente deles é muito melhor. Se você planeja contratar, fica mais fácil integrar novas contratações.

Defenda o estilo de código automatizado. Faça o seguinte no estilo correto pressionando um botão. Use uma ferramenta que comece com um estilo padrão, permita configurá-lo ao seu gosto e possa reestilizar o código pressionando um botão. Tornar o estilo o mais fácil possível remove muitos argumentos sobre o quão difícil será seguir. Eles podem codificar como quiserem e, quando terminam, apertam um botão e seguem um estilo que outros podem ler.

Como essa pessoa não tem a mentalidade de pensar nos outros, você terá que mostrar como essas mudanças os beneficiam. Pode ser tão simples quanto "já que esse é o padrão agora, você não terá que passar por essa briga novamente com a próxima pessoa que contratar". Ou pode ser "se tivermos testes, você pode ser mais agressivo ao alterar o código e se preocupar menos em mudar as coisas". Ou "se houver bons documentos, as pessoas não precisarão incomodá-lo com perguntas sobre como o código funciona". Para que isso seja eficaz, você precisará saber o que eles querem - algumas pessoas gostam de ser incomodadas, isso faz com que se sintam importantes.

É um longo, longo caminho. Você terá que decidir se tem paciência para gerenciar e treinar seu chefe. Pense em si mesmo mais como professor do que como subordinado frustrado, e você pode se sentir melhor com isso.

Estou errado?

Eu não sei PHP, então não posso fazer um julgamento direto, mas assumirei, por uma questão de argumento, que seu estilo de codificação preferido é "melhor" que o código que você encontrou, já que o seu está mais alinhado com ferramentas automatizadas existentes.

Então você não está errado ao sugerir melhorias no estilo de codificação.

Resumindo, não o código com o qual quero trabalhar

Você pode estar errado ao recusar trabalhar com código que não atenda aos seus padrões preferidos, mas apenas na medida em que, ao trabalhar para a empresa, você concordou em trabalhar com o código em primeiro lugar. Por fim, não é "errado" deixar o emprego se isso exigir de você que não lhe agrada, já que esse é o seu direito, e você poderá encontrar um emprego melhor como resultado.

Eu imponho minhas preferências pessoais?

Não. Ele é o líder do projeto e você não. É a decisão dele, embora neste caso ele seja "delegado para cima".

Ele poderia muito bem ter decidido delegar para você, como desenvolvedor líder dos subprojetos, e dar-lhe a mão livre para definir os padrões de codificação para os subprojetos e colegas que trabalharem neles no futuro. Mas, por qualquer que seja o motivo, ele sente que não deve padronizar. Mesmo se ele estiver errado sobre o estilo de codificação você não pode esperar reivindicar uma autoridade que ele não permitiu.

No entanto, como ele diz "Não gosto de aplicar estilos de codificação", você pode pelo menos escrever um novo código no seu estilo preferido (e o fez). Em última análise, isso pode resultar em oportunidades para demonstrar os benefícios objetivos do seu estilo. Seria uma boa hora para tentar o seu caso.

Você também pode (acho) razoavelmente pedir às pessoas que editam arquivos que façam isso no estilo em que o arquivo já foi gravado. Isso permite que você mantenha padrões nos arquivos que você escreveu. Infelizmente, o outro lado disso é que você teria que editar os arquivos que ele escreveu em algo semelhante ao seu estilo.

Mesmo supondo que você tenha um conjunto de testes realmente bom e, portanto, possa refatorar com relativa segurança, ainda existem razões (reconhecidamente razoavelmente marginais) para não invadir e renomear arquivos inteiros. O principal é que é um pesadelo tentar mesclar, reordenar ou reverter as alterações feitas antes e depois de uma grande mudança estrutural. Mas pode ser que nesse projeto em particular isso quase nunca aconteça.

[Meu gerente diz que não] gosta de aplicar estilos de codificação às pessoas [porque] não somos robôs.

Você já se perguntou por que não jogamos fora o código fonte depois de compilá-lo e ele passar em todos os testes? O código fonte é para humanos, e não é apenas para os humanos escreverem, mas também lerem .

Mais cedo ou mais tarde, alguém terá um motivo para voltar e ler o código. Talvez eles precisem mudar, talvez documentar, talvez reutilizá-lo. Tanto faz. Isso vai acontecer, e o código será muito mais fácil de ler e trabalhar, se tudo estiver em um estilo consistente.

Mesmo um estilo ruim é melhor do que nenhum estilo.