O Simples é Poderoso: Como Scripts e Aplicações Console Resolvem Problemas Reais

Existe um vício silencioso que pode contaminar o desenvolvimento de software: a mania de querer usar a tecnologia mais moderna, o framework mais pesado ou a arquitetura mais sofisticada para resolver qualquer problema. Se é para fazer um sistema de cadastro, vamos usar microserviços. Se é para automatizar uma planilha, vamos criar uma aplicação web completa com front-end em React e back-end em Node.

O problema é que essa abordagem pode trazer um custo desnecessário. Mais componentes significam mais pontos para configurar, manter, monitorar e eventualmente corrigir. Dependendo do problema, toda essa estrutura pode acabar consumindo mais tempo do que a própria solução exige.

A tese central deste artigo é simples: muitas vezes, a melhor ferramenta é aquela que resolve o problema com a menor complexidade necessária. Pode ser um script que roda em background, uma aplicação Console ou simplesmente uma rotina no próprio banco de dados. O importante é que a solução seja adequada ao contexto.

Vou compartilhar três casos práticos que vivi em ambientes corporativos. Nenhum deles envolve arquiteturas complexas ou tecnologias de ponta. Todos eles partiram de problemas reais e foram resolvidos utilizando ferramentas que, à primeira vista, podem parecer simples ou até antigas.

E existe um detalhe que considero ainda mais interessante: em todos esses casos, o desenvolvimento da automação aconteceu em questão de horas. O trabalho foi entender o problema, planejar o fluxo, escolher as ferramentas disponíveis e colocar a solução em prática.

Se você trabalha com desenvolvimento e já se pegou pensando que precisa de algo mais sofisticado para resolver um problema simples, este artigo é para você.

O primeiro caso aconteceu em uma empresa do setor de telecomunicações. O problema era relativamente simples: os leads gerados pelo sistema precisavam ser enviados automaticamente para um discador eletrônico, que fazia as ligações para os clientes.

A operação funcionava assim: o SQL Server gerava um arquivo de texto com os leads a cada dez minutos. Esse arquivo precisava ser enviado para um servidor FTP onde o discador buscava as informações. Simples, não?

As tentativas frustradas

A primeira tentativa foi resolver tudo dentro do SQL Server. A ideia era usar procedimentos armazenados para gerar o arquivo e enviá-lo diretamente via FTP. Mas o SQL Server, por questões de segurança e configuração do ambiente, não era a melhor opção para assumir sozinho essa parte da comunicação externa. A solução dependia de recursos e permissões que poderiam ser restringidos pelas políticas de TI.

A segunda tentativa foi criar uma aplicação Windows Forms em C#. A ideia era ter um botão que o operador clicava para enviar os arquivos. O problema era justamente depender de uma pessoa. Se ninguém clicasse no botão, os leads não eram enviados. E se ninguém estivesse disponível em um feriado ou fim de semana, a operação poderia parar.

A solução simples

A solução final foi ridiculamente simples: um arquivo .bat agendado no Windows.

O SQL Server gerava o arquivo .txt localmente. Um script batch, agendado no Agendador de Tarefas do Windows, executava o envio via FTP a cada dez minutos, de forma completamente automática. Sem interface, sem operador e sem depender de uma ação manual para cada envio.

O script era basicamente isto:

@echo off


ftp -s:comandos_ftp.txt 192.168.1.100
del C:\Leads*.txt

O arquivo comandos_ftp.txt continha as instruções de login e o comando de envio. O script rodava a cada dez minutos, enviava o arquivo, apagava o original e aguardava a próxima execução.

Nenhuma linha de código C#. Nenhuma interface gráfica. Nenhum operador precisando iniciar o processo manualmente. Apenas um arquivo de texto, um script e um agendamento no Windows.

O problema foi resolvido, e a solução continuou funcionando por anos sem exigir alterações frequentes.

O mais interessante é que essa solução era tão simples e automática que praticamente desaparecia da rotina da equipe. E isso, naquele contexto, era exatamente o que se esperava de uma boa automação.

O segundo caso aconteceu em uma empresa de cobrança. A operação recebia, todos os dias, múltiplos arquivos CSV de diferentes fontes: pagamentos, parcelas, clientes. Cada arquivo tinha um layout diferente. Todos precisavam ser carregados no SQL Server para que o sistema de cobrança pudesse processá-los.

A tarefa era feita manualmente. Um analista abria cada arquivo, verificava o formato e importava para o banco utilizando as ferramentas disponíveis no SQL Server Management Studio. O processo levava horas e era suscetível a erros humanos.

A solução: um Console Application em C#

A solução foi criar uma aplicação Console em C# leve, focada em fazer uma coisa bem definida: ler os arquivos, reconhecer os diferentes layouts e carregá-los em tabelas temporárias no SQL Server.

A aplicação não precisava de interface gráfica. Ela poderia rodar em background, agendada para executar no início do dia. O fluxo era simples:

