Como Fazer…

Antes de mais nada preciso dizer que esse post vai ser longo e é meio filosófico. Em função disso, gostaria de assentar primeiramente alguns pressupostos que fundamentam a visão que pretendo expor. Também devo esclarecer que ‘código que funciona’ não é uma antítese material ao conceito do código limpo. É apenas um ‘mnemônico’ acidental pra ser usado em conversa de boteco. Também devo esclarecer que aquilo que você vai ler é minha interpretação e não ‘a verdade última’ ou uma revelação divina inquestionável então, sinta-se a vontade para concordar ou discordar. E me corrija se achar algo errado, certo?

Pressupomos…

Pressuposto 0: Programadores são profissionais que necessariamente precisam compreender diversas áreas de conhecimento além da simples prática da escrita de código. Mesmo uma pessoa que seja leiga no ramo da programação, ao iniciar seus estudos percorrerá uma senda inevitável: terá que aprender a lidar com conflitos (de código e entre pessoas), terá que aprender e aprofundar seus conhecimentos em matemática, terá que aprender a arte da negociação, terá que aprender termos técnicos, conceitos e procedimentos restritos às áreas a que os softwares que ela for construir atendam, enfim, é um profissão necessariamente multidisciplinar.

Pressuposto 1: Nenhum programador está interessado em produzir, em primeira mão, aquilo que se chama <código legado>. Programadores não sentam à frente de um computador pensando em produzir uma peça de código que lá à frente no tempo poderá se tornar difícil de manter, sem condições de evoluir e até voltar para assombrar a sua própria vida.

Pressuposto 2: Programadores não querem produzir deliberadamente código que possuam bugs. Programadores não planejam os bugs que afetam seu código, eles não plantam bugs como ‘easter eggs‘ especiais no código. Bugs são acidentes e por vezes nem são causados por algo no código produzido mas por uma dependência introduzida, que pode ser uma biblioteca, um serviço externo cuja API, mal documentada e desatualizada, foi modificada sem qualquer notificação aos usuários, etc…

Pressuposto 3: Programadores querem ser reconhecidos pela boa qualidade de seu trabalho. Programadores são seres humanos, e como bons humanos que são, precisam do tapinha nas costas, do reconhecimento, do afago no ego… enfim daquela dose de dopamina diária… E assim, ‘programadores também choram’.

Entendendo que foram assentados e compreendidos esses pressupostos, vamos adiante.

Adiante

Embora os pressupostos acima sejam válidos, a nossa forma de trabalho e o contexto por vezes nos impelem a seguir em direções que os contradigam. Isso porque esses pressupostos sustentam-se e são válidos na subjetividade do programador e feliz ou infelizmente (você é quem decide) existe algo que a ela se sobrepõe: Todo programador tem clientes com necessidades urgentes e contas a pagar. Aliado a isso temos o problema de se considerar que boas práticas são ‘opcionais’ e que certas coisas não devem ser seguidas a risca, sob pena da perda de valor de mercado de um produto. Daí diz-se: “É melhor o feito do que o perfeito“. E o programador faz a coisa pra funcionar. “Depois a gente volta e conserta o que for possível”. Se você ler atentamente, verá que temos aqui em pouco mais de um parágrafo 4 dos maiores sofismas da área de desenvolvimento de software:

1 – A urgência da demanda se sobrepõe à sua suposta integridade, ou seja, o software é uma urgência para o cliente e precisa ser entregue funcionando. Se preciso for, ignore a cobertura de testes, boas práticas, engenharia cuidadosa… 12factors? tudo isso aí é utopia.

2- Software não se constrói seguindo estritamente instruções de livros, ou seja, embora haja literatura que explique e exemplifique como construir bem um software, na maioria das vezes aquilo não funciona na vida real, quando temos prazos e custos a serem mensurados. É mais importante o software entrar em execução do que gastar tempo pra descobrir e adotar um conjunto correto de design patterns para desacoplar os componentes dele. Bom, adiante devo falar sobre isso mas, descobrir design patterns à primeira vista é possível, mas exige experiência e conhecimento sobre design patterns, então, é preciso ler sobre isso para conhecer e identificar quando pode usar.

