Boneco segurando uma vassoura, varrendo a sujeira.

Manter é Preciso, Mexer não é Preciso

Todos os anos, milhões de linhas de código são escritas e muitas outras milhões precisam ser lidas, entendidas e alteradas. Ao mesmo tempo, diversos novos programadores chegam ao mercado de trabalho em uma proporção bem maior do que em outras profissões. A maioria dos programadores tem menos de seis anos de experiência [1]. Adicione a este cenário a distância do que se aprende nas faculdades com necessidades práticas das empresas e projetos de software. Assim, teremos uma das características mais marcantes de nossa atividade: A dificuldade crônica de entender e manter códigos fonte legado e algumas vezes, até mesmo, recém criado. De forma muito simplificada, podemos entender “Clean Code” como uma tentativa de resposta para esse problema quase onipresente: ler, entender e mexer em código escrito por outras pessoas.

Dessa forma, “Clean Code” é uma filosofia, um guia ou conjunto de boas práticas para escrever código de forma que ele possa ser lido e entendido por outros programadores.

O termo “Clean Code” foi cunhado com a publicação do livro homônimo de Robert C. Martin em 2008. Desde então, esse livro é a referência absoluta sobre o assunto. Neste artigo serão apresentados os conceitos e ideias por trás do livro, bem como a análise de quão atual é este assunto. Especialmente em um momento de adoção de novas linguagens, tecnologias e paradigmas.

A Realidade é Dura

Para entender as forças que levaram a publicação deste livro e de outros do mesmo tipo é preciso perceber que toda equipe de desenvolvimento de software, em menor ou maior grau, enfrenta problemas semelhantes. Livros na mesma linha como “O Programador Pragmático” tentaram justamente definir algum caminho por onde estas dificuldades podem ao menos ser conhecidas e idealmente superadas.

Contudo, o cenário onde o processo de desenvolvimento de um produto vai sendo deteriorado em relação ao seu início é mais comum do que gostaríamos. A percepção da distância entre um modelo ideal de produção de software e o ambiente “real” é muito frequente ou até mesmo uma constante no dia a dia de um desenvolvedor. Este cenário pode ser ilustrado na figura a seguir.

Ciclo vicioso da dívida técnica

Você pode até nunca ter ouvido falar sobre dívida técnica, mas se você trabalha como programador, muito provavelmente já sentiu seus efeitos. Como a figura mostra, é difícil saber onde começa e termina o problema. Esta é uma situação onde há grande interdependência entre causas e consequências, ora uma coisa sendo causa de outra e ora sendo a consequência como num ciclo vicioso.

A Realidade é a que Fazemos

Apesar do livro trazer vários capítulos com conceitos e dicas técnicas, logo no início ele dá o tom do que vem a ser a cola entre todas as boas práticas e recomendações apresentadas: A atitude do desenvolvedor. A forma “certa” de fazer software de nada adiantará se o programador não se dispuser a praticá-la. Com lógica idêntica ao ciclo vicioso da figura anterior, o aprendizado e adoção de boas práticas dentro de um processo de desenvolvimento vai aos poucos causar efeitos. Na figura a seguir podemos ver este efeito no “Ciclo da Eficácia”.

Ciclo da Eficácia

Certamente, a aplicação de todas as boas práticas e dicas do livro desde o início de um projeto, antes que ele entre em um ciclo vicioso de dívida técnica, é o melhor cenário. Contudo, no livro, Robert Martin apresenta a metáfora da “Regra do Escoteiro”. Basicamente, o programador deve comportar-se com o código da mesma forma que os escoteiros fazem com o terreno onde acampam: Eles deixam o lugar mais limpo do que encontraram. Esta pequena atitude pode ser instanciada na figura do ciclo da eficácia. Um desenvolvedor que gaste um pouco mais de esforço em fazer um código mais limpo, produzir alguns testes de unidade ou simplesmente refatorar o código para melhor estará alimentando o ciclo virtuoso e, com algum tempo, verá o retorno.

Clean Code: O Ponto de Partida

No capítulo 12, o livro avalia, a partir das quarto regras do design simples, duas práticas como transversais e vitais para o desenvolvimento de software: Testes e Refatoração. De fato, o desenvolvimento de software moderno não sobrevive muito tempo quando estas práticas são ignoradas. Com foco em mais entregas e com o máximo de valor agregado, os projetos de software precisam iniciar mesmo diante de incertezas. Em uma abordagem ágil, inclusive, isto é parte da natureza do processo (abraçar mudanças).

