Recomendações para o ensino de programadores juniores bom estilo de codificação [duplicado]

Make a good impression

Pegue alguns dos livros conhecidos, por exemplo Limpo Código , Código concluído , Codificadores no trabalho , O Codificador Limpo: Um Código de Conduta para Programadores Profissionais etc. (consulte aqui as listas completas ) e dê-lhes um par de dias para ler um - no trabalho, em um escritório particular. Espaço para fora, digamos um livro por mês ou um quarto. Eles verão do esforço que o que você está dizendo pessoalmente é realmente importante, não apenas "a linha da empresa" para levar com um grão de sal. Obviamente, certifique-se de que você tenha o gerenciamento de acordo com isso - você não quer que eles digam de passagem "hein? O que a pessoa X está fazendo?", Com a porta fechada?

Juntamente com aulas de treinamento mais contínuas e formais nas mais recentes tecnologias.

Além disso, como as coisas são feitas "o caminho certo" deu grande incentivo e até mesmo recompensas. Caso contrário, pode ser mais um ambiente negativo, punitivo e não positivo, recompensador. A maioria das pessoas quer fazer e quer ser conhecida por fazer "um bom trabalho" se tiver as ferramentas necessárias para fazê-lo.

Practice what you preach, Preach what you practice

Fale sobre o código, fale sobre os bons princípios, fale sobre novas ferramentas, torne-se "conhecido" por ele.

Forneça / apoie / sugira screencasts, vídeos, peepcodes e quaisquer tutoriais e aulas online que possa encontrar.

Suporte e sugira grupos de usuários locais apropriados, incluindo aqueles em sites como o link

Se você estiver no escritório (ou seja, não virtual), uma estante de livros em bom estado dos livros reais que você gostaria que as pessoas usassem é boa. Encontrar uma maneira de fazer isso ser "não apenas empoeirada estante no canto", mas colocando-o realmente em destaque, Movendo os livros ao redor, etc Use sua imaginação também. Talvez todo programador receba um livro como "lição de casa" por mês e você tenha uma reunião mensal onde eles possam "apresentar suas descobertas"!

Isso causará uma impressão muito maior do que qualquer conversa de 10 minutos e irá tirar você do papel de 'crítico' e permitir que eles aprendam a pescar para si mesmos (ao invés de dar-lhes peixe, você sabe o negócio) . Algumas pessoas juniores também acham intimidante ter pessoas mais velhas sempre explicando coisas, quando às vezes tudo o que elas realmente querem é algum tempo para estudar, praticar e absorver isso.

Instill a culture of learning and excellence

Basicamente, você quer criar "uma cultura de aprendizado e excelência" para que possa praticar o que ensina e inspirar os outros a fazer o mesmo.

Isso deve ser feito em conjunto com as revisões de código para ver se / como os princípios se aplicam ao trabalho real que está sendo feito. Por outro lado, as revisões de código feitas sem acima podem parecer sessões de chicoteamento para o aluno, independentemente de quão bem intencionadas pelo professor.

Todos os programadores devem sempre fazer revisões de código com um programador sênior antes de confirmar / fundir suas alterações de código.

1. Isso dá aos programadores seniores a chance de chegar a um consenso sobre quais estilos eles querem impor (e reconhecer quais são apenas uma questão de preferência) entre si.
2. Isso dá aos programadores juniores uma chance de aprender quais práticas são esperadas de sua equipe desde o início. Dentro de alguns meses, 90% do código que eles escrevem já estarão seguindo essas práticas antes da revisão do código.

Além disso, a maioria dos IDEs possui ferramentas que você pode configurar para impor a grande maioria das preferências de estilo de codificação com sublinhados ondulados e opções para corrigir automaticamente o estilo em todo o arquivo. Os programadores juniores vão aprender muito rápido.

Acho que a melhor maneira de incentivar esse comportamento de desenvolvedores jovens é praticar você mesmo e ser um modelo para eles. Se possível, você deve emparelhar o programa com eles com frequência e enfatizar a qualidade do código ao programar com eles. Durante o emparelhamento, você pode explicar e justificar boas escolhas de codificação à medida que as cria. Você pode explorar as opções "piores" e explicar por que elas não são uma boa solução a longo prazo. Fazer parte desse tipo de desenvolvimento de maneira prática é provavelmente uma das melhores maneiras de ensinar novos desenvolvedores sobre a importância da qualidade do código. Se todos em sua equipe acharem que a qualidade do código é importante, eles também aprenderão a respeitar isso.

Parece que algo tão simples de impor como padrão de codificação só será tratado por:

1. Contrate pessoas que concordam com você.
2. Revisão de código
3. Use aplicativos que podem automatizar essas coisas.
4. O Make faz tanto parte do seu trabalho quanto aparecer. Tem que haver consequências para não fazer o seu trabalho.

