Como equilibrar a qualidade do código versus personalidades fortes do desenvolvedor

Nas revisões de código em andamento, tenho visto códigos e padrões que considero "inteligentes", embora não necessariamente aumentando a qualidade geral ou a capacidade de manutenção da base de códigos. Aponto isso no meu feedback e não estou convencido pelos contra-argumentos. Estou um pouco preocupado quando esse código entra no repositório e depois na produção.

Quero manter uma equipe coesa, por isso não quero criar tensão sendo muito sincera sobre minhas reservas. Eu também quero criar um ótimo produto para nossos clientes sem ser muito leninente.

Tradicionalmente, quem tem poder de "veto" sobre o que é verificado e como?

Como o código que funciona, mas muito envolvido / inteligente, pode ser removido sem pisar no pé?

Eu amo esta citação:

"A depuração é duas vezes mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, você não é, por definição, inteligente o suficiente para depurá-lo." - Brian W. Kernighan

Por um lado, isso o deixa cansado de código muito inteligente, pois será difícil depurar e estender mais tarde.

Por outro lado, código inteligente que funciona é uma ótima maneira de aprender. Provavelmente para toda a equipe. Que tal incentivar o autor a dar uma pequena conversa informal sobre o código para seus colegas? Apenas certifique-se de que realmente funcione conforme o planejado e que faça sentido no projeto como um todo. Você não quer transformá-lo em uma competição inútil!

Se você não acha que agrega valor, coloque o contra-desafio perguntando: "Como você pode refatorar esta parte (você tem testes, certo?), Para que fique mais legível?" Certifique-se de apontar que é mais difícil criar um código inteligente e legível do que criar pepitas impenetráveis.

Meu conselho é interpretar o idiota, quando é hora de fazer revisões de código, sinta-se à vontade para dizer que você não tem idéia de como ele funciona (se seu ego precisar de uma massagem, você pode dizer que não teve tempo para descobrir isso ) e peça ao desenvolvedor que o explique. Quando ele terminar, você pode sugerir que ele anote tudo isso como um comentário para manutenção futura, com a sugestão implícita de que é complicado demais para ser considerado um código 'bom'.

Se o seu código for um pouco complicado demais, a maioria das pessoas receberá a dica, sem que nada tenha sido dito sobre a qualidade do código ou a experiência do desenvolvedor.

PS. Obviamente, a maior parte desse código será subjetiva de qualquer maneira; portanto, o código incrivelmente inteligente de uma pessoa pode ser um algoritmo razoável e talvez até padrão do setor para outro desenvolvedor; portanto, você não pode acusar ninguém diretamente de escrever código ruim (exceto quando é óbvio) como o contratado que copiou uma matriz de bytes em uma lista stl, passou para uma rotina de criptografia e depois a converteu novamente em uma matriz de bytes!)

Minha regra geral é dobrar as diretrizes de qualidade do código em favor de personalidades fortes de desenvolvedores. Eu o uso sempre quando não tenho tempo para cavar fundo o suficiente - esse tipo de escavação costuma consumir bastante esforço (mais sobre isso abaixo).

Esta regra é baseada na experiência pessoal. Comecei (provavelmente como qualquer neófito) a seguir fanaticamente as orientações e a combater completamente todos os desvios. Com o tempo, adquiri habilidades suficientes e aprendi truques suficientes para vencer essas lutas com relativa facilidade - o que, por sua vez, permitiu focar mais em aprender o impacto geral das minhas "vitórias". E o impacto, pelo que sei, foi bastante negativo - os caras que "perderam a luta" estavam sofrendo e se tornaram menos produtivos - e, você sabe, o fato de o código deles estar 200% em conformidade com as diretrizes de qualidade não compensou isso.

Essa descoberta me levou a abandonar a maior parte dos combates, o que, por sua vez, levou a ter mais tempo para analisar casos problemáticos. E descobri que, quando me aprofundo o suficiente, há tipicamente um problema interessante de design em algum lugar atrás, um problema sutil (ou não muito sutil) que estava apenas se escondendo atrás das personalidades lutando.

