Como posso promover uma codificação limpa no meu local de trabalho?

Trabalho com muitos códigos Java e RPG herdados em um aplicativo interno da empresa. Como você pode esperar, muito do código é escrito em muitos estilos diferentes, e geralmente é difícil de ler devido a variáveis ​​mal nomeadas, formatação inconsistente e comentários contraditórios (se houver).

Além disso, uma boa quantidade de código não é robusta. Muitas vezes, o código é enviado rapidamente à produção pelos programadores mais experientes, enquanto o código dos programadores mais recentes é retido pelas "revisões de código", que a IMO não é satisfatória. (Eles geralmente tomam a forma de "Funciona, deve estar bem", do que uma crítica séria ao código.) Temos um número razoável de problemas de produção, que eu acho que poderiam ser diminuídos se pensarmos mais no design e no design original. teste.

Eu trabalho para esta empresa há cerca de 4 meses e fui elogiado no meu estilo de codificação algumas vezes. Meu gerente também é um fã de codificação mais limpa do que a norma. É meu dever tentar melhorar o estilo e a codificação defensiva, ou devo simplesmente codificar da melhor maneira possível e espero que meu exemplo ajude outras pessoas a ver como um código mais limpo e robusto (além de refatoração agressiva) resultará em menos depuração e mudará o tempo?

Você não mencionou seu nível de conhecimento sobre o assunto. Se você não é um programador sênior, acho que a melhor coisa a fazer é fazer bem seu próprio trabalho. Você também mencionou que seu gerente gosta de um trabalho limpo - isso é ótimo. Se você puder conversar com ele sobre isso (talvez em um ambiente semi-profissional), compartilhe suas preocupações com o problema. Ele está em posição de alterar o fluxo de trabalho.

O que o código limpo significa para você?

Tenho certeza de que sua definição é ótima, mas os outros caras no seu local de trabalho provavelmente têm sua própria definição. Eles não estão errados, apenas diferentes dos seus.

Você deve criar diretrizes de codificação com as quais todos no seu local de trabalho possam concordar e fazê-lo junto com seus colegas programadores. Não tente forçar isso com as pessoas, pois isso sairá pela culatra.

Então junte a equipe e comece a trabalhar em uma definição comum de "código limpo"! Não há regras rígidas para isso. Você está tentando reunir várias mentes e isso pode resultar em conflitos; portanto, convém preparar o cenário com uma nota positiva de que todos devem ser respeitosos e manter a mente aberta (a codificação é pessoal ...).

O livro Código Limpo pode ser útil. Você poderia usar exemplos desse livro para conversar e ver se encontra algum ponto em comum lá?

Há duas coisas que podem fazer maravilhas para garantir uma consistência e alta qualidade de código.

Comentários do Do Code

Você deve se esforçar para que cada check-in - por mais trivial que seja - seja revisado por outra pessoa da equipe. Sem exceções. Parece que isso vai atrapalhar no começo, especialmente para desenvolvedores seniores que pensam que não têm nada a ganhar ao ter pessoas menos experientes revisando seu código. No entanto, a revisão regular do código terá um impacto imensurável para todos os desenvolvedores da equipe.

Definir um padrão e seguir com ele

No Google, temos um guia de estilo de codificação para todas as linguagens que usamos: C ++ , Java , Python , etc. Embora os engenheiros estejam livres para discordar do guia de estilo, ele não é opcional. (E é rigorosamente aplicada nas revisões de código.) Como resultado, toda a base de código - centenas de milhares de linhas de código - é muito consistente.

Eu acho que se você é apaixonado por código limpo, isso atrapalha seus colegas. A mentalidade "Funciona, deve estar bem", que pode ser alterada por pessoas que defendem o bom design e o código limpo de maneira entusiasmada.

Embora várias respostas úteis tenham sido postadas aqui por algum tempo, acredito que há espaço para mais uma. Minha sugestão é, como já foi dito, fazer revisões de código. Mas vale a pena mencionar novamente porque o termo "revisão de código" é tão vago ... quase tão vago quanto "código limpo" :-). Passei muito tempo e esforço trabalhando para alcançar esse objetivo ilusório. E particularmente nos últimos dois anos, alimentados por colegas que compartilharam minha paixão, destilei minhas noções, misturadas com idéias-chave de desenvolvedores importantes, em uma série intitulada Zen of Code Reviews .

Meus artigos são únicos, tanto quanto eu sei, pois abrangem os dois lados do corredor: fazer uma revisão de código como autor e fazer uma revisão de código como revisor . Embora relacionadas, as habilidades de cada um são um pouco diferentes. E ser capaz de fazer as duas coisas bem vai levar a uma melhor qualidade de código. Revisar código é tão importante quanto escrever código. Realmente. Promove a transferência de conhecimento, incentiva a consistência e a comunicação da equipe, ajuda a melhorar o seu trabalho e, por último mas não menos importante, reduz o software de buggy com muito custo - de maneira mais próxima possível.

