Estilo de código como padrão de desenvolvimento

Vamos logo, não se trata de colchetes. Aqui, falaremos sobre como nosso cérebro funciona e por que o estilo de código ajuda a garantir o desenvolvimento linear do projeto, acelera significativamente a adaptação de novos funcionários e, em geral, forma e educa a cultura de desenvolvimento. Tentei coletar em um artigo vários estudos e princípios sobre o trabalho do cérebro do desenvolvedor, e como os programadores leem o código, além de compartilhar os resultados de um experimento pessoal.

Interessante? Bem-vindo ao gato.



Oi Meu nome é Anton, escrevo back-end no ManyChat. Recentemente, tivemos um resumo dedicado ao desenvolvimento do PHP, onde eu falei sobre o estilo do código como um dos padrões de desenvolvimento. No feedback, ele foi bem aos convidados do evento, e decidimos descriptografar o relatório sobre Habr. Para quem aprecia especialmente o efeito da presença pessoal e mais gosta de assistir a um vídeo do que ler textos, transmitimos, que está disponível agora. Você pode encontrá-lo aqui. Para aqueles que amam longrid, sejam bem-vindos.

Nosso cérebro é uma rede neural

Vale a pena começar com uma descrição de como funciona em geral e por que você precisa de tudo sobre o que falarei mais tarde. Muitos de vocês estão familiarizados com o conceito de rede neural, ou pelo menos já ouviram essa frase, que por vários anos tem sido quase um símbolo de hype no espaço e no marketing de TI. Mesmo agora, muitas empresas estão adicionando produtos baseados em IA a seus produtos, como o adesivo "Não OGM" nos bolinhos de massa. A rede neural opera segundo o princípio do reconhecimento de padrões e é extremamente eficaz ao trabalhar com dados homogêneos. São imagens, vídeos, som etc. O destaque que tem a ver com o estilo do código é o princípio sobre o qual eles foram criados. Perceptrons, células de rede, foram descritos como processos cerebrais e estabelecidos muito antes de serem implementados em uma rede funcional, viável e eficiente devido ao baixo poder de computação. Nosso cérebro, embora muito mais poderoso, funciona de maneira semelhante. Como resultado, uma pessoa usa o poder de uma rede neural treinada desde o nascimento até a morte, e o treinamento é quase contínuo.

Então, percebemos apenas imagens. Para o cérebro, não há textos, sons e outras coisas - só percebemos tudo isso após a decomposição. Grosso modo, separamos as imagens “pixel por pixel”, as adicionamos à memória e, com a ajuda do pensamento associativo, reconhecemos vários objetos. Graças a isso, podemos entender se devemos fugir da cobra ou montar uma bicicleta e pressionar os pedais. Aqui está um diagrama de um perceptron padrão, que ilustra como ocorre a classificação dos objetos. Para aqueles que não estão familiarizados com o princípio do perceptron , pode parecer um pouco caótico. Mas, graças a esse esquema de balanceamento e pesagem, a rede neural reconhece imagens de maneira rápida e eficiente.



Na programação, você pode se lembrar do princípio DuckType, quando se acredita que se um objeto nada como um pato, voa como um pato e grasna como um pato, é um pato. Uma aproximação peculiar da detecção de objetos. E para o nosso cérebro, o reconhecimento de objetos acontece instantaneamente. O treinamento é um processo muito mais longo. Portanto, você pode imaginar esse processo, bem como o treinamento de uma criança que só aprende palavras. Você pega uma maçã, aponta e diz: "Esta é uma maçã". Pegue outra e repita novamente: "Esta é uma maçã".



E assim por diante até que o resultado seja corrigido. Verde, amarelo, vermelho, esférico, alongado, com e sem estacas, preto e branco. Ano após ano, a criança constrói sua base com base no conhecimento empírico. Eu acho que o princípio é claro. Fazemos a mesma coisa ao treinar uma rede neural. De objeto para objeto ou, mais precisamente, de imagem para imagem.

Como um programador lê o código

