" Leitura reversa "
" De trás pra frente "
Ao longo desses anos escrevendo códigos, percebi — quase sem querer — que eu lia o código “de trás para frente”: parâmetros, métodos, variáveis, objetos...
Na verdade, quero dizer “ler ao contrário”, pois nós, brasileiros, lemos da esquerda para a direita! Essa percepção sempre me chamou atenção, e hoje trago uma reflexão sobre como isso tem me ajudado a interpretar códigos e decidir por onde começar um novo projeto.
Já parou para pensar que talvez seja mais simples inverter a lógica tradicional das orações (sujeito, verbo e complemento) para compreender códigos com mais agilidade?
Diferente do português, no árabe e no hebraico se lê da direita para a esquerda, e no japonês, de cima para baixo. Cada idioma tem sua própria “dimensão de leitura”, mas todos chegam ao mesmo resultado: a compreensão.
No entanto, no universo do desenvolvimento de sistemas, percebo que o modo “da direita para a esquerda” é mais eficaz para modelar estruturas e prever fluxos. Isso se relaciona com o que conhecemos como notação polonesa inversa ou method chaining, onde começamos com dados brutos e aplicamos transformações sucessivas.
A forma como interpretamos a estrutura de um algoritmo pode nos confundir — e, muitas vezes, nos levar a más decisões.
Pense no seguinte: imagine uma pessoa cantando em um evento, e você percebe que o volume da voz está muito alto.
Se tentar resolver isso partindo da caixa de som até a mesa de som, encontrará um emaranhado de fios e conexões que dificultam o entendimento do circuito.
Mas, se começar pelo microfone — a origem do som — e seguir o caminho dos cabos até a mesa, logo descobrirá qual é o canal da voz e, consequentemente, ajustará o volume certo das caixas.
O raciocínio reverso torna o problema mais claro.
Às vezes, percebo esses mesmos “emaranhados” quando inicio um novo projeto.
Análise de requisitos, escolha do banco de dados, definição da arquitetura (MVC, Monolito, MVVM, Microserviço, SaaS, IaaS, PaaS...) — tudo isso pode gerar uma mistura de confusões antes mesmo de escrever a primeira linha de código.
Entretanto, quando começo a enxergar o fluxo “de trás para frente”, entro no território do DDD (Domain-Driven Design) e percebo que o modelo principal — e mais importante — nasce da experiência do usuário para o código do desenvolvedor.
Pense assim: suponha que você é um engenheiro responsável por projetar uma aeronave.
Se começar pela engenharia pura, vai se perder no abismo de possibilidades e ficará vagando por muito tempo.
Mas, se se imaginar como um piloto, sentado na cabine e olhando para frente, logo verá um botão escrito “START”.
E é aí que tudo começa.
