Algumas questões sobre o Clean Code – parte 1

Se você é desenvolvedor, não importa o campo, você provavelmente já ouviu falar sobre o aclamado Clean Code (Código Limpo em português). Eu, pessoalmente, considero-o um livro essencial para profissionais de tecnologia, pois há lições muito valiosas ali que eu nunca tinha parado para pensar sobre. Falo com tranquilidade que esse livro ajudou mesmo a melhorar meu código. Porém… eu tenho algumas questões com ele, especialmente relacionadas à filosofia apresentada nos primeiros capítulos. Nesse ano, coloquei como meta reler o Clean Code com mais calma e, de fato, pensar sobre algumas questões ali apresentadas. Questões que já tinham me incomodado na minha primeira leitura, mas que não tive tempo de elaborar melhor. Apresento aqui algumas questões sobre o Clean Code e gostaria que vocês ficassem à vontade para concordar, discordar, contestá-las e/ou respondê-las!

Algum contexto sobre as minhas leituras de Clean Code

Eu já tinha ouvido falar bastante do tal do livro de Código Limpo, mas nunca tinha me despertado totalmente a vontade de lê-lo. Eu trabalhava com código há um bom tempo já, e tinha contato com eles desde os 15 anos, então achava que já sabia o bastante. Também não estava tão focada em “ir além” e estudar código fora do meu horário de trabalho; visto que, trabalhando e fazendo faculdade, eu não tinha tempo disponível para me aprofundar em outras coisas.

Eventualmente, troquei de emprego e, dentro de um plano de crescimento traçado para mim, uma das ações era a leitura do Código Limpo. E lá fui eu. O problema foi o seguinte: eu tinha um tempo razoavelmente curto para cumprir essa tarefa. Entre trabalho, cuidar da casa, fazer aulas de outros cursos e ler o Clean Code… esse último foi negligenciado. Eu tinha várias questões sobre o livro borbulhando na minha cabeça, mas simplesmente não tinha tempo para elaborar melhor.

Agora, em 2021, me propus a isso – reler o livro e anotar TUDO: o que eu concordo, o que eu discordo, o que eu já vi acontecer e o que eu nunca vi. Com isso, as questões voltaram e foram até mais longe. Pretendo ir falando de pouquinho em pouquinho aqui e, mesmo que não traga respostas, espero que seja enriquecedor para todos que vierem nessa jornada comigo!

Comecemos com a terceira capa do livro

Sim, nem começou o livro direito e eu já tenho alguns pontos e perguntas. 😅

Na terceira capa do livro, há a seguinte frase:

Writing clean code is what you must do in order to call yourself a professional

Tradução: escrever código limpo é o que você deve fazer para poder se chamar de profissional.

Primeiramente, uma questão técnica: o livro Código Limpo foi publicado em 2008 e bem… computação existe há bem mais tempo que isso. Quem trabalhava antes desse “guia” não era profissional? 🤔 Eu sei que essa questão pode parecer picuinha minha com o autor, mas eu, pessoalmente, não gosto desse tipo de generalização. Me lembra muito aquela cagação de regra do Twitter sobre quem é dev e quem não é, dependendo do que programa ou como programa.

Concordo que, possivelmente, um desenvolvedor que não pratica as regras listadas no Clean Code não seja um bom profissional. Ou, como lemos mais para frente, um profissional responsável. Na minha opinião, responsabilidade em termos de código é isso: mantê-lo legível e manutenível, e as práticas fornecidas pelo Clean Code ajudam muito. Mas a partir do momento que estão te pagando para escrever código, você é um profissional. Responsável ou não, só o tempo dirá.

Adianta ter código limpo se não está em produção?

Essa daqui foi uma questão que já me apareceu várias vezes durante a minha jornada profissional (e eu ainda não tenho resposta para ela). Eu já vi programadores extremamente empenhados em deixar seu código brilhando: limpíssimo, escrito com muito cuidado, cheio de testes passando e aí… esse código não vai pra produção. Nunca vai. Vira um projeto qualquer jogado dentro do PC.

Enquanto isso, o sistema em produção está pegando fogo e os consertos são uns códigos porquíssimos, que foram o que foi possível fazer para resolver o problema naquele determinado momento.

No final do dia: quem gera mais valor para o cliente, que é quem de fato paga a conta e quer ver seus requisitos atendidos?

