Arquiteto

Desenvolvimento Hype Driven

Postado em Atualizado em

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.

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

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

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

Meme dos desenvolvedores orientados a modinha

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

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

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.

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

Anúncios

Consultoria Arquitetural

Postado em

Sua corporação esta planejando projetar uma solução usando a plataforma Java? Qual estilo arquitetura utilizar? Quais frameworks adotar? Proprietários ou especificações ? Como fazer a integração com outras soluções legadas? Qual servidor de aplicação escolher? Como levantar requisitos não funcionais? Como resolvê-los? Estas são apenas algumas das muitas questões e problemas a ser resolvidas pelo profissional responsável por projetar uma solução Java. Nós da FOR-J oferecemos uma consultoria especial com o objetivo de suprir esse “know-how”, direcionando o seu projeto para as escolhas mais adequadas que realmente resolva a arquitetura de forma profissional e sem “fanboysmo” de produtos ou frameworks. Como funciona essa consultoria?

Levantamento dos Requisitos Não Funcionais

No primeiro contato, a empresa contratante passa por uma entrevista e um questionário com o objetivo de fazer o levantamento de requisitos básicos não funcionais do produto a ser elaborado. A empresa contratante deve obrigatoriamente chegar com os requisitos funcionais previamente esclarecidos e identificados.

Proposta Arquitetural

É elaborado pela FOR-J uma proposta de projeto com a definição de um estilo arquitetural, front-end, back-end, componentização, patterns, mecanismos de segurança, adoção de frameworks, integrações, entre varias outras coisas. Em um segundo contato é feito uma sessão no formato de palestra no qual é apresentada ao contratante uma proposta de arquitetura e as justificativas de como ela resolve o cenário da solução proposta, utilizando documentação arquitetural. Em caso de clientes remotos, essa consultoria pode ser feita através de emails, Skype ou áudio conferencia.

Escopo

Esta fora do escopo da consultoria providenciar a implementação da arquitetura proposta, download dos frameworks, configuração, integração dos mesmos, montagem da arquitetura e do ambiente de desenvolvimento, ficando isso de exclusiva responsabilidade da empresa contratante.

Pagamento

O pagamento deve ser obrigatoriamente feito até o primeiro encontro de levantamento de requisitos via deposito ou boleto bancário.  Estamos à disposição para quaisquer outras informações – fernandofranzini[arroba]gmail.com, (43)98407-4007 ou Whatsapp.

Padrões de Transações Java com Spring Framework

Postado em Atualizado em

Uma transação é uma seqüência de ações que são tratadas como uma única unidade de trabalho. Essas ações devem ser completas ou não terem nenhum efeito. O gerenciamento de transações é uma parte importante no desenvolvimento de soluções corporativas, sendo que é que deve garantir a integridade e consistência dos dados  nas operações. Existem 2 tipos de transações:  Locais e Globais.

Transações locais versus globais

As transações locais são específicas para um único recurso transacional, enquanto as transações globais podem abrangem vários recursos transacionais distribuídos.

O gerenciamento local de transações pode ser útil em um ambiente de computação centralizado, onde os componentes e recursos do aplicativo estão localizados em um único lugar, e o gerenciamento de transações envolve apenas um gerenciador de dados local executado em uma única máquina. As transações locais são as mais fáceis de implementar.

O gerenciamento de transações globais é necessário em um ambiente de computação distribuído, onde todos os recursos são distribuídos em vários sistemas. Nesse caso, o gerenciamento de transações precisa ser feito tanto a nível local como global. Uma transação distribuída é executada em vários sistemas, e sua execução requer coordenação entre o sistema global de gerenciamento de transações e todos os gerenciadores de dados locais de todos os sistemas envolvidos.

Spring Framework

Spring Framework fornece toda infraestrutura necessária para se gerenciar transações locais, globais e variações das mesmas. Ou seja, você não precisa perder seu tempo fazendo isso, já esta pronto e disponível através de vários projetos do ecossistema spring. É muito importante que um arquiteto de software Java conheça essas opções e tipos de transações, tendo base para a tomada de decisão diária aí em seus projetos. Segue abaixo um resumo básico das opções em formato de patterns do qual eu venho usando no meu dia dia:

1)Single Transaction RDBMS Pattern

