Se você já é desenvolvedor há algum tempo, com certeza já ouviu falar do termo Clean Code, mas provavelmente ficou em uma estante bem alta do seu Quarto do Saber; a mesma que você usa para guardar livros de capas duras muito bonitas e imponentes de forma a ficarem bem visíveis, mas que está alta demais para que você os pegue e leia.
O que é Clean Code?
Ainda bem que você perguntou! Basicamente, clean code é o que a junção das duas palavras querem dizer mesmo.
O maior problema é o que cada uma delas significa quando são usadas juntas sem um contexto muito claro.
Então, sem mais delongas, a melhor resposta se sua vida dependesse disso seria: ninguém sabe.
Porém, somos desenvolvedores! Trabalhamos muitas vezes na subjetividade. Pense bem:
Aquele código que você fez na véspera do feriado e que tinha que ser entregue para a tarefa daquela sprint funciona? (Eu sei, te peguei).
O próprio Robert diz que “provavelmente devem haver tantas definições [para Clean Code] quanto o número de programadores existentes”.
Nos primeiros capítulos do livro Clean Code: A Handbook of Agile Software Craftsmanship, escrito por Robert C. Martin, o autor traz a definição de Clean Code feita por grandes nomes da computação e, pasmem, apesar de serem geniais elas são pouco objetivas.
Como começar a práticar o Clean Code (Código limpo).
Eu não vou subir lá para tirar o livro da estante!
Sim, eu sei. E é por isso que devemos conversar.
Esse livro nem deveria estar em um lugar de difícil acesso. Eu tenho uma proposta a te fazer, apesar de não ser tão genial quanto as definições já feitas, mas acho que posso te acrescentar em alguma coisa.
Na verdade, a resposta para se encarar algo subjetivo sempre esteve na nossa cara: padronização.
O que fazer quando um cliente chega a nós com uma maneira confusa de operação, garantindo que não há lógica naquela função e que, a qualquer momento, tudo pode mudar e ainda que ele tem a possibilidade de editar um dado como quiser?
Muitas vezes, para nós, isso pode ser uma brecha de segurança ou até mesmo uma dificuldade para apresentá-lo de forma clara no sistema.
Nossa única solução para esta pergunta é a padronização daquele processo. É assim que um bom programador deve pensar.
Quando algo está padronizado, fica muito fácil de ser documentado; se for fácil mesmo, a documentação fica clara e sucinta.
Desta forma, qualquer novo desenvolvedor terá uma curva de aprendizado alta e agradável para aprender os padrões de determinado assunto e poderá segui-los de maneira bem eficaz.
Só que aí a gente esbarra em um outro problema que eu chamo de “Padrão do Pacote de Pão“.
O Padrão do Pacote de Pão (calma, o inception já vai acabar)
Anotar nos pedaços de papel de pacote de pão (lembra?) era algo bem comum há um tempo. Inclusive, algumas dessas anotações viraram memes na época em que eles ainda se chamavam virais.
O problema é que, por mais criativo que seja, essa ideia anotada nunca será
checada e comparada com outras que já estão sendo usadas para a mesma situação em que você já pensou.
E claro, você vai sempre supervalorizar a sua criação sendo um pai ou mãe coruja.
Agora pense nisso em grande escala: Qual padronização pode ser feita para solucionar um dado problema se todo mundo tem seu próprio padrão?
Não é que não pode customizar as ferramentas padronizadas que temos para o nosso cenário. Customização é muito diferente de criação.
Quanto maior ela for, mais nos afastamos de uma ferramenta que, caso se prove ruim, outras pessoas já passaram ou estão passando
pelo mesmo problema e poderão nos ajudar.
Além disso, fazer uso de um padrão amplamente utilizado aumenta a confiabilidade da solução por estar sendo posta em prática em vários cenários e diminui demais a curva de aprendizagem de nós desenvolvedores 😃
Como implantar boas práticas de Clean Code
E é nessa conversa que eu queria chegar! Vamos pular a parte da prática voltada para codificação em si (que talvez fique para um próximo artigo 🤔) e vamos pensar mais no planejamento da coisa.
Tem outro livro que costuma ficar lá na estante alta do Quarto do Saber de cada desenvolvedor: o de Metodologias Ágeis.
Não tem como falarmos de Clean Code sem entrar no mundo dos agilistas.
De fato, no livro Clean Code, o tio Robert realmente vincula os dois implicitamente, ele afirma que “é uma “chamada” para um livro que eu [Robert] escrevi em 2002 intitulado “Desenvolvimento Ágil de Software: Princípios, Padrões e Práticas”. Neste último livro, não tem como foco métodos ágeis, mas acaba tangenciando o assunto.
Existe uma parte que costumamos negligenciar muito durante a maioria das metodologias ágeis: A Revisão de Código, sim o Code Review.
Essa etapa do processo de desenvolvimento é a porta ideal para que as boas práticas de codificação definidas pelos padrões escolhidos pela equipe sejam seguidos e até reavaliados; resumindo: é a hora do Clean Code brilhar.
A Revisão de Código é um ótimo momento para que o desenvolvedor confronte e seja confrontado pelos padrões da equipe. É importante que isso seja feita de maneira saudável de todas as partes.
Todos devem apontar os prós e os contras de seguir, mudar e/ou abandonar um dado padrão de acordo com a situação real exposta.
E por se tratar de algo extremamente real e aplicável ao contexto do projeto (afinal é de fato um problema do projeto) todos os desenvolvedores devem participar, pois assim o conhecimento será passado até mesmo aos que não se envolveram na resolução daquele problema.
Processando conclusão, aguarde…
Clean Code é muito mais que um livro ou uma receita: é uma filosofia.
A grande verdade é que vai fazer pouca diferença se seguir os melhores padrões de codificação e arquitetura de software se a sua equipe não se interessar também.
Não adianta ser um escoteiro, muito menos um caçador de código feio se você estiver sozinho nessa.
Ouça, fale, ouça de novo, demonstre e ouça mais uma vez.
Só assim um padrão sai do pedaço de pacote de pão e vai para um documento oficial da equipe, ou até mesmo vira um padrão bacanudo usado como base por várias outras equipes.
Até a próxima!
Crie um perfil, conheça as oportunidades e receba propostas alinhadas ao seu perfil. São mais de 1000 vagas para desenvolvedores como você!