O mesmo acontece quando trabalhamos com código. Abrimos a página, estudamos, decompomos em blocos, identificamos partes diferentes - separamos facilmente propriedades de funções, níveis de isolamento de métodos e propriedades, encontramos constantes e assim por diante. Identificamos tudo isso por blocos e, portanto, um aspecto importante do estilo do código é trazer o código inteiro para o mesmo formulário. Esse é um fator chave que caracteriza a legibilidade do código.

Por que isso é importante? Porque na maioria das vezes, um programador lê código. Alguma correlação direta não foi encontrada; na maioria das vezes, depende de qualificações, idioma (por exemplo, Python é recuado e código estruturado incorretamente simplesmente não funciona), qualidade do código etc. Mas, 50% do tempo leva para ler o seu código e o de outra pessoa. Se o código for complexo, o indicador poderá chegar a 75% e, se o código for realmente ruim, pode ser gasto 95% do tempo lendo e tentando descobrir onde adicionar uma linha para corrigir algum tipo de falha. E agora a pergunta. O que você fará se perceber que seu código gasta 75% do tempo lendo um disco ou alocando memória para listas duplamente vinculadas? O programador tentará otimizar esse processo, alterar o algoritmo, aplicar uma estrutura de armazenamento mais eficiente etc. Assim, quando o tempo gasto se tornou crítico, comecei a inspecionar esse processo. E pode-se dizer, bem, é o cérebro, é muito mais poderoso que qualquer computador e pode armazenar cerca de um petabyte de dados. Mas, no processo de desenvolver minha estrutura mental para trabalhar com código (um processo oculto de formação de hábitos de leitura de código), deparei-me com estudos nos quais sensores monitoravam os movimentos oculares de programadores iniciantes e experientes. É assim:
Iniciante



Experiente



Preste atenção ao que um programador experiente faz. Ele seleciona blocos de código, decompõe-os e os lê em blocos, destacando as principais partes e analisando seu trabalho. O iniciante percorre linha por linha, apenas tentando entender o que está acontecendo aqui. A maior parte do tempo é gasta na montagem do quadro geral e a leitura do código ocorre com constante inspeção cruzada.

O vídeo é bastante antigo, a partir de 2012, e a gravação teve como objetivo estudar os processos do cérebro de um programador. Você pode ler um pouco mais aqui e aqui .

Agora é a hora de voltar à descrição da operação dos perceptrons. Esta é uma demonstração clara do trabalho de uma rede neural treinada e não treinada. Com base em sua base de conhecimento, um programador experiente segue o código como um intérprete, geralmente sem nem perceber. Pode-se abordar a solução desse problema da mesma maneira que abordamos os problemas do treinamento de redes neurais.

Existem duas maneiras de acelerar a leitura de código:

1. Construa constantemente a base de conhecimento de um desenvolvedor sobre a aparência do código. Isso significa aprendizado contínuo, que está constantemente expandindo o poder da rede.
2. Traga todo o código para um padrão, defina o mesmo estilo de código

Obviamente, é bastante óbvio que o primeiro método é muito trabalhoso. Nesse caso, o programador precisa ler constantemente os repositórios. E, dada a rotatividade de pessoal, o surgimento de novas tecnologias e práticas, isso se torna quase impossível. O método de exclusão continua sendo a estilização do código, que reduzirá o efeito da decomposição e deixará apenas o efeito na lógica de negócios.

Número de afinadores de piano