Usado para gerenciar transação local com um único banco de dados, usando um único tipo de serviço e uma simples tecnologia.
Exemplo: solução java persiste dados no MySQL usando uma unica tecnologia JPA.
Spring fornece 3 produtos para resolver tal necessidade:

  1. Spring oferece gerenciador de transação automático para banco de dados relacional: TransactionManager.
  2. Spring oferece gerenciador de transação para as framework e tecnologias de persistência mais usada da plataforma Java: JDBC, IBatis, Hibernate e JPA.
  3. Spring oferece AOP baseado em anotação para gerenciando de demarcação de transação automática e recursiva: @Transaction.

2)Shared Transaction RDBMS Pattern

Usado para gerenciar transação local com um único recurso, usando múltiplos tipos de serviço e tecnologias.
Exemplo: solução java persiste dados no MySQL usando diferentes tecnologias: JDBC e JPA.
Spring fornece 1 produto para resolver tal necessidade:

  • Spring oferece um gerenciador de transação automático que une em um unica transação múltiplos tipos de tecnologias.

Exemplo: Configurar JpaTransactionManager + HibernateJpaDialect compartilhas as conexões e transações da solução usando tecnologia JPA com JDBC simultaneamente.

3)Single Transaction RDBMS + MOM Pattern

Usado para gerenciar transação local com um banco de dados e um MOM, no qual os dados da solução e a persistência das mensagens do MOM fiquem dentro do mesmo banco de dados. Para que isso funcione, o provedor de MOM precisa ter uma arquitetura flexível para fazer a configuração da estratégia de persistência de mensagens dentro do mesmo banco de dados da solução.
Exemplo: solução java persiste dados no MySQL e usa ActiveQQ persistindo as filas/tópicos dentro da mesa base.
Spring fornece 1 produto para resolver tal necessidade:

  • Spring oferece recurso para setar o mesmo gerenciador de transação da camada de persistência da solução sincronizada com persistência das mensagens enviadas para o MOM.

Exemplo: Configurar org.apache.activemq.store.jdbc.JDBCPersistenceAdapter + com.springsource.open.jms.JmsTransactionAwareDataSourceProxy, faz com que as transações da camada da solução fiquem integradas com as persistencia das filas/tópicos do Apache ActiveMQ.

4)Multiples Transations XA/2PC Pattern:

Usado para coordenar um única transação global de múltiplos recursos diferentes como SGBD’s e MOM’s, remotos e distribuídos. Todos independentes e de marcas diferentes. Para que isso funcione, todos os recursos devem aderir ao contrato do proto copo de transação de banco de dados XA/2PC e a especificação java JTA.
Exemplo: solução java persiste dados em um Oracle, em um SQLServer e usa ActiveMQ persistindo as filas/tópicos em banco de dados MySql.
Spring fornece 3 produtos para resolver tal necessidade:

  1. Spring oferece o contrato do gerenciador de transação automático baseado em JTA: JtaTransactionManager, mas não oferece implementação desse serviço.
  2. Alguns provedores de JTA já tem implementações que pode ser usadas no Spring. Exemplos: Atomikos e Bitronix.
  3. Spring oferece um componente integrador com container FULL JEE. O próprio container possui implementação própria de XA/2PC e JTA, fazendo com que o spring use esse implementação para gerenciar as transações de seus beans.

Prós:
– 100% de garantia de confiabilidade de transação ACID.
– Garante 100% rooback e commit, mesmo com falhas de infraestrutura: travamento, crash, falta de energia, falha de HD, queda de rede e etc
– Usa protocolo XA/2PC e chamadas remotas para garantir a transação.

Contras:
– Todos os recursos precisam implementar XA/2PC.
– Todos os recursos precisam estar configurados para rodar com XA/2PC
– Adquirir um provedor de JTA para XA/2PC open ou paga.
– Reduz tempo de resposta com I/O no protocolo 2PC, sendo que a transação é gerenciada de forma distribuída.
– Reduz escalabilidade com I/O no protocolo 2PC, sendo que a transação é gerenciada de forma distribuída

5)Multiples Transations NON XA/2PC Pattern (Best Efforts 1PC):

Usado para coordenar um única transação local múltiplos recursos diferentes como SGBD’s e MOM’s, remotos e distribuídos. Todos independentes e de marcas diferentes. Use essa opção quando por algum motivo, não seja possível utilizar protocolo XA/2PC.
Exemplo: solução java persiste dados em um Oracle, em um SQLServer e por alguma motivo não é possível configurar e usar XA/2PC.

  • Spring fornece uma implementação de um gerenciador de transação chamado de ChainedTransactionManager que implementa esse padrão.

Prós:
– Não usa protocolo XA/2PC.
– É um pattern que “emula” um suposto XA/2PC.
– Melhora no tempo de resposta com menos I/O, uma vez que não existe XA/2PC e nem transação distribuída.
– Melhora na escalabilidade com menos I/O, uma vez que não existe XA/2PC e nem transação distribuída.