Assim, um software que não passa por refatoração constante terá grandes dificuldades. A refatoração por sua vez requer uma garantia de que novos bugs não sejam inseridos neste processo bem como necessita que o desenvolvedor sinta-se seguro. Consequentemente, é mandatório que existam testes de unidade com boa cobertura para que um esquema de integração contínua seja minimamente possível. Contudo, fazer teste em código “sujo” e difícil de ser entendido é uma tarefa que costuma ser abandonada em função de seu custo por benefício. Este é um cenário da maioria dos projetos de software que não compreendem esta cadeia de dependência, mas são impactados por ela. Em muitos casos, uma equipe que não consegue praticar testes de unidade e/ou refatoração pode simplesmente estar ignorando os conceitos de código limpo.

Clean Code como Ponto de Partida

Não se pode atacar entregas, satisfação e valor como ponto de partida em um cenário já deteriorado. Assim, o melhor ponto de entrada nesta cadeia interconectada é dedicar-se a fazer um código limpo, seguido de seus testes e eventualmente refatorar para que o código fique ainda melhor. Assim, com o tempo, a interdependência começará a atuar a favor do projeto.

Filosofia Clean Code

Não é fácil definir o que é “Clean Code”. Várias fontes usam termos como “guia”, “técnicas”, “conjunto de boas práticas” etc. No entanto, sua linha mestre ao longo do livro baseada na atitude do desenvolvedor faz com seja mais parecida com uma filosofia onde também há preceitos. Mais importante do que como fazer é a disposição de fazer.

Pequenas Coisas Importam

Alguns capítulos tratam de coisas aparentemente pequenas ou com pouca importância, mas logo no início encontramos referência a um pensamento onde criar um código significa dedicar-se a ele. Ou seja, cuidar dos nomes das coisas, a forma como fazemos comentários e até a formatação do código pode parecer de baixo impacto, mas quando nos acostumamos a valorizar e fazer as pequenas coisas, criamos o mesmo hábito para as mais importantes. Na verdade, muitas vezes um determinado código atinge um ponto de deterioração por causa de pequenos descuidos e tarefas não realizadas.

O desenvolvedor que se acostuma a cuidar de coisas como nomes, formatação e comentários provavelmente fará testes de unidade e refatoração com o mesmo cuidado e continuidade. Ele se acostuma a incluir nas suas estimativas aquelas pequenas tarefas de forma que elas não representem uma “perda de tempo” ou um atraso de seu trabalho. Na verdade, ele sabe que essas pequenas tarefas, ao longo do tempo, garantirão a manutenção desta produtividade. Um gerente deve suspeitar do desenvolvedor que pula as pequenas tarefas e nunca contestar aquele que as pratica.

Código é Requisito Detalhado

Você pode ter diagramas, documentos com casos de uso, histórias de usuário ou qualquer outra forma de documentar um software. Contudo, nenhuma delas é tão eficiente quanto o próprio software. Se pensarmos bem, o software descreve através da linguagem de programação o que o negócio deve fazer, pois o software apoia o funcionamento do negócio, seja ele qual for.

Um código fonte é a última milha da transcrição do requisito e ainda por cima é executável. Dessa forma, é importante separar as preocupações em um sistema, pois as mudanças oriundas da tecnologia ocorreram de forma diferente das mudanças oriundas do cliente (negócio). Esta segunda, inclusive, é a mais propensa a gerar dificuldade de entendimento, especialmente por novas pessoas na equipe.

Comunique, não Codifique

Boa parte do livro é dedicada a formas de fazer código que possa, mais tarde, ser lido por outra pessoa. Esse é um dos grandes desafios do desenvolvimento de software, pois um sistema escrito de muitas formas pode funcionar da mesma maneira e atender os requisitos. Assim, os parâmetros de qualidade e boas práticas apresentados em “Clean Code” tentam minimizar este problema clássico.

No entanto, uma abordagem simples pode facilitar bastante esta missão. O desenvolvedor deve escrever seu código tendo em mente que outros programadores precisarão lê-lo e assim tentar comunicar-se no código. Ou seja, deve tentar deixar claro a intenção de um determinado código através dos melhores recursos da linguagem bem como das próprias boas práticas e conceitos apresentados no livro.

Prevenir é Melhor que Remediar

O cuidado com o código deve estar presente desde o início do desenvolvimento. Naturalmente sempre podemos introduzir boas práticas em um ponto mais a frente do projeto, mas quanto mais cedo, mais barato será a implementação de alguma ação. Eventualmente, pode fazer sentido contrair alguma dívida técnica, mas deixá-la crescer sem controle sempre cobra um preço.

No caso de testes de unidade, a antecipação não é somente pela dificuldade posterior, mas principalmente para obter o feedback tempestivo sobre a qualidade do design de um software. De modo geral, quando temos muita dificuldade para fazer um teste de unidade é um sinal que nosso código não está muito bom (testável). Assim, este tipo de teste até faz verificação, mas é primordialmente uma atividade de construção!