Os dois primeiros fornecem dicas e técnicas para preparar uma revisão de código. Em poucas palavras:

• Você, como autor, tem um conhecimento profundo de por que cada linha alterada está na sua revisão de código. Muitos são óbvios para um revisor instruído, mas muitos não são. Transmitir esses pontos anotando sua revisão de código antes de enviá-la aos revisores.
• Mesmo antes disso, considere cuidadosamente o que compreende sua revisão de código: inclua todas as alterações relevantes para um problema e tente não incluir mais de um problema.
• Certifique-se de fazer uma verificação geral do controle de origem (para ressincronizar seu código com main) antes de enviá-lo.
• Revise seu próprio código antes de enviá-lo - linha por linha!

Parte 1: Comentários de Pré-Revisão: Capacite seus colegas para fornecer um feedback melhor sobre sua revisão de código

Parte 2: Práticas recomendadas: diretrizes para preparar uma revisão de código

E os outros dois artigos fornecem conselhos práticos sobre como ser um revisor melhor:

• Leia o Jira / issue / ticket / requisito (como quiser) primeiro.
• Verifique se os testes de unidade atendem aos requisitos.
• Revise os testes de unidade para obter a classe de equivalência e a completude do valor limite.
• Certifique-se de que cada teste de unidade faça o suficiente, sem testar várias coisas.
• Revise o código para aderência aos princípios do SOLID.
• Cuidado com a reinvenção de rodas, código excessivamente complicado e apenas código complicado.
• Evite a magia (cordas mágicas, ints mágicas e, sim, até booleanos mágicos).
• Capte o efeito borboleta - existem ondulações que foram perdidas (por exemplo, inconsistências no nome).

Parte 3: História do Revisor: Diretrizes para executar uma revisão de código

Parte 4: Revise como se você fosse o proprietário do código

Lidere pelo exemplo. Revise seu código.

Na minha experiência, a maioria das aplicações "RPG + Java" são escritas por programadores vindos do lado do RPG, e não do lado do Java, e a mentalidade dos dois mundos é muito diferente, o que eu acredito ser uma das razões pelas quais você tem um design básico problemas

As ferramentas oficiais da IBM são baseadas no Eclipse, portanto, se você usar isso, poderá usar a maioria das dicas e truques disponíveis para o Eclipse, e precisará encontrar coisas que gerem muito em troca de pouco esforço, porque basicamente você precisa mostrá- las. pessoas que vale a pena fazer.

Uma das coisas mais eficientes que encontrei para isso é o Save Actions do editor Java, onde você pode solicitar que reformate sua fonte sempre que salvar um arquivo. Em breve, isso resultará em um layout de codificação mais uniforme, facilitando a leitura das coisas. Eu escrevi minhas descobertas aqui.

Se primeiro você plantou a noção de que pode ter sugestões úteis, as pessoas têm muito mais probabilidade de ouvir ...

"Todo mundo escreve código incorreto". Digere e depois reconheça. Isso define toda a equipe em um plano que quebra a hierarquia e instila em todos que todos são iguais. É muito importante que um programador sênior demonstre esse comportamento e atitude. Com essas premissas, pratique a programação em pares durante a qual você deve discutir, debater (com tempo definido) e convergir para uma decisão sobre o que é certo depois de conversar sobre por que algo pode estar errado. Enquanto a programação em pares, uma pessoa é superior a outra - ambos são programadores humildes e abertos. Que melhor maneira de promover boas práticas de codificação! :)

Uma maneira que eu não vi mencionada em nenhuma das respostas até agora é a educação. Faça com que sua empresa patrocine entradas para aqueles que desejam ir ao JavaZone ou RubyConf mais próximo ou a qualquer conferência que seja adequada e conveniente para você. Encontre cursos relevantes e envie os desenvolvedores selecionados para participar. Se sua empresa é grande o suficiente, pode até ser possível organizar seminários e cursos internos sobre assuntos como boas práticas, master classes para o seu idioma, etc. Obtenha um bom palestrante sobre o assunto e prepare um curso adaptado à situação da sua empresa.

Minha empresa está fazendo isso bastante e, embora ainda haja quem se recusa a se interessar, o conhecimento geral de problemas como esse está aumentando - e o estado geral de nossa base de códigos está melhorando. Até o curso "Básico C" que fizemos por várias rodadas provou ser esclarecedor para os desenvolvedores que escrevem C há 10 a 15 anos. Não porque eles são maus programadores, mas porque você tende a adotar hábitos e esquecer o porquê, e que a linguagem e a experiência coletiva sobre como usá-lo também estão mudando lentamente.