Vejam bem: eu não acho que devemos negligenciar totalmente o código em prol de um objetivo ou de um prazo. Sempre que possível, creio que as soluções devem ser entregues com qualidade, tanto aquela que é visível para o cliente e para os usuários, quanto aquela “por baixo dos panos”, que você faz porque se importa com a manutenibilidade do software e por quem vai encostar naquilo depois de você. Mesmo quando a qualidade do código é deixada de lado para que haja mais agilidade no cumprimento de uma entrega, eu sou do time que, depois da entrega, já ansia por uma refatoração para ajustar possíveis “cheiros” que estejam presentes.

Porém, no final das contas, você é pago para resolver problemas e fazer entregas. De nada adianta ter um código brilhando com “cheirinho de amaciante” se ele vai ficar parado dentro do seu HD.

Código tem contexto?

O livro me dá a entender que não. Inclusive, o próprio autor parece ter deixado isso bem claro no seu Twitter:

When you read code, the race, religion, politics, gender, and orientation of the author are irrelevant and invisible. The only thing you can tell about the author is their ability to write well organized code. Nothing else matters.

— Uncle Bob Martin (@unclebobmartin) November 28, 2019

(Eu acho engraçado que, nesse mesmo livro, no capítulo sobre Nomes Significativos, há a seguinte frase: This matters because programming is a social activity. Vai entender, né? 🤷‍♀️)

Mas, na minha opinião pessoal: código tem contexto sim. Um código “sujo” pode estar ali por diversos fatores: desconhecimento de boas práticas por parte do programador, prazo de entrega apertado, mal-entendidos, cansaço, diferenças de senioridade, uma chefia que não se importa com a qualidade do código, má-vontade (por que não?)… mas a questão é: eu tenho certeza que, se um trecho de código “ruim” existe, é porque existe motivo para ele existir. Logo: há um contexto por trás daquilo.

Pode ser que esse contexto tenha inúmeros fatores dentro dele: aquele código escrito na madrugada da sexta-feira, por um desenvolvedor exausto, feito somente para resolver um problema pontual que vai ser melhor analisado no dia seguinte. Ou pode ser que seja só o código do estagiário que acabou de entrar na empresa e ainda está na faculdade. Eu acredito que, enquanto houver humanos envolvidos em projetos de software, haverá sempre uma explicação e um porquê das coisas estarem como estão.

E com isso, apresento a segunda frase da terceira capa do livro e vou para a minha indagação final (dessa parte):

There is no reasonable excuse for doing anything less than your best.

Tradução: não há nenhuma desculpa razoável para fazer nada menos que o seu melhor.

“Your best” tem contexto também?

Aplicar o que o Clean Code leva prática. Tem coisas que te fazem repensar seu código de imediato, mas tem outras que levam mais tempo e mais experiência. E é com esse espírito que eu me pergunto se o “seu melhor” também tem contextos.

Talvez isso seja uma novidade para as pessoas mas: o seu 100% não é sempre igual. Tem dias que você pode programar de forma super inspirada e criar as melhores classes da sua vida, tudo passando nos testes automatizados, tendo seus PRs aprovados e etc. Mas tem dia que você acorda triste, cansado, desanimado. Tem dias que coisas ruins acontecem, e por mais que você saiba recitar as boas práticas do Clean Code, o seu 100% delas não vai ser perfeito.

A partir desse tipo de frase generalista, eu fico me perguntando o quanto dela é realmente honesta. O quanto “o seu melhor” é realmente seu, e não o “seu melhor” do melhor desenvolvedor que tem na equipe. Em um contexto capitalista, de produtividade, resultados e métricas, o quanto você pode, realmente, fazer o seu melhor, e não o melhor que os outros esperam de você?

---

Concluindo: todas essas minhas reflexões vieram das duas primeiras linhas do livro, do que eu lembro da minha leitura anterior e de tudo que eu passei (até agora) nessa indústria vital que é a de desenvolvimento de software. Assim que for possível, trarei a parte 2 com as questões que me surgiram durante o prefácio deste mesmo livro. Até lá, fiquem à vontade para me contar o que vocês pensam dessas bolas que eu levantei. Concordam? Discordam? Já pararam para pensar nisso?

---

📜 Posts relacionados

💤 Quando foi que descansar ficou difícil?

📚 Lições (re)aprendidas com o HackerRank

---

💌 Recadinhos

Gostou do texto? Tem algo a adicionar? Alguma crítica construtiva? Feedbacks? Sugestões? Pedidos? Fique à vontade para me contatar via email (oli.pmatt@gmail.com), Twitter (@oliviamattiazzo), LinkedIn (/oliviamattiazzo) ou pela caixa de comentários aqui embaixo! Vai ser um prazer conversar contigo! ✨