• É como, digamos, que acho que o arquivo de origem 31K excede o limite de tamanho recomendado, ou seja, 30K. Minhas opções são gastar alguns minutos / horas lutando para forçar o proprietário do arquivo a extrair de alguma forma esse kilobyte extra ou passar um dia ou dois pensando e cavando para descobrir que, digamos, há alguma API de biblioteca que pode ser usada em vez de todas o código nesse arquivo (para que ele possa ser removido).

Essa descoberta às vezes pode não ser muito útil do ponto de vista do usuário final (embora às vezes possa ter um impacto profundo), mas é preciso admitir que a diversão que eu sinto ao quebrar uma noz faz com que valha a pena o esforço ... e como A cereja no topo das orientações do bolo também desaparece sem luta. :)

Sua organização deve ter um documento de diretrizes / normas de codificação atualizado periodicamente com as informações da equipe de desenvolvimento. Esse documento pode especificar detalhes, como: como nomear variáveis, como formatar código e assim por diante. O documento também deve explicar os valores que a organização espera que os programadores adotem ao escrever código, incluindo a importância relativa de coisas como legibilidade, facilidade de manutenção, correção, eficiência e aderência aos padrões.

As revisões de código devem ser conduzidas usando esse documento de padrões de codificação. Se os padrões de codificação disserem que os programadores devem preferir a legibilidade à brevidade quando os dois estiverem em conflito, você terá algum apoio para argumentar contra o código "inteligente". Se os padrões não dizem isso e você acha que deveriam, então você pode argumentar sobre isso em resumo na reunião dos padrões de codificação, em vez de tentar descobrir quando o ego de alguém está em jogo.

Em última análise, às vezes se trata de um julgamento e, nesses casos, a palavra final deve ser da pessoa responsável pelo código e / ou produto. Geralmente, alguém como desenvolvedor sênior, líder técnico, gerente de projetos ou diretor de engenharia. Se você é o responsável e sente que determinado código não é suficientemente sustentável, não deve ter medo de dizer isso. Você pode ser diplomático sobre isso:

Sam, estou impressionado com a sua engenhosidade aqui, mas estou preocupado que possa ser um pouco inteligente demais. Preciso que você trabalhe em um novo desenvolvimento daqui a um ano, em vez de mantê-lo, e estou preocupado que quem tiver que mantê-lo possa não compreender completamente sua grandiosidade. Eu sei que você odeia fazer isso, mas eu apreciaria se você voltasse à implementação direta que discutimos.

Por outro lado, se você não é o responsável, o melhor que você pode fazer é explicar claramente sua posição e tentar convencer o restante da equipe. Se você não está recebendo apoio do gerente, aceite que não é sua escolha e siga em frente.

No seu lugar (e eu, às vezes, sou um desses espertinhos) , não o removo, mas peça pessoalmente ao autor espirituoso / inteligente para documentá-lo muito bem nos comentários e, se possível, para incluir alguma discussão sobre alternativas e escritos mais simples que ele poderia ter usado, com exemplos.

Eu gostaria de sublinhar que isso é o melhor, porque mesmo ele provavelmente não se lembrará de todos os trechos que existem, nessas linhas, em dois meses.

Ele provavelmente abandonará o código inteligente em favor do mais simples, assim que for obrigado a escrevê-lo, como exemplo.

Por que isso funcionaria?

• Você reconheceu que se importa com o que ele escreve ,
• você lhe mostrou respeito por pedindo ,
• citando problemas de memória / foco, você cria e divide com ele um cenário em que esse código deve ser alterado e não pode enquanto ele ainda trabalha para a empresa ou a equipe

(sem essa última alusão, esse tipo de solicitação pode ser recebida como uma tentativa, por parte da empresa, de comoditizar o programador , tornando-o intercambiável com qualquer outro macaco de código a qualquer momento)

Na minha experiência, normalmente é muito difícil obter código que atenda a todos os requisitos da base de código.

No entanto, da próxima vez que o código for mantido, você poderá argumentar facilmente sobre sua substituição como uma medida futura de economia de custos, porque o código antigo era mais difícil de manter.

Quanto ao poder de veto, a gerência obviamente tem isso.
Às vezes, são equipes ou comitês responsáveis ​​pela qualidade do código; nesse caso, eles também teriam esse poder.