Pessoalmente, eu estaria com um gerente que fazia disso uma prioridade. Concentre-se no que é importante e não fique confuso. Você deve ser capaz de justificar o porquê, mas há momentos em apenas escolher um padrão (quem sabe por que um recuo de espaço de 4 é melhor do que 5 a não ser que você está apenas sendo mental).

Obtenha algum consenso de equipe sobre os padrões. Isso irá melhorar a qualidade e o nível de adesão. Não perca muito tempo em um debate. Eventualmente, um líder toma uma decisão com base na quantidade de entrada.

Dê a eles uma unidade de código muito mal escrita para modificar (e testar) e então reescrever (e testar) e então dar a eles uma unidade de código realmente bem escrita com testes unitários para modificar (e testar) e perguntar sobre a experiência.

Depois disso, forneça uma lista de padrões para ler e refatorar seu código (do exercício anterior) para corresponder a esses padrões como prática.

Você precisará de uma documentação organizada de seus padrões antes disso.

Acredito que você não deve ensinar um estilo de codificação específico pelas seguintes razões:

• Os programadores juniores precisam aprender com seus erros. Eles melhorarão continuamente avaliando seu trabalho e fazendo revisões de código com desenvolvedores seniores.

• As diretrizes de codificação variam de acordo com a cultura de uma empresa para a qual você está trabalhando. Eu poderia argumentar contra o que você considera ser um código limpo.

• Os programadores juniores normalmente não têm muita exposição aos sistemas corporativos, e é aí que o código limpo normalmente vive.

• Muitas vezes os professores universitários ficam presos no mundo acadêmico há décadas. Pessoalmente, descobri que suas diretrizes e comentários são um tanto inúteis e ruins em comparação com os padrões atuais do setor. Alguns, claro, são muito bons.

Para resumir:

• Acho que a solução não é ensinar diretrizes específicas ou estilos de codificação, mas tentar explicar sua importância em projetos de vários tamanhos.

• Há tanta coisa que você pode explicar na sala de aula e nos livros.

• Os desenvolvedores terão que sujar as mãos para ver o benefício real por si mesmos.

• Aloque os desenvolvedores juniores para parear o programa, depois revise o trabalho deles e dê a eles feedback. Eventualmente, eles devem começar a ver o benefício.

Não há um estilo de codificação de marca de prata que funcione sempre, como qualquer coisa na engenharia de sistemas.

O problema real é que as pessoas discordam exatamente do código limpo. Uma vez que você tenha escrito o código perfeito com cada detalhe exatamente correto, a próxima pessoa ainda vai pensar que é uma porcaria. Todo programador está olhando para diferentes partes do código e encontrando coisas que ele não gosta enquanto simultaneamente ignora todas as partes boas. Isso é parte necessária da programação, já que os programadores precisam encontrar as coisas ruins antes de ir para o controle de versão pela primeira vez. Assim, os programadores podem facilmente reconhecer o código incorreto. É só que é diferente para todo programador.

Em uma equipe, esse recurso causará problemas, se houver regras muito rígidas para convenções ou se as pessoas precisarem manter e trabalhar com códigos escritos por outras pessoas. A melhor solução é manter as convenções, mas não aplicá-las. E certifique-se de que todos saibam quem é responsável por cada parte do código.

Agora, ensinar programadores juniores é complicado. A maioria das tentativas acaba no programador júnior pensando que seu último código foi de alguma forma ruim e a sessão de ensino é necessária por causa disso. Como se fosse um castigo por algum erro que aconteceu antes.

Se for importante você usar algo como checkstyle e colocá-lo em um gancho de pré-consolidação. Se o checkstyle falhar, o código não poderá ser confirmado. Checkstyle é muito bom em dar mensagens de feedback. As pessoas descobrirão por que seu código não atendeu ao padrão e o que precisam fazer para sobreviver.

Eu aprendi um bom estilo de codificação de um dos desenvolvedores seniores de um dos meus projetos anteriores. Ele revisa meu código para cada commit durante a reunião de revisão de código e ele me explicará linha por linha se algo pode ser melhorado lá.

• Ele passa por cada nomeação das variáveis e métodos e explica como nomeá-los melhor.

• Ele passa por cada método e me diz como tornar mais legível e mais eficiente.

• Ele foi muito educado, mas sua orientação me ajudou muito.

• Demorou apenas três meses para eu me alinhar com ele e agora ele raramente encontra erros no meu código.

Eu sigo o mesmo método de ensinar meus desenvolvedores juniores e funciona.

Clean code and messy code can both lead to identically functioning programs, so does cleanliness matter, and if so, why?

A diferença entre código limpo e bagunçado é tão grande:

• alterar um código confuso é sempre uma tarefa difícil, porque geralmente ele não tem uma rede segura chamada testes de unidade
O código confuso
• tende a ter funções e classes enormes e muito complexas. Tentar entendê-las é inútil e muito difícil
O código confuso
• normalmente tem partes de código copiadas / coladas, aumentando ainda mais a complexidade

