Como equilibrar a qualidade do código com as strongs personalidades do desenvolvedor

14

Nas revisões de código no trabalho, tenho visto código & padrões que considero "inteligentes", embora não necessariamente adicionando à qualidade geral ou manutenção da base de código. Eu aponto isso no meu feedback e não estou convencido pelos contra-argumentos. Estou um pouco preocupado quando este código entra no repo e depois para a produção.

Eu quero manter uma equipe coesa, então eu não quero criar tensão por ser muito vocal sobre minhas reservas. Eu também quero criar um ótimo produto para nossos clientes sem ser muito leninento.

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

Como o código funciona, mas é muito complicado / inteligente ser removido sem pisar nos dedos?

    
por Ivo 14.08.2011 / 23:11
fonte

10 respostas

15

Adorei esta citação:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan

De um lado, isso deixa você cansado de códigos muito inteligentes, já que será difícil de 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 encorajar o autor a dar uma pequena conversa informal sobre o código para seus colegas? Apenas certifique-se de que ele realmente funciona como planejado e que isso faz sentido no projeto como um todo. Você não quer transformá-lo em uma competição inútil!

Se você não acha que isso agrega valor, coloque o contra-desafio perguntando: "Como você pode refatorar essa parte (você tem testes em andamento, certo?) para que seja mais legível?" Certifique-se de apontar que é mais difícil criar um código legível e inteligente para fazer nuggets impenetráveis.

    
por 15.08.2011 / 03:16
fonte
10

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

Se o código bom for um pouco complicado demais, a maioria das pessoas entenderá 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 deste código será de qualquer maneira subjetiva, de modo que o código incrivelmente inteligente de uma pessoa pode ser um algoritmo razoável e talvez até mesmo padrão da indústria para outro desenvolvedor, portanto você não pode acusar ninguém diretamente de escrever código incorreto como o contratante que copiou uma matriz de bytes em uma lista de stl, passou-a para uma rotina de criptografia e a converteu novamente em uma matriz de bytes!)

    
por 15.08.2011 / 02:09
fonte
6

Minha regra básica é dobrar as diretrizes de qualidade de código em favor de personalidades strongs de desenvolvedor. Eu uso sempre quando não tenho tempo para cavar fundo o suficiente - tal escavação, a propósito, é tipicamente bastante desgastante (mais sobre isso abaixo).

Esta regra é baseada na experiência pessoal. Comecei (provavelmente como qualquer neófito) seguindo fanaticamente as diretrizes e lutando completamente contra cada desvio. Com o tempo, ganhei habilidades suficientes e aprendi truques suficientes para vencer tais lutas com relativa facilidade - o que, por sua vez, permitiu me concentrar mais em aprender o impacto geral de minhas "vitórias". E o impacto, tanto quanto eu posso dizer, foi bastante negativo - caras que "perderam a briga" estavam sofrendo e se tornando menos produtivos - e, você sabe, o fato de seu código ser 200% compatível com as diretrizes de qualidade não compensava isso.

Essa descoberta me levou a abandonar a maioria dos combates, o que, por sua vez, leva a ter mais tempo para analisar casos problemáticos. E eu descobri que quando eu cavo o suficiente normalmente há um problema de design interessante em algum lugar por trás, um problema sutil (ou não muito sutil) que estava apenas se escondendo por trás das personalidades que lutavam.

  • É como, você sabe, digamos que eu acho um arquivo fonte de 31K excedendo o limite de tamanho recomendado, que é 30K. Minhas opções são gastar alguns minutos / horas lutando para forçar o dono do arquivo a espremer o kilobyte extra ou para gastar um dia ou dois pensando e cavando para descobrir que, digamos, há alguma biblioteca API que pode ser usado em vez de todo o código daquele arquivo (para que possa ser removido).

Tal descoberta às vezes pode não ser muito útil do ponto de vista do usuário final (embora algumas vezes possa ter um profundo impacto), mas tenho que admitir que a diversão que eu tenho quando quebra uma porca faz valer o esforço de qualquer maneira ... e, como uma cereja no bolo, o desvio das diretrizes também desaparece sem uma briga. :)

    
por 16.08.2011 / 01:34
fonte
2

Sua organização deve ter um documento de diretrizes / normas de codificação que seja atualizado periodicamente com informações da equipe de desenvolvimento. Esse documento pode soletrar 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 dizem que os programadores devem preferir legibilidade a brevidade quando os dois estão em conflito, então você terá algum apoio em 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 de forma abstrata na reunião de padrões de codificação, em vez de tentar descobrir quando o ego de alguém está na linha.

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

Sam, I'm impressed with your ingenuity here, but I'm concerned that it may be just a little too clever. I'll need you to be working on new development a year from now rather than maintaining this, and I'm concerned that whoever does have to maintain it may not fully comprehend its awesomeness. I know you hate to do it, but I'd appreciate it if you'd go back to the straightforward implementation that we discussed.

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

    
por 15.08.2011 / 01:00
fonte
2

Em seu lugar (e eu, às vezes, sou um desses espertalhões) eu não removo, mas peço pessoalmente ao autor espirituoso / inteligente que documente muito bem nos comentários, e se possível, incluir alguma discussão sobre escritos alternativos e 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 bits e bobs que existem, nessas linhas, daqui a dois meses.

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

Por que isso funcionaria?

  • Você reconheceu que se importa com o que ele escreve ,
  • você mostrou a ele respect ao perguntar ,
  • , citando problemas de memória / foco, você cria e divide nele um cenário no qual esse código deve ser alterado e não pode enquanto ele ainda estiver trabalhando para a empresa ou a equipe