Também seria útil se você der um exemplo de um padrão 'inteligente'. Talvez você esteja exagerando ...

'inteligente' quase nunca é uma coisa ruim no meu livro, mas posso concordar que pode haver uma inclinação escorregadia entre inteligente e complicado.

Como muitas outras práticas, acho que a resposta é que depende .

• Se é um defeito, ele definitivamente precisa ser corrigido.
• Se o código funcionar, você precisará equilibrar o valor de insistir para que o código seja alterado versus o custo futuro do código inteligente. Embora existam regras práticas relacionadas à relação entre trabalho de desenvolvimento e trabalho de manutenção, elas variam muito de projeto para projeto. Seja razoável.
• Considere por que você não consegue convencer seu colega de equipe de que o código precisa ser simplificado?
• Você nem sempre precisa obter tudo perfeito. Isso significaria análises de código em um loop infinito e nada registrada porque nada (exceto meu código, haha) é perfeito.
• Minha preferência pessoal é que o autor do código tenha a palavra final. Obviamente, se eles estão continuamente fazendo um trabalho muito ruim, outras ações devem ser tomadas, mas, como você diz, o valor negativo de forçar o desenvolvedor a alterar o código pode ser maior que o ganho obtido ao corrigi-lo, se esta for uma situação muito rara. .

Definitivamente, posso me relacionar com essa pergunta. Atualmente, sou o líder técnico de duas equipes e é meu trabalho garantir que o código que produzimos seja o mais legível e possível de manter. Ao mesmo tempo, soube produzir um código "inteligente" e sei que a maioria dos meus colegas de equipe terá muita dificuldade em segui-lo.

Poucas observações posso oferecer:

1. Sua equipe precisa de um líder que tome a decisão final quando houver um desacordo. No último lançamento, eu estava em uma equipe sem liderança e isso foi atroz. Tudo se tornou um argumento, e se você tiver poucas pessoas com personalidades fortes, nenhuma delas se mexerá. Se você tem uma liderança, independentemente da decisão escolhida, todos na equipe DEVEM entender que o que a liderança diz é válido. É por isso que a gerência fez dele a liderança.

2. Manter as pessoas felizes é muito importante. Portanto, em vez de empurrar toda a equipe em direção ao seu ponto de vista, apenas cutuque-a. Explique os princípios do SOLID, explique a importância de classes / métodos / interfaces pequenas e coesas e repita essas coisas toda vez que você as vir violando (ou seja, em uma revisão de código). Ao mesmo tempo, não os faça reescrever tudo o que você não gosta. No final do dia, você precisa de um equilíbrio entre a expressão pessoal e os seguintes padrões de grupo. Felizmente, os dois convergirão à medida que as preferências pessoais mudarem para como o grupo em geral está operando.

3. Eu acredito que é muito mais importante ter interfaces de classe limpas e fáceis de entender, do que nunca ter um código "inteligente". Por exemplo, temos uma classe que mantém uma lista de entradas pesquisadas de três maneiras diferentes. Atualmente, ele simplesmente usa a pesquisa linear para todas as pesquisas que funcionam em pequena escala, mas como essa classe está em um nível muito baixo, vejo que ela não está sendo dimensionada muito bem. Estou prestes a substituí-lo por uma classe diferente, que usa contêineres Boost Intrusive. Cada elemento suportará a colocação em cada um dos índices simultaneamente e toda a pesquisa será feita em O (sqrt (N)). Sim, será muito mais complicado por dentro e muitas pessoas não gostam do Boost, mas por fora permanecerão três métodos: Adicionar, Remover, Obter. Resumindo, as pessoas podem escrever o código que quiserem (dentro da razão),

4. Mantenha a ideia de propriedade do código. Embora às vezes seja difícil de alcançar, como pessoas diferentes podem precisar adicionar / modificar algum código. Quando o código é escrito, o desenvolvedor original é o detentor final desse código. Isso não significa que ninguém mais possa tocá-lo. Se outros modificarem seu código, tudo bem, mas no final do dia o desenvolvedor original o analisa e continua sendo responsável por tudo o que estiver lá. Se esse código é simples ou inteligente, é o bebê dele. Se / quando, como você está prevendo, os bugs começarem a se acumular por causa das decisões de design / codificação que foram tomadas, em vez de simplesmente consertá-los quando eles entrarem, sente-se com o desenvolvedor (quem btw deve consertar todos esses bugs) e refletir sobre essas decisões para ver como elas poderiam ter sido tomadas de maneira diferente.