3 – É melhor o feito do que o perfeito. Se você for gastar tempo para conceber um software da forma ideal, perderá o projeto e o cliente.

4 – Depois a gente volta e conserta o que for possível, ou seja, faz ai o que der, põe um comentário anotando o que falta ou o que pode ser melhorado ou nem isso… lá na frente a gente volta e conserta o que der.

Esses sofismas da indústria de software contradizem completamente os pressupostos de que falei lá acima. Sim, contradizem e fazem da área de desenvolvimento de software uma área extremamente lucrativa. Vende-se mais cursos e livros sobre ‘como ser um desenvolvedor melhor’ a cada dia… Me pergunto: Isso é bom? Bem… essa avaliação é subjetiva, entende? Bom para quem? Para os clientes, certamente não, uma vez que a cada alteração necessária em um software ou simples atualização de funcionalidade, o custo de manutenção sobe ao ponto de ser praticamente melhor planejar um novo software que manter o existente sob pena de estar trabalhando com um perigoso monstro de Frankenstein. Se a escolha é por manter o software, todos, o cliente, o time desenvolvimento, ficam refém da situação em que se colocaram…

– Êeeeeee, perae, velho… O teu post não era sobre ‘código limpo vs código que funciona’?

Era não! É exatamente sobre isso que estou falando, pow… se você não entendeu ainda, volta lá pra cima e lê tudo de novo…

Enfim…

Aquele ‘código que funciona’ é a armadilha mais sutil que um programador planta para si mesmo. Ao se convencer da validade e verdade dos sofismas, ele passa a viver e programar em regime de urgência. Ele vai sofrer com dilemas internos sobre a qualidade do seu trabalho mas no fim, vai se enganar com a ‘entrega de valor’. Reduzirá a quantidade de iterações de testes, isso quando fizer testes… construirá código com excesso de débito técnico e isso tudo resultará em um produto de qualidade questionável. Funciona? sim… mas e se precisarmos adicionar uma nova funcionalidade aqui ou ali, será simples ou precisaremos reescrever quase tudo de novo? Vai consumir mais ou menos tempo do que levou para produzir a primeira versão? Qualquer outro programador será capaz de fazer mudanças entendendo bem o código que foi escrito e absorver as práticas ali aplicadas para seu proveito?

O ‘código limpo’, por sua vez, é apenas o código que faz exatamente o que ele foi projetado para fazer, que é cientificamente correto, posto que é testável e para o qual você pode repetir os testes e ter o mesmo resultado sempre. É um código benéfico para o cliente posto que não precisará de meses para ser modificado diante de qualquer nova necessidade do negócio. Todo código limpo é necessariamente um código que funciona. Quanto a isso, os livros da sequencia ‘clean’ (Clean Code, Clean Coder e Clean Architecture) nos trazem uma enorme contribuição positiva. De fato, por meio desse conjunto de livros, fica bem estabelecido que o trabalho de um programador profissional é escrever ‘código limpo’, seguindo um método científico certificando-se de que hajam hipóteses e testes adequados e suficientes (testes unitários, testes funcionais, testes de mutação, testes de aceitação) para o código que produziu, agindo com responsabilidade para consigo mesmo, com o time de desenvolvedores e para com o cliente ou ‘dono do produto’.

Mas amigão, é claro que produzir código limpo leva tempo e depende da maturidade do desenvolvedor. Não é algo que todo mundo ‘sabe’ naturalmente fazer… ninguém nasce sabendo. Porém deveria ser um objetivo que todo programador deveria buscar. Veja o código limpo como consequência da adoção de paradigmas modernos de construção de software, como o paradigma orientado a objetos, programação funcional, etc… Isso porém não quer dizer que um código construído utilizando paradigma orientado a objetos é um código limpo por si só. Não… Não será se ele for apenas um amontoado de classes e objetos dismorfos, etéreos, conversando confusamente entre si e que apenas um iluminado consiga entender tal conversa. Um ‘código que funciona’ e que não foi construído com algum rigor científico não te possibilitará identificar uma falha de integração a tempo, não permitirá localizar bugs de qualquer natureza antes de entrar em produção… Hoje eu entendo: a chave é o rigor científico.