Contras:
– Não garante 100% de confiabilidade de transação ACID. Nessa opção, os envolvidos deve ficar ciente desse fato.
– Inconsistências acontecem em casos de falhas de infraestrutura: travamento, crash, falta de energia, falha de HD, queda de rede e etc, dependendo da sequencia do determinado recurso, pode gerar inconsistências, causando comit em 1 recurso e rooback em outro.

Observação:
– As falhas podem ser minimizadas a quase 0%, em caso em que customização adequada na sequencia da configuração da orquestração das transações e investimento melhor de intra que minime falhar infraestruturais nos recursos envolvidos.
– Em certos casos, algumas empresas abrem mão do protocolo XA/2px e aderem a essa estratégia, afirmando que mesmo em casos raros de falhas, o custo da falha seria bem menor que bancar a implementação total do XA/2px.
– Em certos casos, algumas empresas abrem mão do protocolo XA/2px e aderem a essa estratégia, afirmando que é mais barato implementar algum mecanismos dentro da própria solução para identificar e contornar as possíveis inconsistências que bancar a implementação total do XA/2px.

“Este é o dia da vitória de Deus, o SENHOR; que seja para nós um dia de felicidade e alegria!” Salmos 118:24

Características de um Arquiteto de Software

Postado em Atualizado em

Quais são as características básicas que um bom arquiteto de software atualmente deve possuir? Resumidamente, temos 6 itens primordiais:

  • Agir como Líder
  • Ser um desenvolvedor
  • Ter o foco na solução
  • Pensar como um empreendedor
  • Balancear estratégica com pensamento tático
  • Se Comunicar  bem

Agindo como Líder

Os bons arquitetos de software entendem que seu papel como líder não é necessariamente dizer aos desenvolvedores o que fazer. Em vez disso, bons arquitetos agem como um guia, orientando uma equipe de desenvolvedores para a mesma visão técnica baseando-se em habilidades de liderança como contar histórias, influenciar, resolver conflitos, ensinar e construir a confiança com os indivíduos para transformar sua visão arquitetônica em realidade. Um bom líder e, portanto, um bom arquiteto, escutará atentamente as opiniões de cada colaborador, ajustando sua visão com o feedback da equipe. Isso leva bem para o próximo ponto

Ser um Desenvolvedor

Fazer boas escolhas arquiteturais consiste basicamente na responsabilidade de equilibrar um ideal arquitetônico conceitual com o estado real de um sistema de software. Por exemplo, não há sentido em optar por um banco de dados de documentos a um sistema se o domínio do problema é mais adequado para um banco de dados relacional, mesmo que seja chato. Um arquiteto pode se sentir tentado a impor tecnologias ou escolhas arquitetônicas sem considerar o fundamento do problema. A melhor maneira de um arquiteto mitigar isso é gastando tempo com desenvolvedores e tempo no código. Entender como o sistema foi construído, e suas restrições, dará ao arquiteto mais informações sobre as escolhas certas para o ambiente.

Ter um foco na solução

Os desenvolvedores experientes sabem que o código é apenas um aspecto do software real. Para tornar o código executável, um desenvolvedor experiente entende que existem outros atributos de qualidade importantes necessários para que o código funcione bem no ambiente de produção. Eles consideram aspectos como desempenho, segurança, escalabilidade, localidade, disponibilidade, confiabilidade, processos de implantação e testes automatizados. Os desenvolvedores simplesmente focam no código, mas o arquiteto no entanto, se concentrará na compreensão não apenas do código, mas também dos atributos de qualidade necessários para atender às muitas necessidades de diferentes partes interessadas. O bom arquiteto se concentra em encontrar soluções que possam satisfazer tantas dessas diferentes necessidades das partes interessadas, em vez de escolher uma ferramenta ou abordagem otimizada para as preferências ou o estilo de um único contribuinte

Pensando como um empreendedor

Todas as escolhas de tecnologia têm custos e benefícios, e um bom arquiteto vai considerar novas opções de tecnologia de ambas as perspectivas. Os empreendedores bem-sucedidos estão dispostos a assumir riscos, mas buscam maneiras de aprender rapidamente e fracassar rapidamente. Arquitetos podem abordar as escolhas de tecnologia de forma semelhante, buscando informações do mundo real sobre os custos de curto e longo prazo e os prováveis ​​benefícios que eles vão perceber. Um bom exemplo é quando o arquiteto evita comprometer-se com uma nova ferramenta baseada na leitura de um novo artigo, ou ter ouvido falar dele em uma conferência. Em vez disso, eles procuram entender como a ferramenta é relevante em seu ambiente, coletando mais informações. Eles não escolhem uma ferramenta baseada em quão bom a toa, mas que valor oferece, dado o que eles precisam para o seu sistema.

