👨‍👦‍👦 🚣🏿 🔻 O que é o "código limpo" em 2020? 😷 😣 ❕

^{"Código limpo" e um gato limpo}

Não alimente pão para desenvolvedores, vamos discutir sobre a limpeza do código: por exemplo, o post de Dan Abramov "Adeus, código limpo" causou polêmica recentemente .

Mas, ao mesmo tempo, o próprio conceito de "código limpo" não tem uma definição clara. O livro principal sobre esse assunto é "Código Limpo" , onde Robert "Tio Bob" Martin declara imediatamente: "quantos programadores, tantas definições". No entanto, a partir disso, ele não conclui “falar sobre isso é inútil”, mas a conclusão “vale a pena comparar diferentes definições”. Portanto, no livro ele citou as opiniões de vários programadores importantes sobre o que é um código limpo.

Tornou-se interessante para nós: em 2020, as idéias da humanidade sobre código limpo permaneceram as mesmas ou elas mudaram de alguma forma desde o lançamento do livro? As opiniões de diferentes especialistas em TI diferem: talvez os backenders vejam tudo de um ângulo e os testadores de outro?

Em abril, o tio Bob voará para São Petersburgo para falar em nossas três conferências, e eles estarão em apenas três direções diferentes ( sobre desenvolvimento .NET , testes e JavaScript ). Portanto, perguntamos a vários palestrantes dessas conferências o que é um código limpo para comparar as opiniões de especialistas do setor em 2020.

E como o tópico é oco, com certeza um de vocês não concorda com nenhuma das opiniões. Nesse caso, vamos discutir nos comentários, isso também é divertido!

UPD: , . , . - . . 13 , .

DotNext

John é uma lenda do Stack Overflow, autor de C # in Depth e um dos doadores mais famosos do planeta. Ele nos deu a seguinte definição:

“Para mim, código limpo é um código chato, do ponto de vista da implementação. A única surpresa nele é o quanto ele é desprovido de surpresas. Eu tenho que sentir, "Sim, eu poderia escrever isso", mesmo que eu realmente não pudesse - pelo quão bem projetado ele é.

Quando a abstração é escolhida corretamente, a implementação é derivada naturalmente. Idealmente, essa abstração também deve parecer simples e óbvia - embora, de fato, levá-la a esse estado possa levar horas, semanas, meses de reflexão e experimentação.

A falta mencionada de surpresas mais tarde continua a ser usada: quando escrevo código usando uma API bem projetada, meu código também se torna óbvio e chato ".

Andrey Akinshin

Os visitantes do DotNext não precisam apresentar Andrei, mas, pelo resto, contaremos que ele é conhecido por seu trabalho no IDE Rider , na biblioteca BenchmarkDotNet , em relatórios vívidos e no livro "Pro .NET Benchmarking".

Quando perguntamos o que ele pensava sobre código limpo, Andrei se referiu a dois de seus antigos habraposts: “Código perfeito e projetos reais” e “Comentar ou não comentar” . E selecionamos para você alguns parágrafos a partir daí, com os quais alguém provavelmente desejará discutir:

“Eu amo o código perfeito. Afinal, essa não é apenas a abordagem correta para escrever programas, mas também uma arte real. Ao ler uma boa lista, tenho tanto prazer quanto ler um bom livro. Projetar a arquitetura de um projeto grande não é mais fácil do que projetar a arquitetura de um prédio grande e, se funcionar bem, o resultado não será menos bonito. Às vezes, me fascina como padrões de design graciosamente entrelaçados na criação de um sistema de software perfeito. Admiro a atenção aos detalhes quando absolutamente todo método é tão simples e direto que afirma ser o exemplo clássico de código perfeito.

Mas, infelizmente, todo esse esplendor está dividido em dura realidade e projetos reais. Se estamos falando de um projeto de produção, os usuários não se importam com o quão bonito é o seu código e com a qualidade da arquitetura, eles se importam para que o projeto funcione bem. Mas ainda acho que, de qualquer forma, você deve se esforçar para escrever corretamente, só que não deve haver fanatismo. ”