Imagine que uma equipe de 5 pessoas grave, como quiser, em todos os módulos e componentes do sistema, recebendo constantemente tarefas sobrepostas, ajustando o código uma da outra. Qual é o número possível de todas as opções para escrever uma condição se, considerando que cada pessoa escreve à sua maneira? 5. E quantos blocos válidos temos? Todas as construções, chamadas de funções de argumento único e múltiplo, espaços para nome, classes, traços, interfaces, posicionamento de blocos, estática, zonas de visibilidade, etc. Desde que todos usem apenas 1 estilo de escrita, diferente dos estilos de todos os outros. E se uma pessoa tem 10 anos? Que tal 50? É claro que, com um aumento no número de pessoas, a variação diminuirá devido a um número limitado de maneiras de escrever o mesmo bloco. E este é o primeiro nível em que não investimos um dos principais problemas de programação - nomeação de variáveis. O efeito do multiplicador e todas as combinações possíveis nem são levados em consideração. Jogue por cima o estilo de separação, recuo em espaços e abas, amor por macarrão, etc. etc. E novos especialistas estão constantemente chegando e antigos estão saindo. Como resultado, você obtém um enorme código ilegível, impossível de se acostumar e de desenvolver uma rede neural bem treinada de programadores da empresa.

Nosso cérebro é preguiçoso

Outro efeito interessante do nosso processador central no crânio é a percepção extremamente negativa de novas informações. Nosso cérebro é muito preguiçoso. Com uma massa de cerca de 1,5% a 2% do peso corporal total, o cérebro consome 25% de toda a energia corporal. Uma das cirurgias mais intensivas em recursos para o cérebro foi, é e continua sendo uma concentração de atenção. Você pode manter a concentração máxima por 20 a 25 minutos (oi técnica Pomodoro) e, durante esse período, o cérebro engolirá tanta glicose quanto engoliria por um dia inteiro de descanso subjetivo. O processamento de novos dados é um processo extremamente intensivo em recursos. E um dos principais objetivos do cérebro é economizar esses mesmos recursos. Isto é devido ao trabalho do nosso modelo mental. Uma espécie de bloqueador psicológico. Parece algo assim. Você começa a aprender algo novo. É difícil dar algo novo e, devido à falta de dinâmicas tangíveis de progresso, sua auto-estima começa a declinar devido ao pensamento "eu sou estúpido!". Nossa psique é organizada de tal maneira que toda a atitude depende da auto-estima e, por sua vez, depende de nosso sucesso na sociedade. E, para não quebrar os elevadores sociais básicos das dependências adaptativas, nosso cérebro começa a resistir a atividades que reduzem a auto-estima. Como resultado, você quer assistir a uma série de TV, ler um habr, tomar um café, sentar-se em um ambiente social. redes etc. Qualquer coisa, só para não aprender a própria teoria do campo de Landau. Ou conserte um bug difícil de reproduzir. Ou ... leia código de baixa qualidade que é difícil de descobrir. Um ótimo exemplo de como o cérebro se comporta de acordo com as restrições nesta área é de pessoas entre 70 e 80 anos que não querem aprender um smartphone ou dois botões no aspirador de pó robô. Os recursos estão acabando. O cérebro bloqueia desesperadamente o processo de aprendizado e age no polegar. Existem muitos desses recursos quando você é jovem. Com o passar do tempo e o crescimento, eles se tornam cada vez menos. Funciona linearmente. Felizmente, isso é compensado pelo poder crescente de nossas redes neurais. A menos que estejamos falando sobre degradação direta direcionada, é claro.

Alguns estereótipos

Um equívoco comum que você já deve ter ouvido: “Bem, sou profissional, posso ler qualquer código. Escrevo rápido e legal, resolvendo problemas da empresa. E não importa a aparência do meu código, se resolver o problema. O resto simplesmente não consegue descobrir rapidamente, não tenho problemas com isso. " Se você tem um codificador desse tipo em seu ambiente, pode dizer a ele: “Cara, tenho más notícias para você. Você está afetando toda a equipe, e essa abordagem é a razão pela qual outras pessoas escrevem mais lentamente quando um programador super eficiente rapidamente força o código ".

Um programador supereficiente que escreve sem formatação e padronização é supereficiente em duas coisas:

• Super eficientemente feche tarefas sem entrar em design e estilo.
• É supereficiente desacelerar todos os outros, porque, após as adições, as pessoas tentam há muito tempo entender o que aconteceu aqui.

Por que o estilo de código é necessário

Embora isso já deva ser óbvio, é necessário enfatizar de alguma forma os pontos principais.
Estilo do código:

