O objetivo dessa palestra foi desmistificar um pouco o entendimento sobre Domain Driven Design. O foco foi demonstrar que essa abordagem não é sobre padrões, como bem me aconselhou o Rodrigo Yoshima. Enfatizei a comunicação como fator importante e comparei arquiteturas existentes por má compreensão não só da “Orientação a Objetos”, mas por dogmatismo e ignorância.

Como eu conheço bem o mercado local, enfatizei algumas más práticas que considero o empecilho aos projetos, principalmente as “arquiteturas de referências” que se proliferam aqui e impactam na modelagem.

Fizemos um “Hands On” rapidinho e não tem como não falar sobre TDD, afinal, modelagem ágil passa invariavelmente pelo Test First. “Fizemos”, porque tive a ajuda do @rponte.

Descobri só ontem que existe tradução do livro Domain Driven Design do Eric Evans, eu recomendo comprarem o original na Amazon, mas se forem comprar em português que seja pelo meu link.

A InfoQ publicou um minibook sobre o tema.

Vou subir a aplicação que codificamos ontem para o github e atualizo essa página quando estiver disponível. Algumas fotos que foram tirados voces conferem aqui.

Algumas referências importantes sobre o que falei ontem:

http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/

http://fragmental.tw/2010/02/24/everyday-tales-anatomy-of-a-refactoring/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%E2%80%93-part-2/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%e2%80%93-part-3/

http://fragmental.tw/2010/03/22/nevermind-domain-driven-design/

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…

“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.

Essa base mínima eu proponho que seja – dentro do modelo exposto -  raciocínio lógico. O resto ele pode aprender.

Raciocínio lógico está ligado diretamente a noção de avaliar a situação, encontrar um padrão, investigar soluções existentes e implementar a solução, além claro de bom senso.

Não adianta pregarmos que os profissionais deveriam ser melhor escolhidos assim ou assado porque a realidade é que as empresas não tem como medir satisfatoriamente quem é ou não competente e mais cedo ou mais tarde você se deparará com indivíduos em sua equipe vindos por diversas nuances administrativas, seja aquele superqualificado cheio de títulos ou o primo do diretor da empresa.

Aonde quero chegar com essa história?

Precisamos avaliar os riscos necessários com bastante antecedência para que toda a equipe e consequentemente o projeto não sejam lesados e paguem o preço da incompetência às vezes de um único elemento. Parece óbvio? Acredite, não é!

Temos um projeto em um cliente – uma Alfândega – que precisamos refatorar todo o código criado por um determinado profissional com apenas dois ou três meses pronto. O projeto ainda está no início e já temos que refazer código.

Convenhamos, tudo bem que o código de meia hora atrás já é legado, mas código tão recente não deveria já ser refatorado sem mudança na lógica de negócio ou arquitetural. Algo muito errado aconteceu.

Mudanças não funcionais acontecem, surge um novo paradigma ou framework que reduz o tempo de desenvolvimento e convenientemente é adequado sua mudança, isso é comum durante a manutenção de um software já em produção com um meio século de uso – que em informática dura cerca de 4 ou 5 anos.

O nosso em questão não há motivos. Projeto novo, sem restrição ou adequação à “Arquitetura de Referência”, Frameworks de última milha na plataforma Java como JSF, Spring e Hibernate. Testes unitários – mas não TDD.

Como dito, separei um exemplo em código para demonstrar aonde quero chegar. Tem uma lógica bastante simples, existe um processo de apreensão de mercadorias na alfândega e liberação dessa mercadoria.

Há 3 tabelas que representam isso no modelo E/R: TB_DEVOLUCAO, TB_ITEM_APREENSAO, TB_ITEM_DEVOLUCAO. Segundo a lógica relacional, a TB_ITEM_DEVOLUCAO é uma tabela de junção entre a devolução e os itens apreendidos para indicar que item será devolvido.

Seguindo minha definição, um profissional com raciocínio lógico encontraria fácil a solução do mapeamento entre essas entidades apenas lendo a documentação, ele saberia que o Hibernate tem um mapeamento de OneToMany com Join Table Uni ou Bidirecional.

Mas não, ele criou essa bizarrice:

@Entity
@Table(name="TB_DEVOLUCAO")
public class Devolucao {
 