Dylan Beatty

Habrachitateli pode se lembrar de Dylan em seu relatório pensativo e vívido sobre o trabalho com código legado: para Habr, fizemos sua decodificação . E quando nos voltamos para Dylan sobre código limpo, ele escreveu um texto tão detalhado e atencioso que o publicou em pelo menos um post separado:

"É interessante para mim que o conceito de" código limpo "tenha se espalhado muito além do círculo de pessoas que leram o livro de Robert Martin. Conversei com muitos desenvolvedores que ouviram as palavras "código limpo", mas não leram o livro. Eu até os conheci em um codrev: "Tudo está muito bom aqui, mas você pode limpá-lo um pouco?" - e esse pedido pode ser irritantemente impreciso se não for óbvio o que "puro" significa neste contexto específico.

Em inglês, muitas vezes são encontradas palavras juntas - "limpo", "arrumado", "organizado", "arrumado" - e para mim, como falante nativo do inglês, todas significam coisas ligeiramente diferentes. Eu acho que é útil considerar algumas conotações dessas palavras em relação ao desenvolvimento de software.

Imagine, por exemplo, a cozinha de um restaurante. A palavra limpo neste contexto terá conotações muito específicas. Tudo é lavado, esterilizado, não há ameaça de infecção devido a alimentos crus e similares.

Mas isso não significa automaticamente que tudo está bem organizado aqui. Se você já tentou cozinhar com um amigo ou em um apartamento alugado no Airbnb, sabe como é chato quando as coisas estão fora do lugar. O detergente para lavar louça está no buffet, no qual você espera ver panelas, e o espremedor de alho geralmente não está claro onde. Sim, tudo está limpo - não há ameaça de que alguém goste de comida cozida nesta cozinha - mas trabalhar nessas condições é irritante.

Agora imagine uma oficina de carpintaria. Nesse local, a sujeira também pode causar problemas, mas aqui você não tem a mesma definição de “limpeza” que na cozinha. Você pode limpar o cinzel até que comece a brilhar, mas é improvável que você corte salsichas com ele. Portanto, a palavra "limpo" pode ser muito subjetiva.

Mas para mim, palavras como "arrumado" e "organizado" funcionam em contextos em que "limpo" não funciona muito bem. "Organizado" significa que alguém pensou cuidadosamente sobre como organizar os elementos de um local de trabalho específico, e "organizado" significa que esses elementos estão realmente nos lugares que lhes são atribuídos. Como diz o velho ditado, "tudo tem seu lugar e tudo está em seu lugar".

Talvez, no caso do código, devêssemos pensar nas palavras “limpo” , “arrumado” e “organizado” como três conceitos diferentes. "Limpar \ limpo"significa que você olha para os componentes da base de código - métodos, funções, interfaces - e não vê motivo para preocupação. Na nomeação, aderir às convenções; nomes de variáveis e métodos são escritos sem erros; em detalhes como recuos e colchetes aderem a um único estilo; onde quer que você olhe, você vê evidências de que, no nível básico, isso está sendo conduzido por pessoas que levam a sério os negócios. É o oposto de um "código sujo" - um código em que muitos erros de digitação, chaves e recuo são desejáveis nos nomes, nomes de arquivos inadequados. Essas são as coisas que são corrigidas magicamente quando você chama a ferramenta de limpeza de código em algo como ReSharper.

"Organizado"- É sobre arquitetura. É sobre como você pode mergulhar em uma base de código desconhecida e encontrar as coisas que espera vê-las. As interfaces e os limites do domínio ajudam, não interferem; os métodos e variáveis nomeados não são apenas nomeados corretamente do ponto de vista do idioma, mas também refletem o idioma único da empresa com a qual você trabalha.

E “arrumado” é respeitar as convenções locais ... uma base de código na qual você pode encontrar as coisas certas nos lugares deles, mesmo que o modelo organizacional específico não esteja muito claro para você naquele momento.