1. Fornece um desenvolvimento linear do projeto e não afeta a quantidade de base de código. Se você forneceu a gravação histórica de código compreensível, não importa quantos desenvolvedores vão e vêm, você sempre tem a mesma qualidade de código, o que permite que o projeto cresça dinamicamente, independentemente do tamanho.

2. Acelera significativamente o processo de adaptação de novos programadores. Se o seu código for escrito claramente, um novo especialista treinará rapidamente sua rede neural para identificar blocos e começará a ser útil. Existe o ponto de auto-suficiência dos funcionários. É nesse ponto que o funcionário começa a trazer apenas benefícios. E se o código for escrito claramente, os novos funcionários não precisam entender a lógica dos negócios, apenas aprenderão a ler seu código. E quanto mais rápido ele faz isso, mais rápido ele para de fazer muitas perguntas a outros especialistas, perdendo o tempo deles. E o tempo dos especialistas que ultrapassaram o ponto de equilíbrio é muito mais caro para a equipe e a empresa em termos do valor potencial do produto trazido.

3. Remove a dependência de detalhes. Você não precisará tropeçar constantemente na originalidade e no design específico de outra pessoa.

4. Minimiza o efeito do bloqueador mental ao aprender um novo código. Seu cérebro é menos resistente porque não há necessidade de se aprofundar no estilo de outra pessoa. Os recursos mentais para ler códigos claros precisam de muito menos.

5. Minimiza as perdas de reputação. Muito em breve, depois de chegar a uma nova empresa, o programador começará a compartilhar suas impressões com ex-colegas e amigos. E ele dirá que tudo é legal aqui ou destacará os aspectos negativos ao trabalhar com o código. De certa forma, isso oferece um bônus de RH: se você deseja que programadores legais trabalhem com você, faça um bom projeto. Embora isso nem sempre seja importante, e em algumas empresas eles não consideram a qualidade do código em princípio, mas apenas a entrega de recursos às vendas, esse é um bônus interessante. Não é segredo que uma razão frequente para sair é a fadiga do corte constante de uma base de código de baixa qualidade.

6. Forma e promove uma cultura de desenvolvimento. A tarefa do programador está em um nível inferior ao futuro de toda a empresa, mas é importante transmitir o entendimento de que a compreensibilidade e a legibilidade do código agora afetam a dinâmica do desenvolvimento futuro. Se o código é difícil de ler e não é padronizado, pode ser refatorado e dimensionado com dor e sofrimento, então com o crescimento da base de código do projeto, a velocidade de desenvolvimento diminuirá. Quanto mais código de baixa qualidade, mais difícil é escrever um novo, mais lento é o desenvolvimento de um produto, mais difícil para uma empresa aumentar o impulso e mais difícil é pagar mais dinheiro, porque muito dinheiro é gasto em fornecer o ciclo de vida do projeto a novos e novos funcionários, que é o principal eles gastam tempo integrando não em como beneficiar a empresa, mas na classificação dos medicamentos sob os quais esse código foi escrito.

Código perfeito

Todos nós entendemos que isso não existe. Do ponto de vista do estilo de código canônico, está o conceito de design de código. E tudo ficaria bem se isso fosse verdade. No desenvolvimento do estilo de código de longa distância conceito mais espaçoso, que inclui os princípios de desenvolvimento. A divisão de código em blocos isolados logicamente em classes ou arquivos também se refere ao design. Nomeação, níveis de isolamento, herança. Todas essas ferramentas não são apenas interação, mas também o design do seu mecanismo complexo, onde cada tijolo desempenha um papel.

Os conceitos mudam de idioma para idioma. Detalhes vêm à tona. Mas a fundação permanece inalterada. Um código de qualidade é determinado por apenas dois critérios:

• Código é anônimo
• O código parece um livro

Código anônimo