Balanceamento estratégico com pensamento tático

Muitas equipes constroem seu software de forma reativa com desenvolvedores individuais que escolhem ferramentas e tecnologias com as quais se sentem mais confortáveis ou com mais experiência.  O bom arquiteto mantém um olho fora da caixa, alem da zona de conforto para que novas tecnologias, ferramentas ou abordagens que possam ser úteis, mas não necessariamente imediatamente. A adoção da tecnologia requer uma abordagem que considere um horizonte de longo prazo. Os arquitetos procurarão um bom equilíbrio entre a agilidade, permitindo que a equipe se mova rapidamente e o alinhamento, mantendo a consistência suficiente, tanto no nível organizacional como em equipe.

Comunicando bem

Arquitetos sabem que a comunicação eficaz é uma habilidade fundamental para a construção de confiança e influenciar as pessoas fora da equipe. Eles sabem que diferentes grupos de pessoas usam vocabulário diferente e que usar os termos técnicos e descrições com os empresários torna a comunicação mais difícil. Em vez de falar sobre padrões, ferramentas e conceitos de programação, o arquiteto usa palavras com as quais seu público estará familiarizado. Comunicar opções técnicas aos empresários com palavras como risco, retorno, custos e benefícios servirá melhor a um arquiteto do que as palavras que eles usam com sua equipe de desenvolvimento. Um arquiteto também percebe que a comunicação dentro da equipe é tão importante quanto fora e usará diagramas e discussões em grupo para estabelecer e refinar a visão técnica e usar um registro escrito como um registro de decisão arquitetônico ou um wiki para fornecer uma trilha histórica para gerações futuras.

Vamos praticar? Vem comigo!

“Tu és grande e poderoso, glorioso, esplêndido e majestoso. Tudo o que existe no céu e na terra pertence a ti; tu és o Rei, o supremo governador de tudo.”1 Crônicas 29:11

Características de um Arquiteto de Software #7

Postado em Atualizado em

Comunicando bem

Arquitetos sabem que a comunicação eficaz é uma habilidade fundamental para a construção de confiança e influenciar as pessoas fora da equipe. Eles sabem que diferentes grupos de pessoas usam vocabulário diferente e que usar os termos técnicos e descrições com os empresários torna a comunicação mais difícil. Em vez de falar sobre padrões, ferramentas e conceitos de programação, o arquiteto usa palavras com as quais seu público estará familiarizado. Comunicar opções técnicas aos empresários com palavras como risco, retorno, custos e benefícios servirá melhor a um arquiteto do que as palavras que eles usam com sua equipe de desenvolvimento. Um arquiteto também percebe que a comunicação dentro da equipe é tão importante quanto fora e usará diagramas e discussões em grupo para estabelecer e refinar a visão técnica e usar um registro escrito como um registro de decisão arquitetônico ou um wiki para fornecer uma trilha histórica para gerações futuras.

“A fé é a certeza de que vamos receber as coisas que esperamos e a prova de que existem coisas que não podemos ver.” Hebreus 11:1

Características de um Arquiteto de Software #6

Postado em Atualizado em

Balanceamento estratégico com pensamento tático

Muitas equipes constroem seu software de forma reativa com desenvolvedores individuais que escolhem ferramentas e tecnologias com as quais se sentem mais confortáveis ou com mais experiência.  O bom arquiteto mantém um olho fora da caixa, alem da zona de conforto para que novas tecnologias, ferramentas ou abordagens que possam ser úteis, mas não necessariamente imediatamente. A adoção da tecnologia requer uma abordagem que considere um horizonte de longo prazo. Os arquitetos procurarão um bom equilíbrio entre a agilidade, permitindo que a equipe se mova rapidamente e o alinhamento, mantendo a consistência suficiente, tanto no nível organizacional como em equipe. Para qualquer dúvidas, veja o post inicial dessa série.

“De tudo o que foi dito, a conclusão é esta: tema a Deus e obedeça aos seus mandamentos porque foi para isso que fomos criados.” Eclesiastes 12:13

Arquiteto de software? O que estudar?

Postado em Atualizado em

