As tecnologias empregadas no desenvolvimento de software têm evoluido muito ao longo dos últimos 20 anos e em uma velocidade tão grande que algumas pessoas acabaram por não perceber esse ciclo de melhorias, como as das técnicas em si (como a programação orientada a objetos e as estratégias modernas de arquitetura de software e codificação), simplificando o dia a dia focando em código limpo, testável, reutilizável e integrado.

Em um passado muito distante, não tínhamos no dia a dia o conceito de orientação a objetos que temos atualmente. Estou falando de um momento do mercado onde desenvolver em camadas era entupir o banco de dados de regras de negócios baseadas em uma soma explosiva de Trigger + Stored Procedures; conceituando-se como a visão de desenvolvimento em camadas daquele momento, evoluindo a lindos modelos com procedures “maravilhosas” para todo o CRUD (Create, Read, Update, Delete) que vem contaminado projetos até hoje. Certamente você já viu essa situação em algum lugar. Agora você conhece a origem do problema e pode parar com ele.

Este é o momento de sermos muito honestos com a realidade e falar o tamanho deste problema que se iniciou no passado e ainda convive na mente de muita gente. Vamos combinar que desenvolver uma regra de negócio direto no banco de dados é um trabalho sofrível, sem depuração, sem nenhum apoio de reutilização de inteligência de software. É tipicamente um notepad com control+C / control+V; ou seja, o que foi pensando como um caminho de reutilização tornou-se um gargalo para o time de desenvolvimento e para o próprio banco de dados, que absorve funções que são do escopo do serviço de aplicações, consumindo recursos desnecessários. É fácil você comprovar e verificar que todas as empresas que fizeram isso sofrem com gargalos nas operações de banco de dados que ficam travando registros eternamente.

Quando entramos no escopo da manutenção, estamos falando de um caos generalizado que é garantir a qualidade de um código gigantesco – muitas vezes com mais de 10 mil linhas sem nenhuma infraestrutura de apoio. O fato é que ele não foi projetado para isso. Banco de dados é para atuar como banco de dados e não como servidor de aplicações. Agora imagine como vai escalar isso no ciclo do seu projeto, tendo que focar as pessoas em manter esse código ultra complicado. Muda em um ponto e estoura em dezenas de outros. Acredito que já viu essa situação em algum vizinho próximo. Está na hora de você praticar o desapego e parar de acreditar que software tem que ser desse jeito.

Ao longo dos anos, os projetos foram crescendo e os negócios foram crescendo juntamente com o número de usuários nas aplicações. Ao mesmo tempo, cada vez mais pessoas estão participando do ciclo de desenvolvimento, criando demanda por um modelo de produção de software mais organizado, utilizando práticas “reais” de orientação a objeto, padrões de projeto e codificação com regras de validação reutilizáveis e fáceis de manter disponibilizadas em um barramento de serviços (API), compartilhando e facilitando a integração entre plataformas e outros dispositivos, além de uma cobertura por testes automatizados via testes unitários, garantindo a evolução do negócio sem comprometer a qualidade do que está sendo produzido.

Enquanto estamos conversando, as plataformas de banco de dados também evoluíram muito, quebrando paradigmas do passado – que código roda mais rápido se estiver dentro do banco de dados, por exemplo. Os principais bancos de dados criam plano de execução dinamicamente, além de uma série de funcionalidades e estratégias para fazer o objetivo deles: que é oferecer a informação solicitada. Essa historinha ultrapassada ainda toca na vitrola de muita gente e parece aquela do “CD gravado em computador vai estragar o seu leitor”. Está na hora de sair do tempo do vinil e entrar no developer 4D.

Em paralelo está o DBA (Database administrator), cujo nome já deixa claro suas atribuições administrativas que foram também desfocadas ao longo dos anos, não observando que a sua importância não é criar procs e sim otimizar processos do banco de dados, manter estratégias administrativas e operações relacionadas permitindo escala. De uma vez por todas, vamos deixar claro que quem entende de negócio é o cliente solicitante e o desenvolvedor que está construindo a aplicação. O momento da revolução industrial e produção com batedor de martelo não existe mais.

Para entender melhor, imagine você trabalhando em um time de vinte desenvolvedores parados, esperando o DBA construir uma Stored Procedure e determinar a criação de um campo no banco de dados. Ainda me espanto quando vejo isso. É quase o mesmo que assistir uma tv de válvula nos tempos de hoje. Tudo bem, eu sei que você provavelmente desconhece esse tipo de tv, mas só para comparar a distância entre ela e a era SmartTV. Está na hora de acabarmos com essas lendas urbanas e assumirmos a área de desenvolvimento como tem que ser. O trabalho do DBA continua como foi pensado: “Database administrator”; e é parte importante do centro de operações, mas desculpe, não faz parte do desenvolvimento de software e sim operações.

Agora que você está ambientado, provavelmente já participou de algum tipo de conversa sobre essa questão que emerge com frequência na maioria das empresas com mais de quinze anos de mercado. O grande passo para praticar o desapego é entender que temos orientação a objetos há mais de 20 anos e até hoje convivemos com esse conflito entre código e dados, uma relação de amor e ódio que precisa ser resolvida. Chame todo o seu time e faça um DRP (discussão de relacionamento no projeto). Vamos acabar com as disputas de poder e construir um trabalho positivo para todos.

