Para suprir essa necessidade de usabilidade tivemos que adotar alguns conceitos, como ser totalmente stateless e modificar a arquitetura MVC2 para o MVC3. No server-side trabalhamos com um domain model baseado em Hibernate, Spring e Facades e Services com DWR. Nada de frameworks MVC2, não nos preocupamos com renderização e sim com a API. No lado cliente usamos Extjs com algumas modificações que fiz para integrar de forma suave com o DWR.

Primeiro precisamos entender como o Extjs trabalha com herança. Basicamente há um método no objeto Ext que faz esse trabalho de estensão dos componentes, funciona da seguinte maneira:

//Formato:
var NovoComponente = Ext.extend(velhoComponente, { 
          /* metodos e propriedades que serão reescritas */ 
});
 
//Exemplo:
var MilfontGridPanel = Ext.extend(Ext.grid.GridPanel, {
        //novo construtor
        constructor: function(config) {
            // Seu preprocessamento vai aqui
        	MilfontGridPanel.superclass.constructor.apply(this, arguments);
            // Seu pos-processamento vai aqui
        },
 
        NovoMethod: function() {
            // algum novo método que você queira criar para o novo componente
        }
    });

Para esse projeto, criei um Ext.data.DataProxy (como visto no artigo passado) especialista para o DWR, criativamente denominado DWRProxy. A idéia é modificar o comportamento de buscar os dados para usar um Creator do DWR.

Definimos primeiro o objeto e suas propriedades necessárias:

Ext.ux.data.DWRProxy = function(dwr_facade, dwr_filter, dwr_errorHandler){
 
    Ext.ux.data.DWRProxy.superclass.constructor.call(this);
 
	/* Propriedade que receberá a classe Java configurada como Creator */
    this.data = dwr_facade;
    /*
	 * Propriedade que receberá uma classe java configurada como converter
	 * que servirá como filtro de busca
	 */
 
	this.dwr_filter = dwr_filter;
 
	/**
	 *
	 * Propriedade para fazer paginação, indica que deve cachear a consulta de
	 * total de elementos o controlador [fachada] deve implementar a logica de
	 * negocios adequada, quando for false consulta o total, quando for true
	 * consulta apenas a listagem e repete o total
	 */
 
	this.dwr_total_cache = false;
 
	this.dwr_errorHandler = dwr_errorHandler;
 
};

Após isso extendemos do Ext.data.DataProxy :

Ext.extend(Ext.ux.data.DWRProxy, Ext.data.DataProxy, {
 
    /**
     * Método Load do Ext.data.DataProxy overrided
     */
 
    load : function(params, reader, callback, scope, arg) {
 
	/**
	 * Escopo "this" mapeado para a variável "s" porque dentro do callback do
	 * DWR o escopo "this" não pertence ao objeto Ext.ux.data.DWRProxy.
	 */
 
	var s = this;
 
        params = params || {};
 
        if(params.cache != undefined) {
		this.dwr_total_cache = params.cache;
	}
 
	if(params.filter != undefined) {
		this.dwr_filter = params.filter;
	}
 
        var result;
 
        try {
		this.data(this.dwr_filter, params.start, params.limit, this.dwr_total_cache, {
			callback:function(response) {
                                //aqui passamos o retorno do DWR 
                               // que chamei de response,  para o extjs
				result = reader.readRecords(response);
				callback.call(scope, result, arg, true);
			},
			errorHandler:function(a, e) {
				scope.fireEvent("loadexception", s, arg, null, e);
				s.dwr_errorHandler(a);
			},
			timeout:100000
		});
 
		this.dwr_total_cache = true;
 
        } catch(e) {
            this.fireEvent("loadexception", this, arg, null, e);
            callback.call(scope, null, arg, false);
            return;
        }
 
    }
 
});

A fachada DWR é uma classe comum, segue um exemplo de uso com Hibernate:

//classe para satisfazer o transporte para o Extjs
public final class DataTransferObject {
    private int total;
    private List<? extends Object> results;
    //sets e gets
}
 
public class AjaxFacade {
    //injeta um repositorio, whatever
    private Repository repository = null;
 