Passei muitos anos liderando e gerenciando equipes de desenvolvimento. Por natureza, sou um pouco TOC em termos de código e muito em preto e branco. Aprendi com a experiência que escolher suas batalhas é uma das habilidades mais difíceis de aprender como líder de equipe. Sim, os padrões são importantes. Sim, a legibilidade e a manutenção são incrivelmente importantes. Sim, todos devemos nos esforçar para escrever um código uniforme e compatível com os padrões. Porém, os desenvolvedores são humanos ... não ferramentas de geração de código. Temos personalidades, opiniões, ficamos entediados e queremos aprender coisas novas.

Nas revisões de código em andamento, tenho visto códigos e padrões que considero "inteligentes", embora não necessariamente aumentando a qualidade geral ou a capacidade de manutenção da base de códigos.

OK ... então eles não adicionam, mas diminuem? Estamos falando apenas de uma questão de preferência pessoal nos estilos de codificação ou o código está sendo escrito completamente desnecessário (por exemplo, usando árvores de expressão e reflexão apenas porque é divertido usar árvores de expressão e reflexão)? Se for o primeiro, deixe para lá. Parte da diversão de ser desenvolvedor é apresentar soluções criativas para os problemas. Talvez (e a maioria de nós não goste de admitir isso), às vezes nos sentimos intimidados por abordagens que não entendemos e não queremos perguntar ou não temos energia adicional para aprender a nova abordagem.

Agora, quando a criatividade levar a um código desnecessário e a uma complexidade completamente injustificável, seja sincero e faça seu caso. Ser um jogador de equipe é importante, mas também é ser (e responsabilizar os outros). As revisões de código envolvem responsabilidade, tanto quanto garantia de qualidade e aprendizado. Você vai pisar em alguns dedos, mas se você sente que tem um argumento forte por que esforço (dinheiro) deve ser gasto reescrevendo código de trabalho E um ego deve ser machucado no processo E você quer arriscar esmagar o entusiasmo de alguém por seu ofício , então você não deve deixar de colocá-lo na mesa. Se você é o líder da equipe, este é o seu trabalho. Esteja ciente do impacto e faça-o. Se você não é um líder de equipe e não tem autoridade, coloque-o na equipe para decidir.

A melhor maneira de incutir responsabilidade em sua equipe é incentivando outras pessoas a responsabilizá-lo. Se você mantiver a mente aberta e não desligar as pessoas quando elas sugerirem melhorias no seu código, você poderá descobrir que elas são mais receptivas às suas sugestões.

Por experiência pessoal, quando isso acontece, eu solicitava permissão para ser um testador voluntário da unidade adversária para escrever testes para torturar a implementação desconhecida.

Vou me esforçar muito para entender realmente como o código funciona e também tentar sondá-lo de várias maneiras diferentes.

Observe que este é um compromisso de tempo. Pode levar horas, dezenas de horas ou até uma boa parte de uma semana. A justificação depende se a complexidade do código é proporcional à complexidade do requisito.

Se eu não prevalecesse, ou seja, se o código sobreviver a muitos testes, me convenceria de que talvez a implementação seja realmente mais esclarecida do que eu, e apoiarei sua inclusão no produto principal.

Dependendo da metodologia de controle de origem, o código pode ter que ser provisoriamente confirmado no sistema de controle de origem (talvez em uma ramificação) antes que esta fase de teste possa começar.

Minha resposta é colorida pela minha experiência no uso do OpenCV. Existem algoritmos que são muito mais sofisticados do que qualquer programador pode implementar por conta própria; nem mesmo doutores - talvez os primeiros percentuais de doutores. Se o código é que bom, você tem que confiar que, agindo contra seus próprios instintos e preconceito, mesmo se você não tem meios eficazes de quantificar esse nível de confiança.