O ORM (object-relational mapping) foi criado justamente para unificar essa relação entre código e dados, padronizando o código fonte, dispensando a necessidade de escrever códigos T-SQL e, principalmente, de ser uma preocupação extra para desenvolvedores e relacionados. Ficando, então, a cargo da infraestrutura de ORM fazer essa relação e trazer uma visão do banco de dados em um formato integrado ao mundo de desenvolvimento de software com os dados tipados e orientado a objetos, simplificando a manutenção e permitindo o compartilhamento do conhecimento – isso sem falar no aumento de produtividade, pois o desenvolvedor passa a lidar com dados da mesma forma que lida com qualquer outra classe. É nesse momento que você, desenvolvedor, percebe o quanto estava gastando de dinheiro produzindo código macarrônico desnecessário. Quem curte comida italiana, como eu, deixa para consumir em casa ou no restaurante, mas não no projeto.

Agora que já estamos falando em não mais escrever regras de negócio no banco de dados e nem Stored Procedures e afins, precisamos mudar a nossa forma de pensar como um todo e entender que quanto mais simples for o código, mais escalável ele será. Ferramentas de ORM, como Entity Framework e similares, têm justamente esse papel de mapear uma tabela de banco de dados como uma classe criando um elo de integração, tornando a sua aplicação por padrão independente do banco de dados. Para o desenvolvedor, a visão de trabalho será fazer o que ele já sabe: explorar todo o potencial da linguagem de desenvolvimento e produtividade da ferramenta de trabalho integrada, como Visual Studio (Integrated development environment/Rapid Application Development).

O próximo passo é romper discursões inúteis dos resistentes na área de desenvolvimento que, sem conhecer ou testar, já gritam de imediato “Não é rápido, não confio, gosto de fazer tudo a mão, não tenho o controle”. Se você analisar o código fonte de uma aplicação em um cenário padrão de desenvolvimento de software, na maioria dos projetos o que encontramos é uma consulta ao banco de dados trazendo um volume grande de dados para que seja filtrado na camada da aplicação.

Esse é o momento de analisarmos como as consultas estão sendo implementadas hoje. No Oracle e SQLServer temos recursos como RowNumber para paginação de registros. Pergunte quem usa? Usando ORM basta pedirmos a quantidade de linhas e a página desejada que trazemos o bloco específico de registros para mostrar na tela ao usuário. Avaliando, o esforço na implementação será mínimo com uso de um simples parâmetro. É importante você ter em mente que a plataforma de ORM é otimizada para gerar a melhor consulta no banco de dados.

Trazendo a visão para um pensamento em C#, o processo é muito simples e já faz parte do seu dia a dia. Ou seja, por padrão você já é obrigado a saber e implementar orientação a objetos, então, basta instanciar a classe mapeada, efetuar as consultas e deixar o ORM gerar internamente o T-SQL para falar com o banco de dados e retornar os dados para a sua aplicação no formato de objetos. Se você está curioso para saber como ele está trabalhando, basta ligar o profile e verá a query gerada. Com o tempo nem lembrará mais o quanto você sofria e vai perceber apenas o peso do qual se livrou.

Conforme citei no inicio, a partir do momento em que você tira a inteligência do banco de dados e traz de volta para a aplicação, você terá um único local padronizado para manter o seu código fonte, que associado a testes unitários e integração contínua elevará o desenvolvimento do seu projeto para um novo patamar em produtividade e, principalmente, qualidade de software. E isso resulta em uma importante economia no ciclo de desenvolvimento, acelerando e removendo muitas dificuldades encontradas.

Considere esse tipo de resistência como fato natural do ser humano com relação a mudanças. Para se ter ideia, em 1904 passamos por um fato histórico interessante conhecido como Revolta da Vacina, no Rio de Janeiro, onde pessoas extremamente revoltadas não aceitavam a vacinação obrigatória contra a varíola com medo do vírus e hoje brigamos para ser vacinados – também por medo do vírus. Esteja atento, pois a nova geração de profissionais já não convive mais com esse fantasma. Então aproveite a oportunidade e livre-se também.

O tempo do software em caixinha já se foi! Hoje não dá para pensar em mais nada que não seja focado em serviço e para distribuição em larga escala. O seu conceito vai começar a mudar quando passar a entender que aplicações de alta performance dependem minimamente do banco de dados. No mundo do software como serviço (SaaS) não tem espaço para gargalos. Temos infraestrutura de aplicação para High Performance Web Sites como um serviço padrão de cache e Message Queue, organizando processos e filas sempre pensando em não criar gargalos na aplicação em função de outros recursos agregados.

Com a velocidade que os negócios estão mudando, não podemos mais nos dar ao luxo de fechar os olhos e continuar colhendo milho da mesma maneira, achando que essa é a melhor forma porque foi a forma que você aprendeu. Desenvolver software é um desafio diário e compete a todos nós estarmos prontos para entender as mudanças e nos adaptar para que possamos responder as demandas de negócios no tempo certo e com qualidade.