    public DataTransferObject find(Object filter, int start, int limit, boolean cache, HttpSession session) {
        DataTransferObject dto = new DataTransferObject();
        //verifica se o Proxy está passando true 
        // indicando que está paginando
        if (cache) {
            Integer total = (Integer) session.getAttribute("totalObject");
            dto.setTotal(total);
       } else {
            session.removeAttribute("totalObject");
            Integer total = repository.count(filter);
            dto.setTotal(total);
            session.setAttribute("totalObject", total);
        }
        List<Object> retorno = (List<Object>) repository.find(filter, start, limit);
        dto.setResults(retorno);
        return dto;
    }

Para o Grid visto no artigo passado, basta instanciar assim no javscript:

var store = new Ext.data.Store({
    proxy: new Ext.ux.data.DWRProxy(
        AjaxFacade.find, 
        {$dwrClassName:"Project"}, 
        errorHandler
    ),
    reader: new Ext.data.JsonReader({
            root: 'results',totalProperty: 'total',id: 'id'
        }, 
        ['id', 'name', 'manager.name', 'manager.address.country']
    )
});

Para entender o {$dwrClassName:”Project”} visite esse post.

Dessa forma o DWR se torna um proxy para todos os componentes do Extjs.

Código fonte da modificação do javascript eu coloquei aqui no github e uma aplicação demo aqui. No próximo vou integrar o DWR com o Rails, aguardem que sai logo… ou não.

Esse tutorial tem o objetivo de preparar o conhecimento para outros posts que estou escrevendo e achei necessário uma introdução apenas nos conceitos do Extjs para não confundir com as tecnologias que uso em conjunto como DWR ou no modelo REST com o RubyOnRails.

O Extjs é um framework javascript de propósito geral, ou seja, tem um conjunto de funcionalidades que tratam Ajax, um conjunto de Widgets bem elaborados [componentes visuais como Grid e TabPanel], manipulação de DOM [Document Object Model] e BOM [Browser Object Model], tratamento de eventos, animações como Fade In e Fade Out, parser de JSON, entre outras coisas. Seus componentes são construídos com técnicas modernas de orientação a objetos no javascript e manipulação de Scripttag para recursos remotos que não suportam Ajax.

Preparação

Após baixar e descompactar o framework [estou trabalhando na versão 2.x que é estável nessa data], recomendo que deixa a disposição das pastas conforme se encontra e coloque no seu projeto de forma que seja acessível via web, já vem com documentação e exemplos que você deve e vai usar durante o desenvolvimento. Temos a opção de montar o Extjs [marcando a opção "Make build available via CacheFly" ] no CacheFly como um servidor CDN para otimizar o tráfego de sua aplicação principalmente se ela será disponibilizada na internet e não apenas na intranet.

É necessário importar o CSS global, o adapter e o Javascript global conforme mostrado abaixo:

<link rel="stylesheet" type="text/css" href="/javascripts/ext-2.2.1/resources/css/ext-all.css" />
<script src="/javascripts/ext-2.2.1/adapter/ext/ext-base.js" type="text/javascript"></script>
<script src="/javascripts/ext-2.2.1/ext-all.js" type="text/javascript"></script>

Pode usar outros temas para o Extjs, estarão na pasta “resources/css“, assim como podemos internacionalizar os componentes com arquivos que se encontram em “build/locale“. Exemplo com o tema “Gray” e i18n em português do Brasil:

<link rel="stylesheet" type="text/css" href="/javascripts/ext-2.2.1/resources/css/ext-all.css" />
<link rel="stylesheet" type="text/css" href="/javascripts/ext-2.2.1/resources/css/xtheme-gray.css">
<script type="text/javascript" src="/javascripts/ext-2.2.1/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="/javascripts/ext-2.2.1/ext-all.js"></script>
<script type="text/javascript" src="/javascripts/ext-2.2.1/build/locale/ext-lang-pt_BR-min.js"></script>

Internacionalização é algo pensado no Extjs de forma a facilitar a criação de arquivos de linguagem aproveitando a estrutura da linguagem [dinâmica e fracamente tipada], todas as propriedades de mensagens e textos são públicas para facilitar a reescrita como mostrado abaixo na i18n do componente de DataPicker:

if(Ext.DatePicker){
   Ext.apply(Ext.DatePicker.prototype, {
      todayText         : "Hoje",
      minText           : "Esta data é anterior a menor data",
      maxText           : "Esta data é posterior a maior data",
      disabledDaysText  : "",
      disabledDatesText : "",
      monthNames        : Date.monthNames,
      dayNames          : Date.dayNames,
      nextText          : 'Próximo Mês (Control+Direita)',
      prevText          : 'Mês Anterior (Control+Esquerda)',
      monthYearText     : 'Escolha um Mês (Control+Cima/Baixo para mover entre os anos)',
      todayTip          : "{0} (Espaço)",
      format            : "d/m/Y",
      okText            : " OK ",
      cancelText        : "Cancelar",
      startDay          : 0
   });
}

Se você usar o CacheFly gerado pela página do Extjs, ele incluir o adapter e o global em um mesmo arquivo, vai ser algo como:

<link rel="stylesheet" type="text/css" href="http://extjs.cachefly.net/ext-2.2.1/resources/css/ext-all.css">
<link rel="stylesheet" type="text/css" href="http://extjs.cachefly.net/ext-2.2.1/resources/css/xtheme-gray.css">
<script type="text/javascript" src="http://extjs.cachefly.net/builds/ext-cdn-771.js"></script>

Adapter

Quando o Extjs passou a ser um framework independente do YUI, passou a adotar outros frameworks como base para funções básicas de manipulação de DOM e Ajax, hoje suporta trabalhar em conjunto com YUI, JQuery, Prototype e totalmente independente. Se o projeto já tem Jquery ou outro framework que trabalha com o Extjs, a utilização dos dois é muito fácil e indicada, principalmente para usar os widgets que são provavelmente os mais poderosos hoje em dia em um framework opensource.

//Exemplos de adapters permitidos
<script type="text/javascript" src="/javascripts/ext-2.2.1/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="/javascripts/ext-2.2.1/adapter/jquery/ext-jquery-adapter.js"></script>

Widgets

O principal apelo do Extjs que conquista os desenvolvedores é o layout bem trabalhado dos componentes visuais que são de fácil parametrização. Basicamente todos os componentes funcionam da mesma forma, você o instancia passando um objeto literal de configuração com mostrado abaixo:

//Exemplo do grid
var grid  = new Ext.grid.GridPanel({
autoShow:true, width:750,height:250 //mais parametros 
});
//Exemplo de uma Window
var window = new Ext.Window({
autoShow:true, width:750,height:250 //mais parametros 
});
//Exemplo de um Painel
var panel = new Ext.Panel({
autoShow:true, width:750,height:250 //mais parametros 
});

Vamos usar o GRID para exemplificar como trabalhamos com o Extjs, o mesmo comportamente se repete em todos os componentes.
A documentação do Extjs é muito bem feita e praticamente vai ser a única coisa que você vai precisar depois de entender como os componentes são formados, afinal não vale a pena decorar todas as propriedades de todos os componentes, concentre-se apenas em entender os conceitos.

A GRID é o Widget mais famoso desse framework e é formado basicamente por um objeto “Ext.data.Store” [que é a fonte de dados da GRID] e um objeto “Ext.grid.ColumnModel” [que é a definição das colunas], como mostrado abaixo:

var grid  = new Ext.grid.GridPanel({
    autoShow:true, width:750,height:250, //parametros de configuração de layout
    cm: new Ext.grid.ColumnModel({/*configuração*/}),
    store: new Ext.data.Store({}), //Ou especialização de um Store
    sm: new Ext.grid.RowSelectionModel({singleSelect:true}), //ou outra especialização de um AbstractSelectionModel
});

O objeto ColumnModel é a definição de colunas do Grid, possui propriedades para definição de layout como largura e altura, título da coluna como vai ser exibida e formatação do texto:

var colModel = new Ext.grid.ColumnModel([
    { header: "Ticker", width: 60, sortable: true},
    { header: "Company Name", width: 150, sortable: true},
    { header: "Market Cap.", width: 100, sortable: true},
    { header: "$ Sales", width: 100, sortable: true, renderer: money},
    { header: "Employees", width: 100, sortable: true, resizable: false}
 ]);

A propriedade cm [ColumnModel] pode ser também substituída pela propriedade “columns” que funciona como um “alias”, dessa forma o Grid cria automaticamente um objeto ColumnModel:

var grid = new Ext.grid.GridPanel({
    columns: [
        {id:'id', header: "id", width: 200, sortable: true, dataIndex: 'id'},
        {header: "Nome", width: 120, sortable: true, dataIndex: 'name'}
    ]
});

Caso haja necessidade de formatar o conteúdo da célula, você pode usar uma função como “renderer” para tratar esse conteúdo:

var grid = new Ext.grid.GridPanel({
    columns: [
        {id:'id', header: "id", width: 200, sortable: true, dataIndex: 'id'},
        {header: "Nome", width: 120, sortable: true, dataIndex: 'name'},
        {header: "Criado em", width: 135, sortable: true, renderer: function(value) {
                    return Date.parseDate(value, 'Y-m-d\\TH:i:s\\Z').format('d/m/Y H:i:s');
                    //2009-06-14T12:51:07Z
        }, dataIndex: 'created_at'}
    ]
});

A propriedade “store” da GRID é uma especialização do componente “Ext.data.Store” que é formado basicamente por um “proxy” e um “reader“:

var store = new Ext.data.Store({
    proxy: new Ext.data.DataProxy(), //ou uma especialização
    reader: new Ext.data.DataReader() //ou uma especialização
});

O “proxy” é o componente que obterá os dados e o “reader” o componente que fará a leitura desses dados para um formato comum a todos os componentes do Extjs na forma de um objeto denominado “Ext.data.Record“. O objeto “Record” representa um registro de dados e é usado seja para GRID, para um Form ou qualquer componente que trabalhe com dados editáveis.

Dessa forma podemos usar uma combinação de Proxy e Reader como HttpProxy e JsonReader:

var store = new Ext.data.Store({
    proxy: new Ext.data.HttpProxy({
        url: 'projects.json'
    }),
    reader: new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))
});

