Gostaria de compartilhar com vocês o meu método de desenvolvimento de aplicações web. Mas antes de tudo deixo claro que pode até existir técnicas e métodologias melhores. A sequência que descrevo aqui é simplemente um caso real do meu dia dia, como empreendedor e trabalhando em um home office como único desenvolvedor.
As vezes me pergunto se o modo em que eu desenvolvo aplicações a 3 anos é correto, imagine começar a desenvolver primeramente a interface do sistema, ou seja a view, e em seguida as regras de negócio do lado do servidor, pois é, se é correto eu não sei, mas venho usando esta técnica a alguns anos, e percebi que não sou o único no mundo a trabalhar assim.
Imagine um cara contente após ler o livro Getting Real. Imaginou ? Felizmente este cara sou eu. A idéia da 37 Signals, parte deste princípio a qual eu tenho costume de usar, criar situações e usabilidades reais do dia dia dos usuários primeiramente, para dai sim, partir para o desenvolvimento server-side. Hoje procuro documentar o máximo possível seja em uma folha de papel ou até mesmo em fichas pautadas para depois quebrar em tarefas menores caso esta se prolongue com o tempo.
Esta sequência tornou-se mais real após começar a trabalhar diretamente com Flex, o conceito de componentes e interface é o que esta mais próximo do usuário final, e com o Flex Builder ganho tempo criando toda a interface do sistema. O que eu faço é criar um “container” e dentro deste container alojar minhas janelas. Após documentado as telas de cadastros e regras de négocio da aplicação, começo a criar as tarefas que tem prioridade para cliente, então temos.
Cadastro e manutenções de clientes:
1 – Crio um componente window que aloja um form com todos os crud´s desta entidade.
2 – Crio o modelo client e em seguida adiciono todos os campos na migração para criar a tabela clients no banco de dados.
3 – Após rodar a migração faço esta minha window clientes comunicar com o meu controller do lado do servidor, buscando a action a listar que costumo implementar primeiro.
4 – Antes coloco o TDD para funcionar na prática, crio um teste que falhe para a primeira action listar, em seguida crio a regra de négocio para esta ação, sempre testando para manter a casa em ordem.
Para cada modelo, controle e ações faço sempre estes passos, claro chega uma hora que da para reaproveitar estes componentes em outros projetos, mas do lado do servidor é sempre interessante criar tudo.
Há da mais trabalho ? Pode até ser, mas é meu método produtivo de desenvolvimento. Sempre que termino de implementar uma tela com todos os crud, o próximo passo é partir para outra tela e assim sucessivamente. Para telas que possuem LOV(List Of Values) eu crio separamente uma tela(Popup) como um componente para reeaproveitar em um outro momento. Então no ciclo tenho.
1 – Análise
2 – Prioridades no papel
3 – Implementação da interface(window/form)
4 – Criar o modelo na aplicação rails
5 – Criar os campos na migração
6 – Criar o controle
7 – Primeiro teste que falhe
8 – Comunicar pelo menos um crud da interface a uma ação no controller
9 – Novo teste
10 – Implementar a regra de négocio
11 – Mais um teste
Até parece complexo e demorado, na verdade qualquer um com pouca experência em desenvolvimento Flex + Rails, consegue executar estes passos em poucos minutos. Esta é a minha sequência básica, claro que cada caso é um caso, e regras de négocios mais complexas deixo sempre no servidor em um modelo.
O legal de tudo isso é que em pouco tempo já da para mostrar algo real e usual para o cliente e usuários.
Flex + Rails