1. A aplicação verificava a pasta de entrada em busca de novos arquivos CSV;
2. Para cada arquivo, identificava o layout pelo nome ou pelas primeiras linhas;
3. Carregava os dados em uma tabela temporária correspondente;
4. Registrava no banco o nome do arquivo processado, para evitar duplicidade;
5. Movia o arquivo processado para uma pasta de arquivo morto;
6. Chamava uma Stored Procedure que fazia o cruzamento final dos dados.

O diferencial técnico estava no controle rigoroso de duplicidade. Antes de processar qualquer arquivo, a aplicação verificava se o nome daquele arquivo já estava registrado no banco. Se estivesse, pulava. Isso evitava que o mesmo arquivo fosse importado duas vezes, gerando duplicação de pagamentos ou parcelas.

Além disso, a divisão de responsabilidades era limpa. O C# processava o arquivo e o carregava em tabelas temporárias. O trabalho pesado de cruzar os dados, atualizar as tabelas definitivas e gerar os relatórios ficava a cargo de Stored Procedures no SQL Server, aproveitando o processamento de conjuntos de dados diretamente no banco.

O resultado foi uma redução drástica no tempo de processamento e a eliminação de boa parte do trabalho manual. O que antes levava horas e exigia atenção constante de um analista passou a rodar automaticamente todas as manhãs.

E o mais importante: a aplicação era simples o suficiente para que outros desenvolvedores da equipe conseguissem entender o fluxo e dar manutenção sem precisar lidar com uma arquitetura maior do que o problema exigia.

O terceiro caso é parecido com o primeiro, mas com uma diferença importante: a empresa não tinha automação nenhuma. Um analista perdia tempo todos os dias tendo que entrar manualmente na área de FTP para baixar lotes de arquivos.

O processo era doloroso de assistir. O analista abria o cliente FTP, digitava usuário e senha, navegava até a pasta correta, selecionava os arquivos, baixava e depois repetia o processo para outras pastas. Todos os dias. Várias vezes ao dia.

A solução em camadas

A solução foi construir uma automação em camadas, aproveitando o que já existia e adicionando apenas as peças que faltavam.

A primeira camada era um arquivo .bat que acessava o FTP e baixava os arquivos para uma pasta local. Esse script rodava agendado, de madrugada e no meio da tarde, garantindo que os arquivos estivessem disponíveis localmente.

A segunda camada era uma aplicação Console em C#, similar à do caso anterior, que processava os arquivos baixados e os carregava no SQL Server. Essa aplicação também rodava agendada, logo após o término do download.

A terceira camada era um conjunto de Stored Procedures que consolidavam os dados nas tabelas definitivas e geravam os relatórios que a equipe precisava.

O fluxo completo era:

.bat (FTP) -> Console C# (Importação) -> Stored Procedure (Consolidação)

O analista que antes passava horas baixando arquivos manualmente deixou de precisar executar esse trabalho repetitivo. Ele pôde ser direcionado para outras atividades, enquanto a empresa ganhou uma rotina automatizada para uma tarefa que antes dependia de intervenção humana.

Nenhuma das ferramentas usadas precisava ser sofisticada para aquele cenário. Um arquivo .bat, uma aplicação Console em C# e um banco de dados SQL Server foram suficientes para montar o fluxo necessário.

E existe uma lição importante nesse caso: não foi necessário substituir tudo o que já existia. A automação foi construída aproveitando os recursos disponíveis e adicionando somente aquilo que faltava para fechar o processo.

Olhando para os três casos, é possível identificar alguns padrões que ajudam a explicar por que aquelas soluções funcionaram tão bem dentro dos respectivos ambientes.

Baixa complexidade operacional

Nos exemplos apresentados, as aplicações Console e os scripts .bat tinham responsabilidades bem definidas. Não havia necessidade de criar uma interface para tarefas que precisavam acontecer automaticamente. Isso reduziu a quantidade de componentes envolvidos e facilitou o entendimento do fluxo.

Menos intervenção manual

Um dos maiores ganhos desses projetos não veio de uma tecnologia sofisticada, mas da eliminação de tarefas que dependiam de uma pessoa. Depois de configuradas, as rotinas podiam executar em horários determinados sem que um operador precisasse iniciar cada etapa manualmente.

Desenvolvimento rápido

Nos três casos, o desenvolvimento das automações aconteceu em questão de horas. O processo foi essencialmente entender o problema, planejar o fluxo, definir quais ferramentas já disponíveis poderiam ser aproveitadas e colocar a solução em prática.

Não foi necessário passar semanas construindo uma estrutura maior antes de entregar algum resultado. A solução foi desenvolvida diretamente em torno da necessidade que existia naquele momento.

Automação invisível

Existe algo particularmente interessante em automações desse tipo: quando elas funcionam corretamente, o usuário praticamente não percebe que estão ali. Elas executam suas tarefas em background e eliminam etapas manuais do processo.