	@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.ALL)
	@JoinColumn(name="SEQ_ITEM_DEVOLUCAO")
	@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
	private List<ItemDevolucao> itensDevolucao = 
		new ArrayList<ItemDevolucao>();
 
}
 
@Entity
@Table(name="TB_ITEM_DEVOLUCAO")
public class ItemDevolucao { //Para que essa entidade?
 
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	@Column(name="SEQ_ITEM_DEVOLUCAO", columnDefinition="NUMERIC")
	private Integer codigo;
 
	@OneToOne
	@JoinColumn(name="SEQ_ITEM_APREENSAO")
	private ItemApreensao itemApreensao;
 
}

Esse profissional em questão é graduado em computação, tem mestrado em uma federal, certificação como arquiteto Java e diversas outras certificações e pasme, anos de experiência em projetos. Mas não tem o básico, raciocínio lógico. Não investiga e não sabe desenvolver software de qualidade.

O código em questão pode parecer bobagem até mas isso se repete em todo o código criado por esse profissional.

Um profissional responsável em refatorar o código com apenas curso técnico e uma mísera certificação de programador java refatorou assim [como deve ser]:

@Entity
@Table(name="TB_DEVOLUCAO")
public class Devolucao {
 
	@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.ALL)
	@JoinTable(name="TB_ITEM_DEVOLUCAO",
		joinColumns = @JoinColumn(name="SEQ_ITEM_DEVOLUCAO"),
		inverseJoinColumns = 
				@JoinColumn(name="SEQ_ITEM_APREENSAO")
	)
	@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
	private List<ItemApreensao> itensDevolvidos = 
				new ArrayList<ItemApreensao>();
 
}

Ad Hominem da minha parte? Tomar uma exceção pela regra? nada disso, eles são legião! Isso é meu cotidiano.

O prejuízo que esse profissional acarreta a todos os envolvidos é enorme e até difícil de ser mensurado porque envolve custos e humor da equipe que impacta em outros custos imperceptíveis na conta final que é a “fodisse” dos caras que tiveram que refatorar, ou seja, fizeram o seu e o trabalho alheio.

Ah, mas XP não prega o código coletivo? ir lá e consertar? Mas quebra o principal valor que é “Respeito”. Além do mais o projeto em questão seque o velho Cascata – mas culpa do cliente que exigiu ser assim, exigiu não, obriga.

Pela minha experiência de nada adianta você jogar um Clean Code nas mãos dele e pedir para estudar, ele vai continuar escrevendo nmDesc em uma propriedade ou IRepository em uma Interface. Ele foi treinado assim e sem raciocínio lógico no máximo que voce vão conseguir é retreiná-lo para conseguir comer a banana por outro túnel.

Um projeto sem um líder técnico responsável com aptidão e experiência necessária aliado a método baseado em BDUF sem um processo restritivo [como TDD] com modelagem ultrapassada com papéis de analista de sistemas “UMLizados” deixa esse tipo de profissional cometer esses pecados e prejudicar a todos os envolvidos retrabalho desnecessário.

É fácil resolver isso? É! O problema maior é que não podemos simplesmente aceitar que “o cliente quer assim”, temos um dever ético com nossa profissão de não permitir que o paciente escolha como ele quer ser operado e ceder médicos que não tenham capacidade de operá-lo.

… A comunidade em volta da JCP adotou a aberração proposta pela SUN chamada EJB e o mecanismo de persistência seria uma JSR especialista chamada JDO. JDO seria a solução deifnitiva onde não importaria se você usa um txt, um xml ou um Banco de dados parrudo.

Com esse modelo de desenvolvimento foi criado um catálogo de Design Patterns[?] que serviria de “tábua dos 10 mandamentos” para a comunidade. Nasceu a prova de certificação em Arquiteto java com base nessa arquitetura.

Por fora da JCP uma turma se dedicou a criar uma forma de persistência específica para bancos de dados relacionais [Hibernate] onde não estavam preocupados se você guardava seus dados em um xml, queriam apenas resolver os problemas clássicos do mapeamento objeto-relacional. Outro pessoal jogava fora o modelo EJB e criava sua própria JEE [Spring] com técnicas e abordagens que surgiam como IoC, DI, Aspect Programming.

Com esse modelo de desenvolvimento, baseado sobretudo no conjunto de Design Patterns [PoEAA] da turma do Fowler, aposentaram o modelo da SUN apreciado pelos membros da JCP e redirecionaram o comitê para a aprovação de especificações copiadas desse outro modelo.

