Desenvolvimento Orientado a Modinha (DOM)

desenvolvimentoparaweb.com /miscelanea/desenvolvimento-orientado-a-modinha-dom/
17/04/2017
Você é adepto do Desenvolvimento Orientado a Modinha? Saiba como escapar dos hypes tecnológicos
e se preservar através de importantes análises e dicas.

Tárcio Zemel • 17/04/2017 • 19min para ler

Você já trabalhou com equipes que usam aquela metodologia de desenvolvimento infalível, o Desenvolvimento
Orientado a Modinha? Você mesmo já usou (e/ou está usando) a mais nova tecnologia de software que aquela
grande empresa lançou mês passado? Precisamos conversar sobre Hype Driven Development.

Este artigo é baseado em Hype Driven Development, do DaftCode Blog.

Equipes de desenvolvimento de software muitas vezes tomam decisões sobre arquitetura de software ou pilhas
tecnológica com base em opiniões imprecisas, mídias sociais e, em geral, sobre o que é considerado “quente”
(hype), em vez de sólida pesquisa e qualquer consideração séria do impacto esperado em seus projetos. Essa
tendência pode ser chamada de Desenvolvimento Orientado a Modinha ou DOM — originalmente, Hype
Driven Development. Obviamente, existe uma abordagem mais profissional, chamada por alguns de Engenharia
de Software Sólido (Solid Software Engineering). Saiba mais sobre como ele funciona e descubra o que você
pode fazer em vez disso.

Nova tecnologia, nova esperança

Qual seu hype favorito? :-)

Soa familiar? Uma equipe escolhendo tecnologia mais recente, mais “quente” para aplicar no projeto e alguém lê
uma postagem em um blog, vê que é tendência no Twitter e todos acabaram de voltar de uma conferência onde
houve uma grande conversa sobre isso. Logo a equipe começa a usar esta nova tecnologia brilhante — ou
paradigma de arquitetura de software –, mas em vez de ir mais rápido (como prometido) e construir um produto
melhor, começa a se deparar com sérios problemas.

A velocidade de desenvolvimento diminui, todos ficam desmotivados, têm problemas para entregar a próxima
versão do projeto para a produção. Algumas equipes ainda mantêm a correção de bugs em vez de fornecer novos
recursos. São necessários “apenas mais alguns dias” para resolver tudo…

Desenvolvimento Orientado a Modinha ou Hype Driven Development

O Desenvolvimento Orientado a Modinha (ou Hype Driven Development) vem em muitos sabores e toca seu
projeto de muitas maneiras diferentes:

Desenvolvimento Orientado a Reddit. Quando uma equipe ou indivíduo decide sobre a

tecnologia/arquitetura/design com base no blogueiro popular que escreveu o que está quente no Reddit,
Hacker News, blog do Twitter, Facebook, GitHub ou outras mídias sociais.
Desenvolvimento Orientado a Conferência. Observe cuidadosamente o que acontece depois que
pessoas (e programadores) retornam de uma conferência: elas ficam inspiradas. E isso é uma espada de
dois gumes: começar a usar o mais novo paradigma/biblioteca/framework/arquitetura sem pesquisa
suficiente pode ser uma estrada para o inferno.
Desenvolvimento Orientado ao Cara que Fala Mais. As decisões mais influentes são as do que está
falando o tempo todo sobre esse novo framework/biblioteca/tecnologia que ele não tem experiência, mas

1/6
 fala sobre isso o tempo todo e finalmente a equipe decide adotar a coisa.
Desenvolvimento Orientado a Gem/lib/plugin. Um viés especialmente forte na comunidade Ruby On
Rails, em que é possível ver um Gemfile por tanto tempo que a única coisa que leva mais tempo é para
carregar o aplicativo. Vem da idéia de que cada problema em Rails deve ser resolvido através de um gem
— sendo que, às vezes, apenas uma ou duas linhas de código dariam conta do recado ao invés de
resolver o problema acrescentando mais problemas com libs, plugins, gems e/ou frameworks.
Desenvolvimento Orientado a Stack Overflow. Certamente uma das mais comuns de acontecer, dá-se
quando programadores copiam e colam soluções do Stack Overflow (ou encontradas na web, em geral)
sem realmente entendê-las.

A raiz de todo o mal?

O problema com hypes é que eles facilmente levam a más decisões. Tanto a decisões arquitetônicas ruins,
quanto a decisões tecnológicas sobre stacks costumam assombrar uma equipe meses ou mesmo anos mais
tarde. No pior caso, elas podem levar a outra situação muito problemática em engenharia de software: A Grande
Reescrita (The Big Rewrite).

A raiz de todo o mal parece estar nas mídias sociais, nas quais novas idéias se espalham muito mais rápido do
que são testadas; muito mais rápido do que as pessoas são capazes de compreender os seus prós e contras.

A anatomia de um hype
A maioria dos hypes têm uma estrutura similar a esta:

“Ciclo do Hype” (clique para ampliar)

Passo 1: Problema real e solução

Eles começam em alguma empresa com um problema. Uma equipe dentro de alguma empresa decide que a

2/6
solução para o problema está além da pilha tecnológica atual, processo ou arquitetura. A empresa cria uma nova
estrutura, biblioteca ou paradigma e logo o problema é resolvido.

Passo 2: Buzz & Keywords

A equipe está animada para mostrar seu trabalho para o resto do mundo e logo eles escrevem posts e fazem
palestras e conferências. O problema muitas vezes não é trivial, então eles se orgulham de apresentar os
resultados impressionantes de uma solução “da casa”. As pessoas ficam entusiasmadas com a nova tecnologia.
O maior problema é que nem todos que ficam animados são capazes de compreender exatamente qual era o
problema inicial e todos os detalhes da solução — afinal, tratava-se de um problema não-trivial com uma solução
não-trivial.

Leva mais do que um tweet, bate-papo ou post no blog para explicar. Com ferramentas de comunicação como
mídias sociais, artigos de blogs e conferências-relâmpago, ocorre muito ruído na comunicação e a mensagem fica
“borrada” ao longo do caminho.

Passo 3: Obsessão

Toda força do hype leva desenvolvedores a lerem artigos e a participarem de conferências sobre a tecnologia.
Logo as equipes de todo o mundo começam a usar a usá-la. Devido à mensagem “borrada”, algumas delas
tomam decisões precipitadas de uso da tecnologia — mesmo que ela não resolva qualquer um de seus problemas
reais. No entanto, a equipe tem expectativa de que esta nova tecnologia vai ajudar.

Passo 4: Desapontamento

Conforme os sprints passam, a tecnologia não melhora a vida da equipe tanto quanto as pessoas esperavam,
mas traz muito trabalho extra. Há muita reescrita de código e aprendizagem extra para a equipe. As equipes
diminuem a velocidade, a administração fica chateada. Todos se sentem enganados.

Passo 5: Realização

Finalmente, a equipe faz uma retrospecção e percebe quais são os prós e contras da nova tecnologia e para que
finalidade ela seria mais relevante. Todos ficam mais sábios… Até o próximo hype aparecer.

Exemplos reais de hypes

3/6
É só pensarmos um pouquinho para lembrar de alguns exemplos reais do “Ciclo do Hype”, em ocasiões que
trouxeram muitos infortúnios para muitas equipes de desenvolvimento pelo mundo.

React.js

1. Problema real e solução. SPAs, como o próprio Facebook, têm tantos eventos de mudança de estado
que é difícil manter o controle do que está acontecendo e manter o estado do aplicativo consistente.
2. Buzz & Keywords. “Funcional”, “DOM Virtual”, “Componentes”.
3. Obsessão. “Facebook criou a estrutura front-end do futuro! Vamos escrever tudo em React de agora em
diante!”
4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
5. Realização. React é ótimo para SPAs avançados com muitas notificações em tempo real, mas não
necessariamente vale a pena para aplicativos mais simples.

“TDD está morto”

1. Problema real e solução. David Heinemeier Hansson (criador do framework Ruby on Rails) percebe que
é difícil fazer TDD com Rails — já que ele não tem uma boa arquitetura, que comporta OOP — e faz uma
escolha pragmática: não escrever mais testes antecipadamente; não trabalhar mais com TDD.
2. Buzz & Keywords. O hype começa com um post no blog de DHH e uma conferência. Termo-chave do
hype: “TDD está morto”.
3. Obsessão. “Vamos pular os testes! Nosso Guru diz isso. Nós não escrevemos eles de qualquer maneira.
Agora, pelo menos, não estamos fingindo. Finalmente somos honestos.”
4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
5. Realização. “TDD não está morto ou vivo. TDD está sujeito a tradeoffs, incluindo o risco de mudanças de
API, habilidades dos participantes e design existente.” — Kent Beck.

Microservices

1. Problema real e solução. Grandes aplicações monolítica têm escalonamento difícil. Há um ponto em que
é possível dividí-las em serviços. Será mais fácil de escalar em termos de req/sec e mais fácil de escalar
entre várias equipes.
2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Baixo Acoplamento”, “Monolítico”.
3. Obsessão. “Temos um ‘código de espaguete’ porque temos uma arquitetura monolítica! Precisamos
reescrever tudo para microservices!”
4. Desapontamento. Agora é mais lento desenvolver o aplicativo. E difícil de implantar e se passa muito
tempo rastreando bugs em vários sistemas.
5. Realização. Microservices exigem habilidadess “devops” na equipe. Antes de se chegar a graves questões
de escalonamento, são um um investimento excessivo. Microservices são extraídos, não escritos.

NoSQL