Isso não significa que toda solução sem interface ou toda aplicação Console será automaticamente mais estável ou melhor do que uma aplicação gráfica ou uma arquitetura mais sofisticada. A estabilidade depende de vários fatores, como qualidade da implementação, ambiente, monitoramento, tratamento de erros e requisitos do sistema.

O ponto dos exemplos deste artigo é outro: quando o problema é simples e bem delimitado, uma solução simples pode ser suficiente e muito eficiente.

É importante deixar claro que não estou defendendo que toda solução deva ser um script .bat ou uma aplicação Console. Existem problemas que realmente exigem interfaces gráficas, arquiteturas distribuídas ou tecnologias mais modernas. Mas a pergunta que todo desenvolvedor deveria se fazer antes de partir para a complexidade é: "Qual é a solução mais simples que resolve este problema?"

Ser pragmático não significa ser contra a tecnologia. Significa escolher a ferramenta certa para o problema certo. Existem situações em que uma solução mais complexa se justifica, e é importante reconhecê-las.

Quando a complexidade pode fazer sentido

• Múltiplos usuários simultâneos: Se várias pessoas precisam acessar o sistema ao mesmo tempo, uma interface gráfica ou uma aplicação web pode fazer sentido;
• Regras de negócio complexas: Se o problema envolve muitas regras, fluxos e exceções, uma arquitetura mais estruturada pode ajudar a manter o código organizado;
• Integração com múltiplos sistemas: Se a aplicação precisa conversar com vários outros sistemas, uma arquitetura baseada em serviços pode ser adequada;
• Escalabilidade: Se o volume de dados ou de acessos é muito alto, soluções distribuídas podem ser necessárias.

Quando uma solução simples pode ser suficiente

• Tarefas repetitivas e agendadas: Se o trabalho é sempre o mesmo e roda em horários definidos, um script ou Console Application pode resolver;
• Processamento em lote: Se os dados chegam em arquivos e precisam ser carregados no banco, uma aplicação Console pode ser suficiente;
• Automação de tarefas manuais: Se o objetivo é eliminar trabalho braçal, uma automação simples pode ser uma boa alternativa;
• Protótipos e provas de conceito: Se a ideia é validar uma hipótese rapidamente, pode não fazer sentido começar investindo em uma arquitetura sofisticada.

A regra que funciona para mim é simples: comece pelo que resolve o problema com a menor complexidade necessária. Se os requisitos mostrarem que aquela solução não é suficiente, aí sim faz sentido evoluir a arquitetura.

Os três casos que compartilhei neste artigo têm algo em comum: nenhum deles precisava de tecnologia de ponta para resolver o problema apresentado. Foram situações em que ferramentas simples e conhecidas foram suficientes para construir uma automação funcional.

O .bat que enviava leads via FTP. O Console Application em C# que importava CSVs para o SQL Server. A automação em camadas que eliminou o trabalho manual de download. Nenhuma dessas soluções precisava ser sofisticada para cumprir sua função.

E talvez essa seja a principal lição desses exemplos: programar não é escolher a tecnologia mais moderna. É entender o problema, avaliar o contexto e construir uma solução que realmente resolva a necessidade.

Em todos esses casos, o trabalho começou pelo planejamento. Primeiro foi preciso entender o processo, identificar onde estava o desperdício de tempo ou a dependência de uma tarefa manual e, depois, escolher as ferramentas que já estavam disponíveis para construir a automação.

O fato de essas automações terem sido desenvolvidas em questão de horas não significa que qualquer problema possa ser resolvido nesse tempo. Significa que, quando o problema está bem delimitado e as ferramentas adequadas já estão disponíveis, não é necessário transformar uma necessidade simples em um projeto gigantesco.

Se você é um desenvolvedor que está começando, não se deixe levar pela pressão de usar a tecnologia mais moderna em todos os projetos. Aprenda a avaliar o problema, entenda o contexto e escolha a ferramenta adequada.

E se você é um desenvolvedor experiente, talvez valha a pena fazer a mesma pergunta antes de começar um novo projeto: eu realmente preciso de toda essa complexidade?

Muitas vezes, a melhor solução não é a mais sofisticada. É simplesmente aquela que resolve o problema de forma eficiente, confiável e compatível com o contexto em que será utilizada.

Quer contribuir com o Nerd Cult?

Você já resolveu algum problema real com uma solução simples que muitos considerariam "ultrapassada"? Já viu alguém complicar demais algo que poderia ser resolvido com um script ou uma pequena aplicação? Compartilhe sua experiência nos comentários — sua história pode ajudar outros desenvolvedores a enxergar o valor da simplicidade. E se você tiver um caso prático, um projeto ou uma ideia para um próximo artigo, entre em contato com a gente.

Nerd Cult — onde o código encontra o rock, o cinema e a cultura geek. Porque ser nerd é transformar o medo em curiosidade, e a curiosidade em poder.

#Programação #Automação #CSharp #ConsoleApplication #NerdCult