Quanto mais uma parte do código parecer descuidada, mais os desenvolvedores tendem a não cuidar desta parte. Isto é conhecido como “teoria da janela quebrada”. Quando uma coisa parece bem cuidada, todos cuidam, mas quando sua aparência é de abandono, as pessoas tendem a abandonar ainda mais. Assim, é importante cuidar do código desde o início de um projeto de software.

Atitude

Código limpo não fica limpo sozinho. Quem deixa o código limpo é o desenvolvedor que precisa tomar a atitude de seguir boas práticas e dar importância aos aspectos do código relativos ao entendimento e manutenção no futuro. O ideal é que esta postura exista desde o início do projeto, mas, em caso negativo, sempre é tempo de seguir a regra do escoteiro e deixar o código um pouco melhor do que encontrou. É muito provável que sempre haja algo para melhorar em um código.

Testes de unidade e refatoração devem fazer parte do trabalho diário bem como das estimativas. Estas tarefas não são atividades extras nem dependem de uma autorização especial por gerar esforço extra. Pelo contrário, são as atividades que garantem a capacidade produtiva de uma equipe ao longo de um projeto. Sabendo disso, o desenvolvedor não tem que se explicar para fazer testes e refatoração e sim deve explicar-se se não o fizer.

Técnica, Treino e Tempo

A versão em inglês do livro tem o seguinte subtítulo: “A Handbook of Agile Software Craftsmanship” ou “Um Livro de Mão do Artesão de Software Ágil” (tradução livre). A noção de que desenvolver software é uma atividade artesanal é muito forte no livro. Assim como vários outros autores, Robert Martin, provavelmente, adquiriu esta percepção através de algumas décadas nesta atividade questionando erros e acertos em projetos de software. Quando trabalhamos nesta atividade por muito tempo, percebemos que algumas capacidades levam bastante tempo para serem realmente dominadas. Afinal, não se encontram livros do tipo “Aprenda Neurocirurgia em 21 Dias”, mas sobre programação é possível.

Apesar do livro apresentar um grande arcabouço teórico com técnicas e boas práticas, é necessário bastante tempo e prática para entender como esses autores chegaram a conclusão, por exemplo, de que funções não devem ter mais do que 20 linhas. Assim como nos padrões de projeto, problemas recorrentes foram encarados várias vezes até que uma solução ou prática comum emergisse. A forma mais simples de aprender esse tipo de ofício é diretamente com quem levou bastante tempo aprimorando-o. Assim como artesãos, desenvolvedores podem e devem aprender com experiências de seus antecessores. “Clean Code” é uma parcela importante e reconhecida deste tipo de conhecimento.

Conclusão

O conceito de “Clean Code” confunde-se com o livro e muitas vezes com seu autor, Robert Martin. Este artigo tentou destacar o problema principal abordado pelo livro: Fazer código que outras pessoas entendam e consigam manter. Daí seu título sugerir que “Manter é preciso…”, pois software evolui e nem sempre com as mesmas pessoas ou condições de quando foi construído. Contudo, o título também sugere “… mexer não é preciso”, pois, muitas vezes, alterar o software de outra pessoa é como navegar no nevoeiro contando apenas com a intuição.

De forma mais ampla, este problema pode ser percebido como um questão de produtividade e rentabilidade com conexões nem sempre óbvias entre “deixar de fazer aquela pequena tarefa” e “não ser capaz de fazer a evolução que o cliente espera”. Entender e tratar os ciclos viciosos e virtuosos requer preparo e experiência em gestão de projetos de software tanto quanto em codificação. Nesse sentido, “Clean Code” é um conhecimento fundamental para estas duas disciplinas, precisando ser conhecido e compreendido pela primeira e aplicada regularmente pela segunda.

Referências

[1] My Lawn (The Clean Code Blog – by Robert C. Martin). Disponível em: https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

MARTIN, Robert, O Codificador Limpo, Alta Books, Rio de Janeiro 2012
MARTIN, Robert, Código Limpo, Alta Books, Rio de Janeiro 2011

Material de Apoio

Este artigo apresenta uma introdução teórica sobre Clean Code. Se você tem interesse em aprofundar o conhecimento através de um material mais prático, recomendamos nosso curso sobre “Clean Code na Prática” na Udemy. A apresentação abaixo mostra boa parte do conteúdo do curso.

Quiz sobre “Clean Code”

https://create.kahoot.it/share/clean-code-parte-1-motivacao-introducao-e-filosofia/833e4d04-5e1f-469f-8357-6aa5b247fa2e

Deixe uma resposta