1. Problema real e solução. Bancos de Dados SQL têm problemas com cargas elevadas e dados não
estruturados. Equipes de todo o mundo começam a desenvolver uma nova geração de BDs.
2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “BigData”, “Alta Performance”.
3. Obsessão. “Nosso banco de dados é muito lento e não é grande o suficiente! Precisamos do NoSQL!”
4. Desapontamento. “Precisamos usar JOIN nas tabelas? Isso é problemático”. Operações SQL simples se
tornam cada vez mais desafiadoras. O desenvolvimento fica lento e os principais problemas não são
resolvidos.

4/6
 5. Realização. NoSQL são ferramentas para resolver problemas muito específicos — tanto volumes
extremamente elevados de dados, dados não estruturados ou cargas muito altas. SQL é realmente uma
ótima ferramenta, capaz de lidar com alta carga e volumes de dados enormes se for bem usada.

Elixir e Phoenix (ou sua dobradinha favorita de linguagem/framework)

1. Problema real e solução. Frameworks web como o Ruby On Rails não lidam bem com aplicativos de alto
desempenho, aplicativos distribuídos e websockets.
2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Alta Performance”, “Distribuído”, “Tolerante
a Falhas”.
3. Obsessão. “Nosso aplicativo é lento e nosso bate-papo não é escalável!”
4. Desapontamento. “Aprender programação funcional e abordagem distribuída não é tão fácil. Agora
estamos muito lentos.”
5. Realização. Elixir e Phoenix formam um excelente framework, mas demanda um esforço significativo para
aprender. Haverá retorno a um longo prazo se você precisa especificamente de um app de alto
desempenho.

E a lista continua…

O espaço lotado da Engenharia da Computação apresenta muitas áreas em que hypes são comuns. No mundo
do JavaScript, por exemplo, novos frameworks são criados todos os dias. Node.js, Programação Reativa,
Meteor.js, Front-end MVC, React.js. Na engenharia de software nascem novas arquiteturas: Domain Driven
Development, Hexagon, DCI…

Qual é o seu hype favorito? :-)

Boas práticas para evitar o DOM

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência.

Então, se não podemos confiar no que a internet diz e opiniões de outras pessoas, como tomar decisões
inteligentes em relação ao Desenvolvimento Orientado a Modinha? Eis algumas dicas e boas práticas.

Teste e pesquise antes de decidir

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência. A caráter de testes, invista 1 ou 2
dias para construir um protótipo de alguma funcionalidade na nova tecnologia antes de tomar uma decisão. Deixe
a equipe analisar os prós e contras. É possível usar algumas tecnologias competitivas e permitir que diferentes
partes da equipe construam protótipos com tecnologias diferentes.

Participar de hackathons é uma ótima maneira de construir a consciência de uma equipe através da análise de
tradeoffs de diferentes tecnologias. Tome 1 ou 2 dias para toda a equipe testar todas as tecnologias que estão em
ascensão. Isso permitirá que a equipe tome decisões inteligentes por si mesma, com base em sua própria
experiência.

Quando arriscar?

A princípio, quando o retorno do investimento é enorme. A maioria das tecnologias são criadas para resolver um
problema específico. Você tem esse problema? É um problema grande? Será que vai economizar muito tempo?
Será que o uso da tecnologia paga o custo da curva de entrada e reescrita? E se inicialmente retardarmos o
desenvolvimento pelo fator de dois? Ou quatro? Ainda vale a pena?

Algumas equipes são mais rápidas do que outras em entregar valor, chegando ao ponto de ficarem entediadas ao
5/6
realizarem entregas de maneira mais fácil. Essas equipes podem introduzir novas tecnologias com mais
freqüência — por outro lado, se a equipe tem problemas com entregas, este um forte indício para proceder com
cautela.

Trabalhe com as pessoas certas

Ter uma formação técnica sólida é essencial: pessoas que conhecem diferentes paradigmas, compreendem a
teoria da programação (por exemplo, algoritmos, concorrência etc) e têm boa cultura de engenharia tendem a ser
menos suscetíveis a hypes.

Experiência também conta muito. Hypes impressionam mais desenvolvedores jovens. Com o passar dos anos,
as pessoas que viram muitas tecnologias e estiveram em problemas muitas vezes tendem a ter uma visão mais
equilibrada da tecnologia e sabem escolher melhor.

Conclusão sobre Desenvolvimento Orientado a Modinha

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) não é novidade. Acontece de de um
hype realmente se consolidar no mercado e se tornar “a nova melhor prática”, mas a quantidade de hypes é tão
grande que, estatisticamente, poucos são os que alcançam o status de “paradigma” e se mantêm lá.

As dicas de testar e pesquisar, saber quando arriscar e trabalhar com as pessoas certas — com ênfase aos não
tão jovens e/ou aventureiros — realmente surtem resultados. Seguí-las pode determinar o sucesso ou fracasso
de seus negócios no mundo dos softwares.

O bom senso sempre foi um dos melhores aliados de todos nós. Parece que é hora de começar a dar mais
atenção a este velho amigo.

6/6