Por que escrevemos o que escrevemos? Filosofia, Clean Code e Boas Práticas

Sumário

Introdução
Filósofos
Escritores da Engenharia de Software
Recapitulando
O que eu acho
Referências

Introdução

Código é o artefato de registro histórico da resolução de problemas.
Ele conta uma história: de zelo, carinho, organização e técnica; ou de promessas, segredos, desespero e caos.
O código é um presente: para você e para os colaboradores do projeto.
Agora, se é um presente de grego, misterioso, ou de casamento, você é quem escolhe.

Depois de ler um livro sobre filosofia, conectei alguns conceitos à programação e resolvi criar esse artigo.

Nele, falarei sobre os pensamentos de alguns filósofos ocidentais, escritores famosos da programação e, por fim: o que penso sobre tudo isso, e como aplico estes conceitos na minha rotina como dev.

Jean-Paul Sartre

Vamos lá, de acordo com Sartre:

Diferente dos animais, o ser humano nasce sem um propósito pré-definido, sem uma essência.

Logo, somos todos obrigados a tomar decisões, para criar/formar/definir tal essência.

A falta de decisão também é uma escolha.
Como o NULL, em uma coluna createdAt, de uma linha existente no banco.

SELECT * FROM Users ORDER BY createdAt DESC

createdAt	id	name	email
NULL	42	Robert Allen Zimmerman	robert.zimmerman@mail.com
NULL	77	Tupac Amaru Shakur	tupac.amaru@mail.com
NULL	101	Jessé Gomes da Silva Filho	jesse.silva@mail.com

Kierkegaard

Disse:

Somos forçados a escolher e toda escolha resultará em algum arrependimento.

Então, por que não fazer a melhor escolha?

E como saber qual a melhor escolha?

Jeremy Bentham

Era inglês, viveu no século 18 e propôs uma solução:
A melhor escolha é a que gerar maior efeito positivo para a sociedade, levando em consideração a dor e a felicidade de pessoas e animais.

A.J Ayer

Ayer popularizou o positivismo lógico.
Criou a Teoria do UHU/BOO (em inglês Hooray/Boo), que critica frases emotivas.
Disse que argumentos morais não são verificáveis, nem são fatos, e portanto, não possuem valor cognitivo.

Roubar é errado = Boo, roubar!
Ajudar é bom = UHU, ajudar!
Java é ruim = Boo, Java!
JS é lento = Boo, JavaScript!

Beleza, agora, vamos à computação.

Escritores da Engenharia de Software

Andrew Hunt & David Thomas

No livro O Programador Pragmático, os autores defendem que programar é como cuidar de um jardim, constantemente livrando-se das pragas/mato.

Apresentam a teoria das janelas quebradas, que sugere que um ambiente destruído/bagunçado tende a piorar com o tempo.
É fácil sujar um ambiente que está sujo, mas ninguém quer ser o primeiro a colocar louça na pia limpa.

Também advogam pela mudança:

Martin Fowler

Define o que são code smells (código fedido) e defende a ideia da melhoria constante, através de pequenas mudanças iterativas e muitos testes automatizados.

Exemplos de "code smells"

Nome misterioso
- dataItem, infoList, DataItemComponentPropHelper
Código duplicado
Função longa
Lista longa de parâmetros
Dados globais
Dados mutáveis

Acredita que refatoração deve ser feita através de micro commits. Ele roda uma esteira de testes automatizados a cada micro alteração, garantindo que a aplicação se mantenha estável (sem quebrar).

Robert C. Martin

Sugere a política da boa vizinhança:

E incentiva desenvolvedores a dizerem não às demandas impossíveis:

Donald Knuth

Escritor da grandiosa série de livros: The Art of Computer Programming (referência clássica em Ciência da Computação), criador da linguagem TeX (que inspirou LaTeX), defende a matemática como base para programadores e, sobre boas práticas de desenvolvimento, afirma que:

Recapitulando

Sartre: Liberdade absoluta, angústia da decisão.
Kierkegaard: Escolhendo ou não, haverá sempre a dor do arrependimento pelo caminho não escolhido.
Bentham: Escolha pensando no bem da maioria.
Ayer: Teoria do UHU/BOO.

Eu gosto da analogia do jardim para projetos, combina com a ideia de melhoria contínua em micro mudanças (Fowler) e boa vizinhança _(Robert C. Martin)_se assemelha aos ideais de Bentham (agir em prol da maioria).
Kierkegaard te instiga a escolher a melhor opção sem medo de errar, já que o erro é inevitável 😅😅😅
E Ayer prefere o uso de argumentos lógicos, embasados em alguma justificativa, a argumentos emotivos, que também ressoa com a fala de Donald Knuth.

O que eu acho

Para mim, a melhor estratégia é, com certeza, jogar todos esses conceitos no liquidificador e bebê-los como se fosse uma vitamina.

Livre para decidir, sigo o caminho que faz mais sentido e documento meus motivos.
Escolho buscando justificativa, não hype/felicidade/argumentos morais/emotivismo.
Sem argumento lógico, evito otimizações prematuras. (Boas justificativas surgem da observabilidade.)
Começo simples, sigo muito o YAGNI (You ain't gonna need it).
Luto contra os problemas da escalabilidade imaginária.
Refatoro sempre que possível, visando melhorar o estado do código principal, focando em legibilidade.

Por experiência própria, sei que: A incerteza pós-alteração em um projeto instável, sem cobertura de testes, é angustiante.

Por isso, defendo o conceito de entrega contínua.

Sobre entrega contínua

Micro-alterações frequentes exigem testes automatizados para garantir uma integração contínua (sem quebrar a aplicação).

Quanto maior o escopo do teste, maior sua confiança. Um teste mockado, embora tenha validade, tem pouco impacto na confiança da entrega.
Um teste E2E(end-to-end), sem serviços mockados, fornece muito valor ao projeto, mesmo com o incômodo da configuração inicial.
Teste unitário é bom para evitar reincidência de bug e documentação de função complexa. De resto, prefiro teste de integração ou E2E.

Vale ressaltar que nem sempre cabe ao programador decidir o ritmo de entrega e prioridade das tarefas. A vida não é um morango 🍓.

Mas também, vale lembrar que:

Por que escrevemos o que escrevemos?

O título dessa seção (e artigo) foi inspirado no livro: Por que fazemos o que fazemos?

Para mim, escrevemos para registrar o que rapidamente nos foge à memória.
O código é um atalho para o momento de maior contexto mental (cacheado e indexado), o da implementação. Então, ao resolver o problema, gaste 5 minutos a mais pensando sobre a situação do código.
Pergunte-se: Faz sentido? Dá para ler? Existe duplicidade? Vou entendê-lo daqui 6 meses?

A estratégia do Red-Green-Refactor do TDD, insiste que reescrever faz parte do processo.

É preciso renomear, mover, desacoplar, deletar e simplificar os registros das soluções dos problemas, para que se torne uma história contada através de arquivos, nem muito pequenos, nem muito grandes.

Diferente do Clean Code, não defendo arquivos minúsculos, acho arquivos grandes aceitáveis, quando descritivos.

Mas então, por que escrevemos o que escrevemos? Não posso falar por você, você vai ter que decidir, boa sorte.
Eu escrevo e programo para evitar a futura fadiga mental de reaprender o que já foi aprendido. Sempre visando um código legível.

Meu workflow ideal