Devido o costume do uso do HttpProxy, o componente Store possui uma propriedade chamada “url” que estando presente cria um HttpProxy automaticamente como mostrado abaixo:

var store = new Ext.data.Store({
    url: 'projects.json',
    reader: new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))
});

O objeto “Reader” é o único que foge um pouco a regra de instanciação por receber dois parâmetros, um similar aos outros com um objeto literal de configuração e outro com o mapeamento dos dados. O objeto de configuração tem duas propriedades de que representam o total e a lista de dados. O objeto de mapeamento usa um método “estático” do objeto Record para criar um link entre a propriedade do json [com a propriedade "mapping"] e o índice interno do Record [pela propriedade "name"].

 new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))

Dessa forma você tem um link entre o ColumnName pela propriedade dataIndex e o Store por meio do Reader, como abaixo:

Ext.data.Record.create([
         {name:'nome_linkado', mapping:'name'}
    ])
//
 columns: [
        {header: "Nome", width: 120, sortable: true, dataIndex: 'nome_linkado'}
    ]

Para melhorar a navegação da GRID, você pode também acrescentar um componente de Toolbar no header ou no footer:

var grid  = new Ext.grid.GridPanel({
    autoShow:true, width:750,height:250, //parametros de configuração de layout
    cm: new Ext.grid.ColumnModel({/*configuração*/}),
    store: new Ext.data.Store({}), //Ou especialização de um Store
    sm: new Ext.grid.RowSelectionModel({singleSelect:true}),
    bbar: new Ext.Toolbar(), //Bottom Toolbar
    tbar: new Ext.Toolbar() //Top Toolbar
});

