Eu duvido que você, desenvolvedor, nunca se deparou com um fonte mal construído, que só de pensar em ter que dar manutenção tinha vontade de trocar de profissão. Os famosos, “não mexe pois funciona assim faz tempo“, “mas eu adicionei apenas um comentário, como foi parar de funcionar ?”, ou até mesmo, “o cara que desenvolveu isso não está mais na empresa“.
Essas dentre outras frases são mais corriqueiras do que vocês podem imaginar. Apesar de não aparentar, situações como as citadas anteriormente podem contribuir diretamente para a saúde de um projeto, sua saúde mental e consequentemente na insatisfação do cliente. Pensem no desconforto dos membros de um time de desenvolvedores ao serem alocados para realizar uma manutenção (por menor que ela seja) em uma determinada funcionalidade que esteja mal escrita? Este sem dúvida é um dos piores pesadelos (causadas pelo próprio time) que nós escritores de código movidos a café podemos ter.
Sim pessoal, temos em nossas mãos todos os ingredientes necessários para que um projeto fracasse, não é mesmo??
Mas em 2008, através do livro “Clean Code: a Handbook of Agile Software Craftsmanship” escrito por Robert Cecil Martin (Uncle Bob) foram apresentadas técnicas para reverter esses tipos de situações.
Afinal, o que é Clean Code?
Clean Code é uma técnica de desenvolvimento que consiste em fazer um código ágil, simples de ser escrito e mais fácil ainda de ser entendido, empregando os conceitos de que: para que um software esteja bem escrito todas as funcionalidades devem possuir uma única responsabilidade, sua leitura seja de fácil compreensão e sua manutenção não poderá impactar em outras funcionalidades já existentes.
Em seu livro, Bob procura destacar algumas boas práticas de uso do Clean Code visando o bom funcionamento de seu programa. Vejamos agora quais são elas:
- Seja o autor do seu
livrocódigo: engana-se quem acredita que escrever um código não é semelhante a escrever uma história. Um código precisa ser coeso, precisa ser de fácil interpretação para outras pessoas e não só para computadores. Para isso você se apegue a escrever funções pequenas e coesas (como capítulos e subtramas presentes um livro) - Nomes importam SIM: é importante definir um nome claro e objetivo, seja para uma variável, uma função ou até mesmo nome de um arquivo, sem se preocupar com seu tamanho. Nomes extensos muitas vezes podem apresentar uma ideia muito mais coesa.
- Regra do escotismo: “mantenha o ambiente mais limpo do que quando encontrou”, o mesmo se aplica a manutenção de um fonte. Não é porque o fonte por si só é um emaranhado de código que você vai contribuir para que essa monstruosidade cresça cada vez mais. Faça sua parte, procure deixar o código (ou pelo menos parte do mesmo) mais limpo do que quando o encontrou.
- D.R.Y.: DRY (don’t repeat yourself) ou, não repita si mesmo. Determina que um programa bem escrito não deve ter funções parecidas ou simplesmente copiadas e coladas onde uma difere da outra em pequenos aspectos. Afinal, como num livro um capítulo não pode ser igual ao outro.
- Comentários mentem: um bom programa não necessita de muitos comentários, ele por si só deverá ser de fácil entendimento. Se um fonte precisa de muitos comentários é porque algo está errado, concorda?
- Testes devem ser isolados: Um código só é considerado limpo após passar por todas as possibilidades de execução, correto? Esses testes devem garantir a integridade do programa, e um programa bem escrito deve ser capaz de fazer com que suas funções sejam testadas de maneira isolada, afinal, estamos falando de funcionalidades com comportamentos únicos.
- Trate os possíveis erros: mesmo quando tudo aparentar caminhar para um possível erro, o programa deverá continuar sua funcionalidade. Use e abuse da tratativas de erro em seu programa. O usuário não é obrigado a se deparar com aquela pilha de chamadas jogadas em sua cara.
O processo de aprendizado e aplicação do Clean Code na rotina de um desenvolvedor é constante. Não pensem que é um processo ágil, pois como toda cultura leva-se tempo para domina-la. Um desenvolvedor que possuir essa skill aumentará seu nível técnico de maneira formidável.
Como utilizar o Clean Code em meu dia a dia?
O ponto de ignição para adotar essa prática é alinhar a expectativa com todo o time de desenvolvimento, expor todos os benefícios por ela trazidos bem como as dificuldades que serão enfrentadas no início de sua implementação, evitando assim, ocasionar maiores problemas na construção de novas funcionalidades, tempo e qualidade da entrega. Uma vez que essas etapas estejam alinhadas passaremos para o próximo passo, “do como fazer?”.
Aqui vão algumas dicas de como iniciar essa transição junto ao time (lembrando que cada linguagem de programação deverá seguir sua convenção).
Funções
É de extrema importância adotar uma padrão para nome de Funções, seja ele o Camel Case, Upper Case ou qualquer outro tipo. Mais do que isso, é importante que a função a ser escrita possua um nome claro e objetivo (evitando abreviações) , e que ela se limite apenas a fazer aquilo que deve ser feito.
Há quem diga que funções devam ser escritas no infintivo, ou seja, terminadas por -ar, -er ou -ir (-or no caso do verbo pôr).
Um ponto que costuma gerar dúvida na comunidade é: “devo criar funções em português ou inglês?”. E a resposta que vos digo aqui meus amigos é a seguinte: Depende. As convenções de linguagens populares sugerem o uso de funções em inglês, pois acreditam que a nível semântico fica “estranho” misturar dois idiomas no código: imaginem algo como “function calcularNota”. Soa um pouco estranho não?
Mas aqui vai a justifica da minha resposta: Antes de determinar a forma a ser escrta, deverá ser discutido com o time o nível técnico de cada um sob o idioma escolhido (no caso o inglês). Imaginem que em um time de 8 devs apenas 3 tenham conhecimento em inglês? O que era pra ser algo simples acaba se tornando dificultoso para os demais, pois imaginem só a cada function você ter que procurar na internet o significado de algum termo? A dica que eu dou nesse tópico é: alinhe com o time antes de determinar o padrão a ser adotado, pois sempre haverão pontos de vistas diferentes do seu.
Variáveis
Devemos seguir o mesmo conceito utilizado no tópico anterior. Utilize nomes claros, que se comprometam a fazer aquilo que lhe foi designado, lembrando sempre de inicializá-las. Não tenham medo de variáveis com nomes longos.
Notem que nesse exemplo, pode gerar dificuldade de interpretação, afinal a variável cNumPed refere-se a um pedido de compra ou a um pedido de venda?
Responsabilidades
Toda e qualquer função deverá se responsabilizar apenas por aquilo que ela realmente deve fazer, ou seja, ter um comportamento único
Comentários
Evitem comentários demasiados em seu código. Se seu código possui muitos comentários talvez esteja na hora do mesmo passar por uma revisão, e por que não uma refatoração? Lembrem-se: um bom programador desenvolve para outros programadores.
Bom pessoal, o objetivo desse post foi apresentar a vocês e passar de uma maneira simples as diferenças de um código utilizando Clean Code, e outro não utilizando.
Caso queiram se aprofundar mais no assunto sugiro a leitura do livro escrito pelo Robert Cecil Martin citado acima.
Até a próxima galera!
Include Brasil 
Parabéns pelo conteúdo! Que tenham muito sucesso nessa caminhada. Vai ajudar bastante a comunidade.
Grande Caio!
Muito obrigado pelo apoio brother. Estou a disposição para ajudar.
Abraços