Eu acho que quando eles falam sobre a luta por "código limpo", isso geralmente significa todas essas três coisas. Mas definir a meta para ser completamente "código limpo", especialmente ao trabalhar com um projeto legado complexo, pode ser uma perspectiva bastante assustadora. Talvez seja útil para todos nós pensar um pouco mais profundamente e descobrir em qual dos componentes do "código limpo" será realmente útil o projeto em que estamos trabalhando atualmente ".

Heisenbug

Esta é uma "conferência de teste, não apenas para testadores": está na interseção de teste e desenvolvimento. Portanto, muitos de seus falantes entendem as especificidades de ambos os mundos ao mesmo tempo.

Ivan Krutov e Anna Chernysheva

Ivan e Anna trabalham em empresas diferentes, mas algo as une: ambas sabem muito sobre o Selenium. Conversamos com eles ao mesmo tempo, e obtivemos uma definição conjunta:

Ivan: “Para mim, a definição mais simples de código limpo é um código que é compreensível sem comentários,“ auto-documentado ”. Código repleto de comentários que tentam explicar o que ele faz não é um código puro. ”

Anna: "Parece-me: este é um código que você pode descobrir rapidamente, consertar um bug, expandi-lo facilmente, complementá-lo."

Ivan: "Você também pode dizer que este é um" código pelo qual você não tem vergonha ". Geralmente eles dizem que se você olhar o código que escreveu há seis meses e não estiver aterrorizado, não estará desenvolvendo. Acontece que todo ano seu código deve ficar mais limpo. ”

Sebastian Dashner

Sebastian é o Lead Java Developer Advocate da IBM e geralmente pode ser visto em conferências Java. Mas como ele está voando para Heisenbug agora, perguntamos a ele sobre código limpo no contexto dos testes, e ele respondeu:

“Na minha experiência, a qualidade do código é importante não apenas no caso do código de produção, mas também nos nossos testes. Nos testes, o código limpo, as abstrações corretas e a delegação geralmente são negligenciados, o que leva a um código de teste que você não pode oferecer suporte. Quando refatoramos o código de produção e alteramos seu comportamento, fica claro se fizemos um bom trabalho na modelagem e implementação de nossos testes. ”

Andrey Lushnikov

Andrey está trabalhando em uma ferramenta de automação de navegador Playwright, sobre a qual escrevemos recentemente . Sua definição acabou sendo a mais concisa:

“Código limpo é código idiota, muito compreensível. E quanto mais burra, melhor.

Alexandra Svatikova

Alexandra é especialista em segurança da informação em Odnoklassniki, que "começou na área de TI como desenvolvedor de Java, mas virou o caminho errado". Sua definição acabou sendo:

“O código puro tem três propriedades: outro desenvolvedor pode lê-lo e compreendê-lo facilmente, pequenas melhorias exigem um esforço proporcional e o efeito de uma alteração específica pode ser previsto.

De fato, isso significa que o código é estruturado, conciso, segue práticas geralmente aceitas para o idioma em que está escrito, não contém dependências implícitas ou efeitos colaterais e é coberto por testes. ”

Holyjs

Andrey Melikhov

Andrei é conhecido por muitos pelo projeto Devshakhta . Não é de surpreender que uma pessoa que constantemente formula seus pensamentos no Podcast Devshacht tenha declarado claramente sua posição:

"Robert" Tio "Martin com seus três livros principais (" Código Limpo "," O Código Limpo "e" Arquitetura Limpa "), Parece-me que ele está tentando responder perguntas para si mesmo: quem, o que e como deve escrever. Pode-se argumentar sobre a correção de algumas de suas conclusões, mas aqui está o que é incontestável: esses livros são baseados em rica experiência pessoal e bom senso. E dentro da estrutura dessa idéia, posso dizer que para mim um código limpo é um código que seria escrito por uma pessoa que tropeçou em um número considerável de armadilhas em sua vida e nesse doloroso processo aprendeu a andar com uma marcha cuidadosa que permite que sejam evitadas.

Você pode não se sentir confortável com o estilo dessa pessoa, mas se você a seguir, certamente permanecerá intacto. Você pode pegar esse estilo e reciclá-lo, tornando-o conveniente para si mesmo. Ou você pode mergulhar desesperadamente no rio para encher seus próprios cones, desenvolver seu próprio estilo, enquanto o resto o encarará com descrença, movendo-se sob a supervisão de camaradas mais velhos.