Por outro lado, com um código limpo, todos na equipe podem entender facilmente a lógica por trás e adicionar novos recursos sem muito esforço.

Fazer revisões de código

Destaque especialmente os problemas que surgem do estilo de codificação incorreto ou evitados pelo bom estilo de codificação.

Falar muito sobre por que isso é importante.

Dependendo de quão junior seus colegas de trabalho são, perceba que você tem que aprender a escrever código antes de escrever um código bonito.

Uma ideia: mostrar a eles como o código poderia ser visto se não fosse fácil de ler e compreender ( link é um bom exemplo, por exemplo). Pergunte a eles que você gostaria de receber um código como este para manter?

Destaque a importância de

a computer language is not just a way of getting a computer to perform operations ... programs must be written for people to read, and only incidentally for machines to execute.

(citação de SICP )

Eu aprendi programação pela primeira vez ao receber um programa bem escrito e conduzi-lo linha por linha. (Eu aprendi muito nessas poucas horas que eu não tive em todo o meu programa de graduação.) Tente o mesmo com eles, percorrendo um dos seus melhores módulos apontando como e por que ele é construído e estilizado dessa maneira. Você pode fazer isso em uma sessão de grupo.

Se você puder, jogue ditador benevolente. Dependendo do seu sistema de controle de revisão, você poderá usá-lo para ajudá-lo. No entanto, você pode acabar sendo o gargalo no processo de desenvolvimento.

Implante um verificador de estilo automatizado para verificar quantas regras de estilo você puder. (Muitas regras checkstyle devem ser portáveis entre Java e C ++.) Isso fará com que você se separe, mas não substituirá as revisões de código. Fazer com que seus desenvolvedores analisem o código de revisão pode ajudar a reduzir a carga.

Se você implementar um verificador de estilo automatizado, também poderá implementar uma ferramenta de análise de código estático. Isso deve ajudar a eliminar alguns dos erros que podem ser perdidos nas revisões de código. Ele também permitirá que você se concentre em questões de estilo, em vez de procurar os erros que a ferramenta de análise de código estática cobre. Ainda pode haver casos comuns que precisam ser verificados.

Desenvolva uma lista de verificação para os desenvolvedores usarem antes de fazer o check-in do código. Isso pode conter outras coisas que você quer que ocorram antes do check-in. Há evidências crescentes de que listas de verificação podem ajudar a reduzir erros. Incentive os desenvolvedores a criarem sua própria lista de verificação dos erros que costumam cometer, de modo que possam evitar a repetição deles.

Fale sobre a programação alfabetizada de D. Knuth.

I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do

Donald Knuth, about literate programming.

Na minha humilde opinião, o fato de que o principal objetivo de um programa de computador é comunicar entidades intelectuais a outros programadores, é um argumento decisivo para a importância do estilo de codificação.

Eu acho que um aspecto subestimado do estilo de codificação é que ele se manifesta naturalmente. Quando vejo um código-fonte que escrevi há muito tempo, geralmente sinto um desejo irresistível de romper o continuum tempo-espaço apenas para me dar um soco na cara pelas monstruosidades (percebidas) que executei na dita fonte. Já que você está orientando juniores, e eles tendem a aprender rápido (já que precisam), faça a solução mais simples possível: permita que eles escrevam um código ruim (uma vez!), Então faça com que eles o mantenham. As chances são, se eles são bons em engenharia de software, eles vão se arrepender de seus pecados e refatorar o código corretamente. Claro, não divulgue sua coleção de spaghetti como código de nível de produção, tenho certeza de que há muitas oportunidades para fazer um desenvolvedor júnior escrever algo pequeno, quase 'descartável'.

Não há escola de software como a vida real

DRY faz todo o sentido quando você teve que editar essa linha copiada e colada 4 vezes, e você fez isso apenas 3, é por isso que o código cancela a referência a um ponteiro nulo e o aplicativo trava ...
Além disso, a energia que você gastará tentando transmitir 'boas' metodologias para eles provavelmente será muito, e não é certo que eles não a descartarão com um "seja lá o que for", como você apontou.
Portanto, mostre-lhes na prática que o estilo de código é importante, demonstrando sua melhor legibilidade a eles mesmos também.

O software de suporte é muito mais útil para programadores do que eles pensam que é

Eu acho que é outro assunto, mas a maioria das pessoas instintivamente assume que eles escrevem um bom código (eu me declaro culpado). Então consertar a bagunça de outra pessoa pode ser bom para os hábitos de alguém - você não pecaria se acabasse de voltar de férias no inferno, certo (pontos de vista religiosos à parte)?

Eu acho que seria uma ótima maneira de treinar os novos programadores com a técnica de Convenções de Nomenclatura [é o padrão para nomear uma variável, método ou classe]. Para melhor acompanhar o fluxo de programadores que tocam no código, será fácil lidar com isso com o conhecimento dos nomes relevantes usados.

Por exemplo: as variáveis estáticas começam com s,         As variáveis começam com a, etc.,