(sem essa última alusão, este tipo de pedido pode ser recebido como uma tentativa, por parte da empresa, de comoditizar o programador , tornando-o com qualquer outro código macaco a qualquer momento)

    
por 16.08.2011 / 04:15
fonte
1

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

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

No que diz respeito ao poder de veto, a gerência obviamente tem isso.
Às vezes, são equipes ou comitês encarregados da qualidade do código e, nesse caso, 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 um declive escorregadio entre inteligente e complicado.

    
por 14.08.2011 / 23:55
fonte
0

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

  • Se for um defeito, definitivamente precisa ser corrigido.
  • Se o código funcionar, você precisa equilibrar o valor de insistir que o código seja alterado em relação ao custo futuro do código inteligente. Embora existam regras práticas sobre a relação entre o trabalho de desenvolvimento e o 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 deixar tudo perfeito. Isso significaria revisões de código em um loop infinito e nada check-in 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, alguma outra ação tem que ser tomada, mas como você diz, o valor negativo de forçar o desenvolvedor a mudar o código pode ser maior do que o ganho obtido corrigindo-o se esta é uma situação muito rara. .
por 15.08.2011 / 04:03
fonte
0

Eu definitivamente posso me relacionar com essa questão. 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 sustentável possível. Ao mesmo tempo, sou conhecido por produzir um código "inteligente" e sei que a maioria dos meus colegas de equipe terá dificuldade em segui-lo.

Poucas observações que posso oferecer:

  1. Sua equipe precisa de um líder que tome a decisão final quando houver discordância. No último lançamento eu estava em um time sem liderança e era atroz. Tudo se tornou uma discussão, e se você tem poucas pessoas com personalidades strongs, nenhuma delas se moverá. Se você tiver uma liderança, independentemente de qual decisão for escolhida, todos na equipe DEVEM entender o que a liderança diz. É por isso que a gerência fez dele o líder.

  2. Manter as pessoas felizes é muito importante. Portanto, em vez de empurrar toda a equipe em direção ao seu ponto de vista, basta empurrá-los para lá. 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ê os vir sendo violados (por exemplo, em uma revisão de código). Ao mesmo tempo, não os faça reescrever cada coisa que você não gosta. No final do dia, você precisa de um equilíbrio entre a expressão pessoal e os padrões do grupo. Esperançosamente, os dois irão convergir conforme as preferências pessoais mudam para a forma 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 que são pesquisadas de 3 maneiras diferentes. Atualmente, ele simplesmente usa 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á muito bem dimensionada. Estou prestes a substituí-lo por uma classe diferente, que usa contêineres Boost Intrusive. Cada elemento suportará ser colocado 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 do lado de fora, restam três métodos: Adicionar, Remover, Obter. A conclusão é que as pessoas podem escrever o código que quiserem (dentro do razoável), mas as interfaces não devem ser inteligentes.

  4. Mantenha a ideia de propriedade de código. Embora às vezes seja difícil conseguir, pessoas diferentes podem precisar adicionar / modificar algum código. Quando o código é escrito, o desenvolvedor original é o guardião final desse código. Isso não significa que ninguém mais possa tocá-lo. Se os outros modificarem o código, tudo bem, mas no final do dia o desenvolvedor original revisa e continua sendo responsável por tudo que estiver lá. Se esse código é simples ou inteligente, é o bebê dele. Se / quando, como você está prevendo, os bugs começam a se acumular por causa das decisões de design / codificação que foram feitas, em vez de simplesmente corrigir esses bugs, entre em contato com esse desenvolvedor (quem deve estar corrigindo todos esses bugs) e refletir sobre essas decisões para ver como elas poderiam ter sido feitas de forma diferente. Depois, dê a ele um livro sobre refatoração e veja como você pode "desobstruir" parte dele.

por 16.08.2011 / 05:44
fonte
0

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

On code reviews at work I have been seeing code & patterns that I consider "clever" though not necessarily adding to the overall quality or maintainability of the code base.

OK ... então eles não adicionam, mas eles diminuem? Estamos falando apenas de uma questão de preferência pessoal em 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 ir. Parte da diversão de ser um desenvolvedor está chegando com 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 tampouco queremos pedir ou não ter energia adicional para aprender a nova abordagem.

Agora, quando a criatividade leva a um código desnecessário e complexidade completamente injustificável, então, de qualquer maneira, seja vocal e faça o seu caso. Ser um jogador de equipe é importante, mas o mesmo é ser (e responsabilizar os outros). Revisões de código são sobre responsabilidade tanto quanto garantia de qualidade e aprendizado. Você vai pisar em alguns dedos do pé, mas se você sentir que tem um argumento strong 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 evitar 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 para a equipe decidir.

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

    
por 10.01.2017 / 22:25
fonte
0

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

Eu tentarei muito entender realmente como o código funciona e também tentar investigá-lo de muitas maneiras diferentes.

Observe que esse é um compromisso de tempo. Pode ser horas, ou dezenas de horas, ou mesmo uma boa parte de uma semana. Se isso é justificado, depende se a complexidade do código é compatível com a complexidade do requisito.

Se eu não prevaleçasse, ou seja, se o código sobreviver aos muitos testes, eu me convenceria de que talvez a implementação seja realmente mais esclarecida do que eu, e vou apoiar 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 essa fase de teste possa começar.

Minha resposta é colorida pela minha experiência em usar o OpenCV. Existem algoritmos que são muito mais sofisticados do que qualquer programador pode implementar sozinhos; nem mesmo os PhDs - talvez as poucas porcentagens dos PhDs. Se o código é bom, você tem que confiar nisso, agindo contra seus próprios instintos e preconceitos, mesmo que você não tenha meios efetivos de quantificar esse nível de confiança.

    
por 10.01.2017 / 22:43
fonte