Já recebi muita essa pergunta nos fóruns, emails e cursos, hoje gostaria de separar um tempo e falar sobre. Aperte o cintos e vamos nessa. Objetivo de um arquiteto de software é projetar soluções. O que podemos fazer para aprender isso?  Participar de projetos reais, “colar” no arquiteto responsável da corporação, aprendendo com ele os contextos ai do dia a dia e suas decisões de design. E se eu não tiver acesso a um? Sem problemas, temos livros fantásticos no mercado que registram e documentam experiencias e contextos de projeto reais de software. Mesmo se tivesse acesso a um, seria necessario complementar o seu conhecimento, estudando os mesmos livros, potencializando seu know-how e experiências. Sendo assim, segue abaixo um lista completa e devidamente sequencial de livros que vão te encaminhar para a profissão de arquiteto de software:

1. Patterns of Enterprise Application Architecture – Autor Martin Fowler

Esse livro é o mais fundamental de todos, tratando ai de padrões, contexto e soluções básicas pontuadas na camada de visão, negócio e persistência. Esse seria o livro que todos deveriam começar. Quantas camadas eu devo fazer? Sessão de usuário, você persiste no cliente? No server? Ou no bando de dados? Regra negocio, procedural ou orientado a objetos? Persistência de dados? SQL ou ORM? Estes são alguns de muitos dos exemplos de coisas básicas respondidas nesse livro. Existe uma versão em português.

2. Domain-Driven Design: Tackling Complexity in the Heart of Software , autor Eric Evans

Ele oferece aos leitores uma abordagem sistemática com relação a como desenvolver uma solução completa usando realmente OOP, apresentando um conjunto abrangente de práticas, ideais de design, técnicas baseadas em experiências e princípios fundamentais que facilitam o desenvolvimento de projetos de software que enfrentam domínios complexos. Reunindo práticas de design e implementação, este livro incorpora vários exemplos baseados em projetos que ilustram a aplicação do design dirigido por domínios no desenvolvimento de softwares na vida real. Existe uma versão em português.

3. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions – Autores Gregor Hohpe e Bobby Woolf.

Ao projetar uma solução, o arquiteto tem hoje uma outra dificuldade muito básica, integrar a nova solução com outras existentes, ou legadas e ou de parceiros de negócio. Dificilmente projetaremos um novo produto para funcionar sozinho de forma isolada. Nesse livro, teremos os cenários mais clássicos de integração, opções, prós e contras e muitas informações. Para ligar uma solução na outra, uso banco de dados? Arquivo? Web Services? Mensageria? Qual é melhor? Qual é mais cara?  Mais demorara? Nele você encontrara todas essas informações já mastigada e comprovada na prática. Outro motivo para ler esse livro é que ele se aprofunda especificamente no padrões de integração relacionado ao uso de servidores de mensageria. Não temos versão em português. Já fique sabendo que, sem inglês, como arquiteto, não da para chegar tão longe.

4. Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services, Autor Robert Daigneau

O uso de web services hoje tem sido um pilar fundamental para fazer integração de soluções, fazendo com os estilo SOAP e REST tenham seus próprios contextos, padrões, casos e soluções individualizadas. Nesse livro, você encontrará todos esses casos, padrões, e experiências relacionados com o uso efetivo de cada estilo de web services SOAP e REST. Não tem versão em português.

5. Building Microservices, Designing Fine-Grained Systems, Autor Sam Newman

O novo dilema de um arquiteto de software, na hora de projetar um solução é manter o uso de tipo de projeto monolítico ou usar o novo tipo de projeto conhecido com microservices. Nesse livro, você encontrara todas a informações necessárias para aprender oque é microservices, quando e se deve usar no seu projeto. Não tem versão em português.

5. Microservice Patterns, Autor Chris Richardson

Se o arquiteto decidir em usa o estilo de projeto microservices, muitos problemas surgiram na aplicação da filosofia. Como coordenar transação em projetos separados? Devo usa um banco de dados por serviço ou um para todos. Esse livro, que não esta pronto, trata contextos, padrões e experiencia relacionado o uso cotidiano de microservices. Até lá, consulte o site oficial do autor, que contem um boa documentação previa do assunto.

Conclusão

Bom pessoal, vou encerrar por aqui. Acredito que já temos livros ai para um “booooommmm” tempo de estudo, estou nessa jornada há um bom tempo, quase terminado todos eles. Te convido a entrar nessa jornada comigo. Vamos nessa? Precisando de ajuda, estou a disposição. Até a próxima!

“Por isso, não fiquem preocupados com o dia de amanhã, pois o dia de amanhã trará as suas próprias preocupações. Para cada dia bastam as suas próprias dificuldades.” Mateus 6:34