Código puro é um código fácil de ler, de manter e de estender. São esses três aspectos que estabelecem uma base sólida para aplicativos que precisam viver por anos diante de requisitos externos voláteis. Ou seja, esses aplicativos que escrevemos em grandes empresas "

Alexandra Kalinina

Alexandra é membro do comitê de programa do HolyJS, ela tem uma vasta experiência em programação - e, embora não esteja na Heisenbug, ela também conhece os testes em primeira mão (unidade, integração, E2E, B2B). Aqui está o texto dela:

“O código limpo agora é um conceito simples, mas é bastante difícil de entender. Parece-me que o código limpo pode ser obtido observando as seguintes regras:

- cada código individual deve poder escalar ou crescer / melhorar independentemente de outras partes, mas ao mesmo tempo reter a ideia / integração original com outras partes (o SOLID ajuda muito e também a regra “todas as decisões que possam ser tomadas posteriormente devem ser tomadas posteriormente”).
- O código deve ser lido como um livro fascinante, com nomes e designações típicos compreensíveis. Por exemplo, se você decidir escrever uma história, ela provavelmente terá uma estrutura típica como uma introdução, um enredo, um clímax e um desenlace. Mesmo se você for o único a trabalhar em um projeto, o código deverá ser facilmente lido por você depois de qualquer momento, independentemente da arquitetura, idioma ou estrutura escolhida.
- O código deve ter uma estrutura clara. Essa. a razão pela qual esse ou aquele trecho de código está no projeto deve ser entendida.
“Cada linha de código deve ser justificada da perspectiva dos negócios”

Nicolò Ribaudo

Nicolo, ainda estudante, se tornou um dos principais desenvolvedores do compilador Babel (já perguntamos a ele sobre isso separadamente). Sua versão acabou sendo a seguinte:

“Um código limpo é um código que pode ser facilmente dividido em pequenos componentes atômicos.

“Atom of code” é o menor conjunto possível de instruções que tem significado independente e não depende desnecessariamente do contexto circundante: os nomes das variáveis e operações são descritivos o suficiente para que o leitor não precise alocar memória adicional em sua cabeça para armazenar seus valores e possíveis modificações, além de não era necessário procurar outro lugar no código para entender o que significa o resultado desse "átomo". Quanto menores os átomos, mais fácil é entender o que o código faz.

O código pode ser limpo independentemente da linguagem ou paradigma de programação: os átomos podem ser implementados como pequenos objetos, funções ou até mesmo como pequenos pedaços de código que não são sintaticamente isolados ".

Conclusão

Finalmente, quando as opiniões foram coletadas, nós as mostramos ao tio Bob e perguntamos se ele queria dizer alguma coisa. A resposta acabou sendo:

“Apoio totalmente os comentaristas acima. Eu acrescentaria apenas uma coisa que Michael Feathers disse uma vez: "Um código limpo sempre parece que foi escrito por uma pessoa que se importa".

Sua conclusão parece muito amigável. Mas o código limpo é um tópico tão discutível que, enquanto um de vocês concorda, alguém provavelmente está pegando fogo, sentindo algo como isto:

« : „ , ”. , , : . , !»
« „ ”? „” , — , , „” — !»
“As palavras“ você pode encher a barriga enquanto os outros parecem perplexos ”soam depreciativas, como se apenas os tolos o fizessem. Mas tudo de melhor e inovador aparece quando você enche seus cones e entende as razões deles, e não apenas segue livros antigos! ”

UPD 12 de março: Embora o tio Bob não possa voar até nós, nossas conferências em São Petersburgo ( para desenvolvedores .NET , testadores e desenvolvedores JavaScript ) provavelmente não disputarão código limpo. Nos locais das conferências - sempre versões atualizadas dos programas. Fique ligado e assine nossos boletins - uma vez por semana, falaremos sobre as mudanças.

O que é o "código limpo" em 2020?