Capítulo 3 de 7
Antes do código, entender o trabalho
Quando comecei a trabalhar com desenvolvimento, em 1996, programar exigia compreender o que acontecia fora da tela: como uma empresa organizava seus cadastros, controlava o estoque, registrava pagamentos e conferia seus resultados.
Minha formação em COBOL e processamento de dados ajudou a construir essa maneira de olhar para os problemas. Antes de escrever comandos, era preciso identificar as informações de entrada, as regras de processamento e o resultado esperado. Um programa podia executar sem apresentar erros e, ainda assim, entregar uma resposta incorreta se a rotina tivesse sido mal compreendida.
Essa foi uma das bases mais importantes do meu aprendizado. Ao longo dos anos, mudaram as linguagens, os ambientes e as formas de entregar software. A necessidade de entender o trabalho de quem vai utilizá-lo permaneceu.
COBOL e a atenção às regras do negócio
COBOL foi desenvolvido para o processamento de dados de negócios, com recursos voltados à manipulação de registros e aos cálculos decimais. Essa origem ajuda a explicar sua longa presença em aplicações financeiras e administrativas, inclusive em sistemas que continuam em operação. A própria IBM descreve essa continuidade e os caminhos de modernização da linguagem.
Na minha formação, o contato com COBOL ajudou a dar importância à organização dos dados e à sequência das operações. Cada campo tinha uma finalidade; cada cálculo precisava respeitar uma regra.
Essa preocupação continua fácil de reconhecer. Um desconto aplicado na ordem errada, uma data interpretada incorretamente ou um valor arredondado de forma inadequada pode comprometer um resultado inteiro. A interface pode mudar completamente, mas a responsabilidade sobre essas informações continua sendo do sistema e de quem o desenvolve.
Clipper e os sistemas que faziam a empresa funcionar
Com Clipper, o desenvolvimento estava próximo das necessidades comerciais: cadastros, estoque, contas a pagar e a receber, vendas e relatórios. Em muitos ambientes, essas aplicações funcionavam em DOS, utilizando arquivos de dados e índices.
As telas eram predominantemente textuais, e o teclado tinha um papel central na operação. Para quem passava o dia lançando informações, a ordem dos campos, os atalhos e a rapidez das consultas faziam diferença.
Também era necessário prestar atenção aos recursos disponíveis. Memória, acesso a disco e compartilhamento de arquivos em rede influenciavam diretamente o funcionamento do programa. Quando duas pessoas precisavam alterar o mesmo registro, por exemplo, surgia uma questão que continua atual: como coordenar o acesso sem perder informações?
Olhar para esses sistemas ajuda a lembrar que a qualidade de um software aparece no uso diário. Um cadastro rápido e confiável pode ser mais valioso para uma empresa do que uma tela impressionante que dificulta o trabalho.
Pascal e o cuidado com a estrutura
Pascal reforçou outra parte dessa formação: organizar o raciocínio e dividir um problema em partes compreensíveis.
Procedimentos, funções e estruturas de dados ajudavam a dar forma à solução. Esse aprendizado continuou útil nas linguagens que vieram depois, especialmente quando um programa precisava crescer ou receber alterações.
Ao voltar a um código depois de algum tempo, fica evidente o valor de nomes claros e responsabilidades bem definidas. É preciso conseguir localizar uma regra, entender por que ela existe e avaliar o que será afetado por uma mudança.
Essa clareza também facilita o trabalho de outra pessoa que venha a cuidar do sistema. A manutenção começa nas decisões tomadas durante o desenvolvimento.
Visual Basic e a relação com quem estava diante da tela
Com Visual Basic, janelas, botões, menus e formulários ganharam espaço na minha trajetória. O desenvolvimento visual facilitava a construção de aplicações Windows, enquanto a programação orientada a eventos exigia pensar nas ações do usuário: clicar, selecionar, preencher, confirmar ou cancelar.
A interface passou a oferecer novas possibilidades, mas também exigiu mais atenção ao comportamento da aplicação. O que aconteceria se alguém clicasse duas vezes? Se deixasse um campo vazio? Se fechasse uma janela antes de salvar?
A facilidade de desenhar uma tela não resolvia essas perguntas.
Essa etapa reforçou a importância de orientar quem utiliza o programa. Uma mensagem precisa explicar o problema; uma confirmação deve deixar claro o que será feito; uma operação demorada precisa dar algum sinal de que continua em andamento.
São cuidados que permanecem necessários em um sistema acessado pelo navegador ou pelo celular.
Quando o navegador se tornou um ambiente de trabalho
Ainda no final dos anos 1990, comecei a escrever códigos em PHP. A web já oferecia possibilidades de interação, e o processamento no servidor ampliava o que podia ser feito com formulários, consultas e bancos de dados.
A evolução do PHP acompanhava esse movimento. Sua documentação registra a disponibilização pública das primeiras ferramentas em 1995 e o lançamento do PHP 3 em junho de 1998, com maior extensibilidade e suporte a diferentes bancos e protocolos. Esses marcos aparecem na história oficial do PHP.
Para mim, a mudança mais significativa estava na forma de disponibilizar uma aplicação. O navegador permitia acessar funcionalidades sem instalar o programa completo em cada estação. Atualizações podiam ser concentradas no servidor, alterando a maneira de distribuir e manter os sistemas.
Ao mesmo tempo, era preciso lidar com outras condições: conexão interrompida, diferenças entre navegadores, controle de acesso e requisições que podiam chegar novamente.
O sistema ganhava alcance, e o desenvolvimento precisava acompanhar essa responsabilidade.
O banco de dados sempre fez parte da solução
MySQL tornou-se recorrente nos projetos web. SQL Server e PostgreSQL também passaram a fazer parte do repertório, conforme os requisitos e os ambientes.
Trabalhar com bancos diferentes reforçou uma percepção: a confiabilidade da aplicação depende de como os dados são organizados, relacionados, consultados e protegidos.
Imagine uma operação que precisa registrar uma venda e atualizar o estoque. Se apenas uma dessas etapas for concluída, o sistema pode ficar inconsistente. Transações permitem agrupar alterações para que sejam confirmadas em conjunto ou desfeitas em caso de falha, como explica a documentação do PostgreSQL.
Além disso, entram decisões sobre índices, permissões, cópias de segurança e recuperação. Um backup precisa poder ser restaurado. Uma consulta precisa continuar funcionando bem quando o volume de registros aumenta.
Essas questões fazem parte do desenvolvimento desde o planejamento.
Mais ferramentas, mais conexões e novas responsabilidades
O desenvolvimento web ampliou muito as opções disponíveis. Node.js permite executar JavaScript fora do navegador, inclusive no servidor. React oferece uma forma de construir interfaces a partir de componentes. São ferramentas com papéis diferentes, descritos nas documentações de Node.js e React.
PHP também evoluiu. A linguagem ganhou melhorias de desempenho, tipagem e tratamento de erros, entre outros recursos registrados em seu histórico oficial. Sua presença na minha trajetória atravessa diferentes fases do desenvolvimento web.
Hoje, uma aplicação pode conversar com serviços de pagamento, enviar notificações, gerar documentos e compartilhar informações com outros sistemas. Cada integração acrescenta possibilidades e situações que precisam ser previstas.
Se um serviço externo não responder, o usuário precisa saber o que aconteceu. Se uma confirmação chegar duas vezes, a operação não deve ser duplicada. Se uma etapa falhar, deve haver informação suficiente para investigar e recuperar o processo.
O trabalho passa a incluir o acompanhamento do que acontece depois que o código entra em uso.
O que mudou na maneira de desenvolver
Também evoluíram as ferramentas de trabalho: controle de versão, testes automatizados, documentação compartilhada e processos de publicação ajudam a organizar mudanças e reduzir riscos.
Bibliotecas e frameworks permitem aproveitar soluções já desenvolvidas. Isso economiza esforço, mas exige compreender as dependências incorporadas ao projeto e acompanhar sua manutenção.
Com tantas opções, escolher passou a ser uma parte importante do trabalho. É preciso considerar o problema, a infraestrutura disponível, o custo e a capacidade de manter a solução ao longo do tempo.
A experiência ajuda a fazer essas perguntas. E continuar estudando ajuda a encontrar respostas adequadas ao cenário atual.
O que permaneceu
O número de componentes aumentou, mas reconheço no desenvolvimento atual princípios que acompanham minha trajetória desde o início:
entender o processo antes de programar;
separar responsabilidades;
validar os dados de entrada e as regras do negócio;
proteger as informações;
prever e tratar falhas;
documentar decisões e seus motivos;
desenvolver pensando em quem precisará manter o sistema.
Esses cuidados têm consequências práticas. Uma validação esquecida pode permitir um cadastro incorreto. Uma falha sem tratamento pode interromper o trabalho de alguém. Uma decisão sem documentação pode transformar uma alteração simples em horas de investigação.
Linguagens envelhecem, frameworks mudam e plataformas surgem. Regra de negócio mal compreendida continua produzindo software ruim em qualquer tecnologia.
Ter passado por gerações tão diferentes me ajuda a escolher ferramentas pelo problema que precisam resolver, considerando também quem vai utilizar e manter a solução. A novidade desperta curiosidade e incentiva o aprendizado; a escolha exige avaliar o que faz sentido para cada projeto.
Do COBOL ao desenvolvimento web moderno, continuo encontrando valor nessa combinação de experiência, estudo e atenção às necessidades das pessoas. É ela que me ajuda a transformar código em algo útil no dia a dia.