… and they lived happily ever after.

…

Opa, faltaram atualizar a prova de Arquiteto Enterprisey para adequar aos Patterns corretos. Ainda leio na ementa da prova no capítulo sobre Patterns:

• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
• From a list, select the benefits and drawbacks of a pattern drawn from the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
• From a list, select the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

Minhas críticas derivam principalmente da falácia e do sofismo, as pessoas acreditam que possuir um nível superior as credita para a qualificação necessária a uma determinada tarefa simplesmente. Quantos alunos estão se formando esse ano em Ciência da Computação sem a necessária qualificação? A maioria? Todos? Nenhum? Como saber se não existe um mecanismo eficiente de provar isso?

Na ausência de um mecanismo eficiente, o mercado sempre adota pontos factuais para basear suas contratações, e uma delas é o porte de um diploma de curso superior.

Fiz quase todas as cadeiras que envolvem desenvolvimento de software: Estrutura de dados, laboratório 1 e 2, técnicas de programação 1 e 2, lógica matemática, teoria da computação, entre outras que não lembro no momento. Em todas essas cadeiras nunca ouvi o professor(a) sequer mencionar coisas como: Closure, Currying, Continuation, Design By Contract, Actor model, Lazy evaluation, Tail recursion, Quine, Engine, Liskov substitution principle, … mais algumas coisas que não lembrei no momento …

O básico de orientação a objetos é ensinado, o aluno consegue até responder o que é herança e encapsulamento, mas eu nunca vi sequer mencionarem Orientação a Objetos Prototype-based, aí tenho que me deparar com gente dizendo que Javascript ou Lua fede porque simplesmente não entende como funciona os conceitos e acha estranho a sintaxe das linguagens.

Eu mesmo passei a faculdade inteira sem discutir design patterns, com exceção de DAO, que eventualmente pula na frente dos alunos em alguma cadeira obscura de "desenvolvimento web" (sic). Hoje um amigo estava impressionado com as recomendações que o pessoal da SUN passou sobre o GoF na caravana de ontem, e eu falei para ele que isso é naftalina, sério, se em 2007, o GoF é novidade para você, algo de muito sério aconteceu com sua formação.

Tive um professor muito bom, Hélio Moura, que usava na época a primeira edição do livro "Applying UML and Patterns"(que é de 1997 e faz portanto 10 anos) do Craig Larman, referência na época para RUP, e passou alguns princípios legais como GRASP, Law of Demeter, Open/closed principle, entre mais algumas coisas legais que não lembro agora. Mas isso foi uma exceção, e esse professor não ministra mais aulas na faculdade onde estudo. Isso era coisa de 99 ou 2000, início do milênio, vi que os professores de lá ainda usam a mesma versão do livro do Craig. Detalhe, já estamos na terceira edição e com mudanças significativas.

Agora PoEAA do Martin Fowler que é bom, voce vai passar batido, nem tenha esperança de discutir isso em sala de aula.

Domain Model? isso é anos-luz da academia brasiliana, vá estudar que é melhor. Domain Driven Design também é assunto inexistente, procure outra freguesia.

Metodologias ágeis, enquanto a academia está descobrindo XP (timidamente claro), o mercado já discute a fusão entre XP, Scrum, FDD, Crystal, DSDM. Até a Microsoft tem métodos ágeis enquanto a academia consolida UPs como novidade.

A maioria sai da faculdade monoglota, com apenas o conhecimento específico de uma linguagem de programação, enquanto deveriam estudar princípios, estão estudando linguagem. Programação funcional até pode ser vista, talves raramente em uma cadeira de calculo, ou IA (com LISP) se der tempo, alguns confundem sentenças com paradigmas, tinha um professor que falava que por a linguagem ter sentença condicional como um "IF", ela não poderia ser considerada 100% Orientada a objetos, entre outras sandices bizarras. DSL? bah!

