O desenvolver RAD?Ferramentas RAD, ou Rapid Application Development (desenvolvimento rápido de aplicação), é o termo usado para definir ferramentas que estimulam o design visual da interface gráfica, e alta reutilização de componentes, de forma a produzir uma aplicação no menor tempo possível. Lembro, por exemplo, que quando estávamos no tempo do Visual Basic clássico, muitos diziam que o VB era RAD, e o C++ não era (mesmo possuindo também sua suite de componentes visuais – mas que nem de longe chegavam à simplicidade e produtividade do VB). Na época era comum fazer a regra de negócio em C++ e só a apresentação em VB. As empresas mantinham equipes distintas pra isso.

Os componentes visuais RAD costumam ser data driven, ou seja, o foco é exibição e manipulação de dados, e até mesmo ligados aos registros de banco de dados. Alguns componentes tinham ainda uma forte ligação com o banco de dados.

Aí fico pensando… Rapid Application Development. Rapid. Veloz. Penso em veloz e logo penso ágil. E quando penso ágil, não penso em controles data driven, no estilo drag and drop, que ligam a tela ao banco de dados, para fazer aplicações. Não penso em “forms over data”.

Tanto que, ao pesquizar o que era RAD para colocar aqui, encontrei uma definição da Wikipedia coloca RAD com os pés no desenvolvimento ágil. Fala que RAD é iterativo, coloca que XP e Scrum são formas de RAD.

É assim que entendo RAD: desenvolvimento rápido só pode ser feito quando você trabalha direito, com boas práticas, com uma boa arquitetura. Nas minhas palestras sobre boas práticas (como a última) falo que sempre que o desenvolvedor ignora alguma boa prática de desenvolvimento, e fica só arrastando e soltando coisas na tela, ele se vê como o The Flash, que coloquei aqui no começo do post, quando na verdade, quanto mais ele trabalha “RAD”, mais ele se parece mais com isso:

O desenvolver RAD!

Quanto mais rápido você tenta ir, ignorando as boas práticas de desenvolvimento, mais débito técnico você adquire, e mais devagar você vai. Em pouco tempo a produtividade do projeto cai, e você está preso no código legado que você mesmo escreveu, um mês atrás.

Isso porque uma aplicação feita com “forms over data”, com componentes ligados ao banco de dados, é acoplada demais, difícil de testar, possui regras de negócios duplicadas em vários lugares, e código macarrônico, impossível de entender (entre outros inúmeros problemas).

Portanto, rápido mesmo é fazer direito, limpo, com boas práticas, com arquitetura adequada. Ferramentas RAD são muito úteis sim, desde que você saiba usá-las. Desenvolver telas com código dá muito mais trabalho, e você precisa dominar a tecnologia que está trabalhando (daí tanta crítica ao ASP.Net MVC) e por isso não sou contra designers visuais, sou contra aplicações feitas somente com eles, ou abusando deles. Não faça data binding com seu banco de dados, faça com seus objetos de domínio. Use OO, DDD, TDD. Use padrões de arquitetura da interface gráfica, como os citados pelo Fowler aqui (e aqui, do lado direito tem os presentation patterns). Vai lá ler, é grátis, e a leitura é obrigatória.

Com frequência os clientes me chamam para ajudar a definir o backend das aplicações, definimos o método de acesso a dados, aplicamos DDD, usamos WCF, fica tudo lindo, escalável, fácil de entender, etc. Quando vamos entrar na interface gráfica, o cliente diz que já sabe fazer, ele usa ferramentas RAD. Faz sem boas práticas, e o resultado é uma aplicação limpa, mas só de uma camada pra frente. Aí acabo tendo que voltar pra explicar onde está errado, e o cliente acaba tendo que refazer um pedaço da aplicação.

Pense nisso.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.