A Toolbar mais usada é sua especialização com paginação, a Ext.PagingToolbar que necessita ser linkada com o Store:

new Ext.PagingToolbar({
    pageSize:10, //propriedade opcional, default é 20
    store: store
})

A PagingToolbar é I18n, mas se as mensagens não agradarem você pode mudá-las [eu sempre faço]:

new Ext.PagingToolbar({
    pageSize:10,store: store,
    displayInfo: true,	
    displayMsg: 'Exibindo o resultado: {0} a {1} de {2} registros',
    emptyMsg: "Sem resultados a exibir"
})

Uma coisa bacana nesse componente é que você pode agrupar botões [já que é uma Toolbar] e até padronizar o layout:

new Ext.PagingToolbar({
    pageSize:10,store: store,
    displayInfo: true,	
    displayMsg: 'Exibindo o resultado: {0} a {1} de {2} registros',
    emptyMsg: "Sem resultados a exibir",
    items: ['-', {
        pressed: true,enableToggle: true,text: 'Alterar',
        toggleHandler: function(){}
    }, {
        pressed: true,enableToggle: true,text: 'Excluir',
        toggleHandler: function(){}
	}]
})

Código da GRID inteira:

 
var store = new Ext.data.Store({
    proxy: new Ext.data.HttpProxy({
        url: 'projects.json'
    }),
    reader: new Ext.data.JsonReader({
        totalProperty:'total',
        root:'results',id:'id'
    }, Ext.data.Record.create([
        {name:'id', mapping:'id'},
        {name:'name', mapping:'name'},
        {name:'created_at', mapping:'created_at'},
        {name:'updated_at', mapping:'updated_at'}
    ]))
});
 