O estado ideal que você precisa apresentar nesse processo é chamado código anônimo. Estou certo de que muitos de vocês, tendo aberto um rascunho de trabalho e um componente aleatório, podem dizer sem problemas qual dos colegas escreveu isso. Todo mundo costuma ter um estilo. Alguém gosta de macarrão se, alguém com e sem estalar lambdas, alguém gosta de reduzir variáveis ​​para salvar um caractere. No código anônimo, você não pode fazer isso. Em um código despersonalizado ideal, é impossível identificar o autor. E é esse o caso quando você chegou ao ponto final do seu estilo de código.

Legibilidade no nível do livro

Lembrar 2 problemas principais de programação? Invalidação de cache e nomeação de variáveis. Vamos ignorar o passado sombrio dos processos de cache e ir direto para a nossa dor. Nomeando variáveis, classes, objetos, arquivos, métodos, constantes e assim por diante. Este problema tem 2 extremos. Nomes muito curtos e muito longos. O senso comum nos diz que a lógica está em algum lugar próximo, próximo ao meio. Aqui, programadores super eficientes batem à nossa porta e nos dizem que não se importam. Mas por que devemos teorizar sobre isso? Diga-me o que esse código faz?



E esse aqui?



O segundo código é lido diretamente e facilmente. Não é necessário entender realmente a lógica de negócios para entender a carga funcional com essa nomeação. Neste exemplo, apenas pegamos o repositório inteiro, usamos o construtor para criar a coleção e aplicamos o filtro. Você nem precisa se aprofundar no código para entender o que está acontecendo. Como ler um livro sobre manchetes. Mas nomear não é tudo.

Padrões de design

Você é questionado sobre os padrões de design em quase todas as entrevistas. Seu objetivo público é uma solução arquitetônica repetível. Seu efeito colateral é previsibilidade e consistência. No momento em que você muda para uma arquitetura baseada em padrões de design, forma um sistema bastante previsível. I.e. com base no nome, você entende facilmente o objetivo da classe ou objeto. O que o padrão do Repositório faz? Esta é uma visualização de repositório com métodos de aquisição de dados. O que o padrão do construtor faz? Monta um objeto ou estrutura complexa. E assim em todas as frentes.

Existe um padrão como Command. O que pode ser feito com isso? Claro, apenas execute! Você não precisa estudar o que está dentro dele. É claro que isso pode ser feito. Os padrões de design ajudam a entender como o seu projeto funciona. Se você escreveu tudo bem, não se perguntará: "O que há nos meus diretórios?" Pelos nomes, você pode determinar facilmente o que e onde está localizado.

Vamos apenas dizer isso. Todas as decisões sobre os padrões de design foram formadas, tendo como base a dor do desenvolvedor em um problema específico. Essa dor já foi sentida por alguém, enquadrada e conseguiu sua solução na forma de um dos modelos arquitetônicos existentes. Além disso, tudo isso foi formado em cima do notório SOLID.

SÓLIDO

SOLID é um acrônimo dos cinco princípios da programação orientada a objetos. Nota: 5 princípios. Orientado a objetos. Programação Isto não é uma prática. Esta não é uma recomendação. Este não é o desejo de algum programador antigo de ensinar jovens. , SOLID — . SOLID, 6 , , SOLID — . , , . — . , , : , , . . , .

? ? . , . code style, , SOLID. . . . — -. I.e. , , , , , , . , .

, code style community . , , , , . , . , . , . , .

code style? ! . , . , . . - open-source based . , PSR , - . symfony2 code style, PSR . , , PHP. , , .

?

, , ? — , , CodeStyle , . , PHPStorm , phpcs codestyle — . , . , , , .

, (), . , ? . . , . 2 Google Sheets . 23% . , 7 , , 20 . . , 20 . 21% . , , .

, , , , 90% , . ? Middle PHP Developer . onboarding , 3-. … - . . onboarding -, , . , 1- Junior PHP Developer. « » . success story.

, , , 25%, onboarding' ⅔. « » , . , . , , , phpstorm Sonar Light.

— , Senior , , . , , . Senior QA Engineer .

, 21-27%. , , - . , 5%, 5 ( , ), 5 69 . , 14 840 – 40 /. phpcs phpstorm? , 50 .

PS: , , ManyChat, .