Conversando com um amigo dia desses lá na faculdade, entramos no assunto banco de dados, sem querer surgiu no meio da discussão sobre formas normais, para minha surpresa ele disse que não sabia do que eu estava falando, achei estranho porque o professor de banco de dados 1, cadeira responsável por esse conteúdo, é um excelente professor, Fernando Siqueira, e conhecendo ele eu sabia que não passaria ninguém sem ensinar formas normais. Depois esse meu amigo voltou e falou que deu uma "olhada" no livro e "lembrou". Ora, isso me causa apreensão, mesmo eu sabendo que o professor tem a competência sobre uma matéria e tenho certeza que a aplicou, porque um aluno simplesmente esquece o principal conteúdo de uma determinada matéria?

São mistérios, mas mistério mesmo é uma menina que se forma esse ano e não sabe ainda para que serve um banco de dados, mesmo evidentemente ter cursado todas as cadeiras de banco de dados. Isso sim merece estudo, tese, trabalhos científicos e tudo que nós pudessemos descobrir.

Livros

A minha escola real são os livros, tive e tenho alguns bons professores, uns poucos excelentes, mas os autores clássicos são os mestres dos meus mestres. Não procure livro específico, procure autor, e toda a cultura por volta desse autor.

Posso indicar alguns que são a base da carreira de qualquer desenvolvedor que se preze: Alan S. Koch, Alistair Cockburn, Bertrand Meyer, Craig Larman, Eric Evans, Joshua Kerievsky, Kent Beck, Martin Fowler, Rod Johnson, Ron Jeffries, Steve McConnell, Robert C. Martin, … isso só dando uma olhadela aqui na minha "biblioteca". Sei que esqueci nomes importantes, mas se você seguir essa lista, vai acabar caindo neles.

O pior disso tudo é que o pessoal fica empolgado com título aqui, o cara virou doutor já se acha semi-deus, são praticamente inacessíveis, é muito mais facil você falar com Martin Fowler do que falar com um Doutor brasileiro.

Então voce tem duas alternativas, estudar ou frequentar a faculdade, dá para conciliar as duas, mas a preferência será sempre para o estudo, ele que pagará o leite de cada dia, aliás… leite não que esse está matando ultimamente, e ei que pensei que era a cerveja

Nessa época passavamos pelo treinamento da Evolução com uma figura que ministrava tudo que havia de mais insano nesse campo, BOLOVO na vêia, e com essa palestra consegui abrir muitos olhos. Essa talves foi a palestra mais importante da minha vida em termos de eficiência na mensagem passada e nos objetivos alcançados.

O padrão Bridge define o desacoplamento da abstração (interface) com suas implementações e cada implementação possa variar independentemente.

No código passado vimos isso implementado na função addEvent como segue:

var addEvent = function(el, type, fn) {
    el['on'+type] = fn;
};
if(document.addEventListener) {
    addEvent = function(el, type, fn) {
        el.addEventListener(type, fn, false);
    };
} else if(document.attachEvent) {
    addEvent = function(el, type, fn) {
        el.attachEvent('on'+type, fn);
    };
}

Nesse código o método addEvent é uma forma genérica de adicionar eventos a um elemento DOM na página e encapsula o comportamento implementado pelos Browsers. Essa estratégia pode e deve ser adotada em todo o código que necessite de implementação diferente dependendo do navegador, o chamado Cross Browser.

Cross Browser é a técnica de implementar uma construção que rode em múltiplos navegadores sem diferença perceptível ao usuário. O custo de aplicar essa técnica é diminuir a performance da aplicação como um todo, aumentar a complexidade do código mantido, propiciar um ambiente mais sujeito a falhas de implementação e cair em bugs do próprio navegador (como o Memory-Leak no IE).

Instanciar o objeto XMLHttpRequest é outra situação que possui diferença entre o líder de mercado e os demais navegadores. Aplicando essa técnica, faríamos o seguinte código:

var getXHR = function() {
	this.http = new XMLHttpRequest;
	return this.http;
}
var isIE = !!document.attachEvent;
if(isIE) {
      var msxml = [
        'MSXML2.XMLHTTP.3.0',
        'MSXML2.XMLHTTP',
        'Microsoft.XMLHTTP'
      ];
      for (var i=0, len = msxml.length; i < len; ++i) {
        try {
          http = new ActiveXObject(msxml[i]);
          //cria nova implementação
          getXHR = function() {
            return new ActiveXObject(msxml[i]);
          };
          break;
        }
        catch(e) {}
      }
};

Dei a dica no artigo passado de criar um arquivo para cada implementação de navegador diferente e aplicar o conceito de Lazy Loading para carregar sob demanda.