var colModel = new Ext.grid.ColumnModel([
    {id:'id', header: "id", width: 200, sortable: true, dataIndex: 'id'},
    {header: "Nome", width: 120, sortable: true, dataIndex: 'name'},
    {header: "Criado em", width: 135, sortable: true, 
        renderer: function(value) {
          return Date.parseDate(value, 'Y-m-d\\TH:i:s\\Z').format('d/m/Y H:i:s');
 
    }, dataIndex: 'created_at'}
 ]);
 
var pagingToolbar = new Ext.PagingToolbar({
    pageSize:10,store: store,
    displayInfo: true,	
    displayMsg: 'Exibindo o resultado: {0} a {1} de {2} registros',
    emptyMsg: "Sem resultados a exibir",
    items: ['-', {
        pressed: true,enableToggle: true,text: 'Alterar',
        toggleHandler: function(){}
    }, {
        pressed: true,enableToggle: true,text: 'Excluir',
        toggleHandler: function(){}
	}]
});
 
var grid  = new Ext.grid.GridPanel({
    autoShow:true, width:750,height:250,
    cm: colModel,
    store: store,
    sm: new Ext.grid.RowSelectionModel({singleSelect:true}),
    bbar: pagingToolbar
});

Como eu falei, todos os componentes possuem o mesmo comportamento, notaram que dá para aproveitar esse código semelhante e reaproveitar em todos os CRUDs?
Vou falando de um por um de acordo com os posts que forem saindo, aguardem que o próximo sai logo… ou não.

Quando falo em testes aqui eu falo no conjunto de todos os tipos de testes, como: unitários, aceitação, integração, carga e demais necessários. A cobertura de testes é um investimento para redução de bugs na fórmula de ROI. Bugs são como “Back Order” na indústria e comércio, além de lucro perdido pela não-venda da mercadoria, ainda fragiliza a marca.

Um ponto crucial: EU ACREDITO EM COBERTURA DE 100%, mas não existe cobertura de 100%, então como podemos conviver com esse paradoxo?

Cobertura de 100% é uma meta ambiciosa de um mundo feliz onde não nos preocupamos com custos e escassez, ou seja, uma utopia. Utopia na vida real não é vendável, precisamos [mesmo a contragosto] medir os dados reais e encontrarmos um padrão aceitável.

Sabemos por consequência que testes aumentam a qualidade do software, eu não tenho tanto problema quanto antes em vender testes de software, mesmo a empresa que não tem testes automáticos, sabem da importância de se testar o software [mesmo que manual].

Meu problema atual é como conseguir vender o aumento da cobertura, mas antes disso eu mesmo preciso entender até quanto testar é suficiente para se pagar.

Power Law

Conversando dia desses na Fortes com o Clavius Tales sobre o seu post de mesmo preocupação, ele me explicava porque encontrou uma função logarítmica e eu tive o mesmo sentimento em dois pontos: que o aumento de testes por mais insignificativo que seja já provoca uma redução drástica de bugs e que ao passar do tempo você tem a impressão de que os testes já não trazem mais retorno, como vocês podem ver no grafico abaixo. Vou chamar esse ponto de “Ponto de Acomodação”.

Fonte da imagem: Blog do Clavius Tales.

Comentei com o Tales que concordo que a função seja mesmo logarítmica, mas que tenho a impressão que a curva é um pouco mais acentuada e o “Ponto de Acomodação Ideal” que deveria ser o “Ponto G” no mundo real é algo entre ele e o “Ponto B” e que devemos ir mais além. No gráfico do Tales ele mostra dois pontos de acomodação, o real no Ponto B [que é um engano e as empresas devem buscar sair dessa área] e o “ideal” no ponto G, aqui tratado.