– Mas o desenvolvedor tem que ter formação para ter método científico, ne?

Boa pergunta…. mas pensa comigo: quem formou o primeiro cientista e passou o método para ele? Métodos são ferramentas e estão disponíveis para descoberta e aprendizado. Isso independe da formação acadêmica. Curiosamente a palavra método origina-se de duas palavras gregas ‘meta’ e ‘hodos’, significando ‘caminho a percorrer’, ‘modo de fazer’ algo. Assim, você precisa aprender métodos, modos de fazer as coisas, e por existirem ‘modos corretos’ e ‘modos inadequados’ é que falo em ‘rigor científico’, querendo exatamente dizer que não devemos abrir mão de coisas como ‘unit test first’ e ‘test driven development’. São métodos comprovadamente eficientes de escrever bons códigos e de simplificar as coisas para futuras refatorações.

– Me diz só uma coisa: todo código que tu compões segue essa regra também?

Em geral, sim. Mas vivo fazendo muitas concessões e isso volta como problema pra mim depois, essa é a verdade. É preciso admitir que aprendi a respeitar o ‘código que funciona’ apenas porque ele é muitas vezes o produto de mentes cansadas, de prazos renegociados e pressão por entrega, mas por isso mesmo valorizo ainda mais o código limpo e todas as boas práticas que o fundamentam. Depois que o bug explode diante de você e você vê que isso seria facilmente evitável, daí em diante, você não pode ignorar sem incorrer em prejuízo próprio.

– Hum…. mas to aqui esperando e você não vai trazer nenhum exemplo pra gente e tal? Queria ver se existe mesmo essa diferença entre o código limpo e o código que funciona na prática, saca?

Hoje não, irmão. Hoje não.

Vamos ver que eu tenho alguns posts pra soltar ai nos próximos dias (meses ou anos, vai depender do estado de espírito…) e que conterão exemplos, mas nesse aqui não.

Aqui é mais uma reflexão.

Pensa nisso que você leu até aqui, chama teu time pra conversar sobre isso e tenta formar um consenso. Tendo feito isso, dialoga com quem precisar para conseguir fazer qualquer ajuste necessário em termos de boas práticas, tá certo? Fala com coordenador, gerente, supervisor, com quem precisar mas não cai na armadilha do ‘código que funciona’.

PS.:

Preciso mencionar também que a adoção de metodologias ágeis como solução de problemas de gerenciamento em um time de desenvolvedores pode acontecer de forma equivocada por equipes que não desenvolvem uma cultura à base da prática ‘clean’ e isso pode acabar funcionando como um reforço àqueles sofismas. A base do manifesto ágil é a cultura do time.

Vamos lembrar o contexto que o manifesto ágil e seus signatários supõem ser ‘fato’ nas equipes: Programadores desenvolvendo profissionalmente código seguindo boas práticas, adotando um ponto de vista ‘progressista’ quanto à metodologia de desenvolvimento do software, (Progressista no sentido representar uma alternativa a modelos de ciclo de vida de um software tradicionais como o ‘cascata’) mas conservador no sentido de preservar a demanda do cliente como requisito fundamental levando isso tão a sério que a resposta a mudanças nas necessidades do cliente não são atendidas no fim, mas durante o desenvolvimento das funcionalidades e mediante a discussão aberta do que está sendo feito. Enfim, só nesse contexto, onde há um nível bastante profundo de comprometimento do desenvolvedor com a própria integridade; quando desenvolvedores ampliam seus próprios conhecimentos envolvendo-se diretamente na discussão das demandas dos clientes; quando eles, os desenvolvedores adotam para si, individual e coletivamente, boas práticas para produzir software atual e facilmente atualizável. Só nesse contexto a gente consegue ser ágil como se precisa ser. É isso…

[EDITADO] O final parecia que havia ficado desconexo e havia mesmo: Adicionei o fragmento que faltava.