Então temos dois fatores novos, a curva mais acentuada e o ponto de acomodação, que é o ponto onde as pessoas sentem que não adianta mais testar porque o inicio de testes já reduzem significativamente o número de bugs. Esse ponto de acomodação pode ser explicado por Pareto que é algo que funciona aproximado em quase tudo na vida, dizendo que 20% de alguma coisa geralmente representa 80% do todo.

Tenho ainda um terceiro sentimento provocado pela minha experiẽncia com testes, quanto mais testes nós fazemos, mais cedo detectamos bugs e sempre há pelo menos uma inconsistência que não tinhamos “pensado” antes. Pode até ser que seja finito a quantidade de testes necessários no sistema, mas esse número é muito grande e nunca consegui alcançar na prática, sempre há bugs.

Considerando esses fatores somados, podemos usar os cálculos do Power Law ou cauda longa para melhorarmos o gráfico original do Tales de forma mais aproximado da redução de bugs com o aumento constante de testes no sistema.

Fonte da imagem: Wikipedia

Considero que a meta de cobertura de 100%, mesmo sendo irreal, é algo a ser buscado sempre, forçando o time a se policiar e aumentar o número de testes constantemente mesmo após a acentuada queda de bugs [que chamei de "Ponto de Acomodação"] e que 100% de cobertura não quer dizer livre de bugs porque a cauda sempre vai ser um número aproximado mas nunca toca o zero na prática. Esse caso se aproxima da regra de 98%.

Considero também que dependendo da necessidade de software em produção um número aceitável de bugs a partir do “Ponto de Acomodação” não trás tanto retorno de investimento a curto prazo.

Vou começar a coletar informações de dois projetos atuais para verificar se a tendência desse gráfico satisfaz a realidade. Por enquanto preciso de mais informações para chegar a conclusões melhores.

Em projetos antigos é comum encontrarmos esse tipo de situação, eu mesmo já criei meu framework caseiro em coisa por volta de 6 anos atrás, mas hoje em dia isso não só é algo abominável como um desrespeito pelos profissionais, ainda mais após tanta evolução nos últimos 10 anos.

Conversando com um amigo que trabalha em uma grande empresa de planos de saúde, ele me falou que o “arquiteto java” dessa empresa [conhecido por sua fama de criador de "Framearras"] convenceu a diretoria sobre um projeto recente que se baseia no desenvolvimento de um framework específico para a empresa [eles já possuem um framework caseiro que é um terror e bem conhecido por grande parte dos desenvolvedores locais].

É impressionante como não acaba essa tara de desenvolvimento de frameworks caseiros, qual a necessidade de uma empresa que tem TI como meio [e não como fim] de desenvolver um framework para desenvolvimento de software?

Olha que não é de hoje que eu falo sobre os perigos de frameworks caseiros, mas parece que os defensores desse tipo de abominação se reproduzem como coelhos.

Engraçado que no último projeto que participei eu recebi um treinamento de um dos criadores do framework caseiro que deveríamos usar na construção, alias na continuação de um sistema que está há 5 anos em desenvolvimento sem sinal de algo ir para a produção.

Os argumentos que ele usou foram os seguintes [anotei a frase para não esquecer]:

“Amigos, é importante um framework criado pela propria empresa para padronizarmos o desenvolvimento, diminuindo a curva de aprendizado e ganharmos na produtividade, utilizando padrões consagrados, obtendo reuso nos componentes de negócio e garantindo a manutenibilidade pela fácil criação de código, principalmente CRUD.”

Segredo do fracasso

Vou expor algumas considerações sobre essa frase dele:

Curva de aprendizado

Se algo é complexo de entender por quem conhece os padrões daquilo que se deseja desenvolver, é porque não serve mesmo. Não há como comparar um software opensource consagrado no mercado onde centenas de milhares de desenvolvedores já aperfeiçoaram com algo feito em casa.

Ganho na produtividade

A desculpa número um de todo framework caseiro é a famosa produtividade, sendo que voce sempre perde produtividade porque insere algo fora da normalidade no cotidiano do desenvolvedor. Além do que é insano voce ter uma produtividade no inicio - se fosse o caso, já que não é - comprometendo todo o ciclo de vida restante da aplicação por conta disso.

Porque é isso que acontece, todos esses frameworks caseiros são pensados e desenvolvidos para facilitarem a construção de CRUDs no inicio da aplicação e você tem que sacrificar todo o resto para satisfazer esse capricho que pode ser automatizado facilmente com tecnologias atuais.

Utilização de padrões

Ninguem pode saber que padrão utilizar antes de saber qual o problema, isso é impossível. Ou vai usar um martelo para furar uma parede ou uma furadeira para pregar um prego.

Reuso de componentes

Não existe reuso de objetos de negócios, nenhum processo é semelhante nem que seja na mesma organização ainda mais tentando reusar código por meio ide interface gráfica comum em projetos com dificuldade incial até de separação de pacotes.

Uma alternativa geralmente usada é se comunicar via API ou uma estrutura de serviço como WS, JMS, whatever e não aproveitando uma tela em um sistema distinto.

Aumento da manutenibilidade

Sistema como Frameworks caseiros sempre são dificeis de manutenção por que falta documentação, gente que conheça realmente [além dos próprios criadores], código sempre acoplado, falta de testes, maturidade, e principalmente propósito real [como não haver um existente no mesmo segmento].

Em todos os frameworks caseiros que trabalhei e não foram poucos, a manutenção é algo punitivo porque temos que satisfazer o framework e não o negócio.

Garantia da qualidade

Não há qualidade alguma em frameworks caseiros, pelo contrário, pelo conjunto de más práticas já expostas, o que acontece na realidade é que os sitemas desenvolvidos com esse tipo de ferramenta apresentam uma qualidade baixíssima.

Fork em frameworks do mercado

Problema em fazer um merge no futuro, voce não terá tempo e recurso suficiente para isso. Melhor solução seria submeter patch e codigo para o framework original e acompanhar o desenvolvimento deste. Deixa o desenvolvimento preso a versões antigas.

Associado a cascata.

Quase impossível você encontrar um framework caseiro em uma equipe ágeil, até porque isso fere vários dos valores e princípios.

Menos codificação

Na verdade duplica a codificação para satisfazer o framework.

Extensão de classes genericas

Acoplamento, referencia cíclica, etc… dá até preguiça de escrever.

CRUD Driven Design

Quebra o principio do XP que é fazer o mais importante e crucial primeiro, CRUD nunca é o mais importante. Se voce faz o CRUD primeiro, cria a regra de negócio e refaz todo o CRUD depois.

Geração de codigo sempre reescreve as informações, merge manual.

Frameworks caseiros são #ESFM. Vão complementando com as más práticas…

“Vejo que estou fazendo a coisa certa quando vejo meu saldo bancário!”

Frase dita por um palestrante em um evento recente no ano de 2009.

“Já tentei algumas vezes escrever os testes unitários no começo, mas simplesmente prefiro a abordagem de escrever os testes posteriormente, preferencialmente acompanhando o desenvolvimento das funcionalidades de negócio.”

Notei em diversas consultorias que isso é muito comum por diversos motivos, o principal a meu ver é justamente entender como começa o código do teste, em dois extremos: se depois que definiu o fluxo de processo de negócio de alguma forma [como UML, CRC ou mesmo apenas com UC] ou se já começa algum esboço em código sem ter discutido bem como funciona totalmente o negócio.

A primeira abordagem, definir todo o processo primeiro, deixa a grande maioria dos desenvolvedores confortáveis já que é algo tradicional que vinhamos fazendo, mas o problema é que invariavelmente descamba para BDUF.

A segunda abordagem, que está ligada ao desenvolvimento iterativo e incremental, já deixa um sentimento de que “algo está faltando” em grande parte dos times que tenho trabalhado. A resistência maior é deixar um sentimento de que não preparamos a arquitetura adequadamente e essa pode sofrer um revés num futuro próximo, claro que isso é uma bobagem para quem conhece como TDD funciona, mas é algo comum que tenho notado e precisa ser desmistificado.

Note que não estou falando aqui do sistema inteiro, apenas uma funcionalidade, mesmo assim a mudança cultural de quebrar uma funcionalidade em tarefas e ir desenvolvendo com “passos de bebê” é algo que dificulta a adoção.

Como sanar essas deficiências?

Precisamos de uma forma que conversassemos sobre a funcionalidade inteira mas que me permita ir avançando e atualizando conforme eu vá entendendo melhor como funciona.

Tenho trabalhado essas deficiências nos últimos times que peguei com BDD [Behaviour Driven Development] , iniciando a escrita das histórias [descrição daquela funcionalidade na visão de uma pessoa] seguindo o modelo de template que o Dan North sugeriu. O resultado é que os times avançaram porque eles notaram como iniciar satisfatoriamente com testes sem comprometer a velocidade do desenvolvimento.

O BDD nos trouxe os testes para o inicio de qualquer código, praticamente sem distinguir que se está testando antes e associado com outras práticas como “Programação em Par” facilitou a linguagem ubíqua do time.

Independente se é ágil ou tradicional eu tenho notado uma deficiência na coleta de informações, seja como User Stories ou Use Cases, onde os analistas de negócio, ou seja lá como são chamados nos times, não sabem pensar em negócio. Uma das coisas mais ridículas que vejo é o sujeito explicar para seu time uma funcionalidade com base em um DER ou outra estrutura técnica, dizendo coisas como: “a tabela tal, associada a entidade x”.

Tenho tentado corrigir isso nos times que enfrento como princípio básico, antes de qualquer coisa eu tento disciplinar a pensarem em negócio. Faço exercícios simples como questioná-los com “esqueçam de qualquer termo técnico” e “como essa funcionalidade é no papel?” ou “se não tivesse computador, como fariam isso?”, perguntas simples para instigar o raciocínio sobre a funcionalidade. Após esse exercício, escrevemos essa história em um arquivo e partimos para sua implementação.

Em março desse ano eu palestrei no primeiro encontro da XPCE sobre BDD, vejam os slides. Em termos de ferramentas você pode conferir como temos trabalhado em um projeto recente seguindo os posts do Jefferson Girão:

Parte 1 http://jefferson.eti.br/?p=96
Parte 2 http://jefferson.eti.br/?p=105
Parte 3 http://jefferson.eti.br/?p=139

Enfim, acredito que BDD seja um caminho natural para adoção de TDD por seu time já que eles terão código de teste, antes de qualquer coisa, na forma de negócio e o TDD já florescerá quando forem testar o modelo criado ou sugerido pelo código BDD. Ainda tem uma vantagem adicional, terão a documentação do sistema executável e comprovável.

[http://groups.google.com.br/group/xpce]

Local: Faculdade Lourenço Filho [http://www.flf.edu.br/]

Endereço: Rua Barão do Rio Branco, 2101 Centro. Localização com o Google Maps. Esquina das ruas Barão do Rio Branco com Domingos Olimpio.

Data: Dia 30/05/2009 [sábado] das 09:00h as 11:00h no auditório.

Palestra

09:00 - 11:00

Palestra: Integração Contínua
Resumo: Descubra o que projetos ágeis fazem para possibilitar que diversos desenvolvedores trabalhem juntos em um mesmo projeto, integrando suas contribuições de forma harmônica e segura.
Palestrante: Igo Coelho, fanático por desenvolvimento de software, novas tecnologias, internet, eletrônicos e tudo mais que um geek pode gostar. Com mais de 9 anos de experiência em desenvolvimento de Software trabalha atualmente na Fortes Informática como arquiteto de software com XP e Java. Casado, pai de dois filhos e mantem um blog em www.igocoelho.com.br.

O resultado disso foi a catalogação de todos os buracos no Google Maps [como Mashup da ação], um dos problemas e o mais sério que já causou até capotamento de carro e quebrou o próprio carro oficial da prefeita. Crateras são algo comum em Fortaleza.

Os problemas estão piorando com as fortes chuvas que castigam Fortaleza. Há uma cratera na avenida Leste-Oeste que a prefeitura já fechou várias vezes e vários carros já caírem nela, vide imagem abaixo que capturei na terça-feira quando um caminhão ficou com a roda presa e praticamente parou o trânsito.

Em poucas horas que iniciamos a campanha #buracosfortaleza no twitter, os jornais locais deram a notícia da campanha em seus portais, como OPOVO, Jangadeiro [1], Jangadeiro [2] e Diario do Nordeste.

O Emilio Moreno está fazendo uma cobertura completa da campanha que tenta sensibilizar todo mundo para esse sério problema.

[update 05/05/2009]

Rafael Carneiro postou sobre a campanha.

Mário Aragão postou sobre a campanha.

Natanael Pantoja postou sobre a campanha.

[/update]