Arquiteto

Programação – Item 55

Postado em Updated on

Online_video_marketing_optimize_conversion_rates_tips_id35618561Otimize Criteriosamente

A historia das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode leva-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e pior de tudo inflexível de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitira que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de gerador de perfil e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório.

Para todas as informações, veja o post inicial.

“Tudo quanto, pois, quereis que os homens vos façam, assim fazei-o vós também a eles; porque esta é a Lei e os Profetas.” Mateus 7:12

Arquiteto de Software X Humildade

Postado em

4_WorkHardA humildade não é uma característica muito comum nos profissionais arquitetos de software. Depois de ter trabalhado com alguns arquitetos terríveis e, recentemente, com um muito agradável,  Johannes Brodwall compilou algumas de suas experiências e compartilhou neste post Humble Architects.  Leitura obrigatória para os arquitetos de plantão.

“Diz ao SENHOR: Meu refúgio e meu baluarte, Deus meu, em quem confio.” Salmos 91:2

O primeiro RWD agente nunca esquece

Postado em Updated on

20130814_163922

2013 é ano da Responsividade! Venho hoje compartilhar o nosso primeiro RWD - www.uniprimebr.com.br.

“porque todo o que é nascido de Deus vence o mundo; e esta é a vitória que vence o mundo: a nossa fé.” 1 João 5:4

Plano de Evolução – Nível de Qualidade Equipe Java

Postado em Updated on

100_qualityEm uma das empresas que eu atuo como consultor, eu acabei construindo uma classificação que define a qualidade da solução produzida por uma equipe de desenvolvimento Java. Esse plano foi utilizado para conscientizar qual era a real situação da qualidade do código produzido pela corporação e principalmente para traçar um plano de evolução para cada programador da equipem utilizado no conceito “de pronto” do Scrum. Hoje eu gostaria de publicar o plano com objetivo de receber sugestões sobre o assunto. Segue abaixo:

Nível 0

É classificada como “nível 0” uma equipe de desenvolvimento que codifica suas soluções Java sem nenhuma práticas, diretrizes ou patamar qualidade estabelecido, deixando o fato de livre decisão a cada desenvolvedor.

Nível 1

É classificada como “nível 1” uma equipe de desenvolvimento que consegue codificar suas soluções Java compatível com as seguintes práticas:

  1. Java Code Convention – o código da solução é escrito seguindo o padrão mundial de organização e nomeação dos elementos de programação.
  2. Java Doc – o design da solução é 100% documentada ao mesmo tempo em que é desenvolvida.

Nível 2

É classificada como “nível 2” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1”, acrescidas simultaneamente das novas seguintes práticas:

  1. Java Efetivo – o código da solução contempla o uso correto dos idiomas de programação Java descrito pelo Joshua Bloch em seu livro Java Effective.

Nível 3

É classificada como “nível 3” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2”, acrescidas simultaneamente das novas seguintes práticas:

  1. TDDo código da solução é escrito seguindo o a filosofia baseada em testes, criando na solução algum nível de cobertura de testes automatizados.

Nível 4

É classificada como “nível 4” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3”, acrescidas simultaneamente das novas seguintes práticas:

  1. Princípios OOP – o código da solução contempla o uso de princípios básicos e elementares da programação orientado a objetos.
  2. Padrões de Projeto – o código da solução contempla o uso correto de padrões de projeto.

Nível 5

É classificada como “nível 5” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3 + 4”, acrescidas simultaneamente das novas seguintes práticas:

  1. Refatoração – o código da solução contempla o uso correto dos princípios de refatoração de programação Java descrito pelo Martin Folwer.
  2. Programação pareada - o código da solução é aperfeiçoada com a refatoração utilizando a pratica de programação em par.

Nível 6

É classificada como “nível 6” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3 + 4 + 5”, acrescidas simultaneamente das novas seguintes práticas:

  1. Desenvolvedor Oracle Certified OCA e OCP – o código da solução contempla o uso adequado dos recursos básicos de programação e API JSE resultantes do conhecimento adquirido pela processo de certificação oficial Java.

Dicas

Scrum Masters ou gestores responsáveis pelas equipes podem utilizar estes níveis de qualidade para propor uma plano de evolução individual a cada membro desenvolvedor. Vale lembrar que os níveis são cronologicamente evoluídos. Desafie sua equipe e veja como eles podem construir uma solução Java com o mais alto padrão de qualidade. Só que já passou por isso é que pode realmente saber da diferença da entrega e manutenção de uma solução baseado no nível da equipe. E você? Em que nível você se encontra?

Disse Jesus: “Nem ele nem seus pais pecaram, mas isto aconteceu para que a obra de Deus se manifestasse na vida dele”. João 9:3

Intenções de Padrões de Projeto

Postado em

Hoje eu gostaria de abordar uma situação problemática que eu percebo acontecer repetitivamente com profissionais Java relacionado com o uso de padrões de projeto. Qualquer ser humano normal que já investiu tempo estudando diversos livros e materiais relacionados com catálogos de padrões de projeto, praticamente tem a tendência natural de esquecer a grande parte do conteúdo depois de um certo tempo. Partindo da idéia central de que um padrão simplesmente acontece em uma arquitetura, posso claramente afirmar que existe uma grande chance do profissional então não visualizar um determinado cenário favorável para a aplicação de um padrão. Por mais escancarado que uma situação arquitetural aponte para um padrão, se o profissional não estiver com as características daquele padrão injetado na memória, ele fatalmente não ira se beneficiar dos objetivos motivadores da existência de um padrão, enviando possivelmente sua arquitetura para o penoso caminho da inflexibilidade.

Mas como podemos então evitar tudo isso? A resposta é simples:

O profissional precisa apenas se preocupar em memorizar somente a “intenção central” de um padrão para que quando o cenário arquitetural aparecer, ele possa facilmente identificar o caso de aplicabilidade.

Com o objetivo de ajudar os desenvolvedores eu gostaria de publicar o meu resumo de intenções do catalogo de padrões GOF que utilizei para fazer esse mapeamento mental. Segue abaixo:

Padrões de Criação

As motivações dos padrões de criação esta centralizado em como os objetos são criados. Ou seja, eles são usados para capturar intenções focalizadas na criação de objetos.

Factory Method – sua intenção é definir um ponto de criação para um tipo de objeto no qual não se tem conhecimento do tipo concreto a ser usado.

Abstract Factory – sua intenção é definir um ponto de criação para uma família de objetos relacionados ou dependentes no qual não se tem conhecimento dos tipos concretos de todos estes objetos a serem usados. O Abstract Factory é basicamente uma “extensão em massa” do padrão Factory Method.

Prototype – sua intenção é definir um ponto de criação de objetos que precisam ser instanciados usando como base a cópia outro objeto molde denominado de “protótipo”. Todos os objetos criados passam a existir contendo valores copiados desse suposto objeto protótipo.

Singleton – sua intenção é definir um ponto de criação de objetos que necessitem ser instanciado somente uma vez durante todo o ciclo de execução da solução e oferecer um ponto único de acesso para essa referencia.

Builder – sua intenção é definir um ponto de criação de um objeto complexo de sua representação de forma com que esse ponto de construção possa ser parametrizado para construir diferentes variações desse mesmo objeto.

Padrões Estruturais

As motivações dos padrões estruturais esta centralizado na organização e composição de classes e seus objetos. Ou seja, eles são usados para capturar intenções focalizadas na composição estrutural dos objetos.

Adapter – sua intenção é converter a interface de uma classe para outra interface requerida, definindo um ponto intermediário de ligação com o objetivo de promover comunicação entre duas interfaces incompatíveis.

Bridge – sua intenção é separar a abstração de uma ação de suas diferentes implementações, de forma que ambas possam ser flexivelmente intercambiais.

Composite – sua intenção é fazer com que um objeto possa ser genericamente operado de forma que represente uma estrutura dinâmica hierárquica de composições de objetos.

Decorator – sua intenção é definir um meio alternativo a herança de adicionar responsabilidades ao um objeto de forma flexível e dinâmica em tempo de execução.

Facade – sua intenção é definir uma interface fácil, simples e unificada para um ou mais conjuntos de operações relacionados a subsistemas internos.

Flyweight – sua intenção é definir um ponto de compartilhamento eficiente que suporte um grande numero de manipulações de objetos de granulação fina reutilizáveis.

Proxy – sua intenção é definir um objeto-substituto para um objeto-real, de forma com que o objeto-substituto possa transparentemente intermediar as interações para esse objeto-real.

Padrões Comportamentais

As motivações dos padrões comportamentais esta centralizado nas responsabilidades e relacionamentos dos objetos. Ou seja, eles são usados para capturar intenções focalizadas no que um objeto pode fazer e como ele se relaciona com os outros.

Chain of Responsability – sua intenção é desacoplar o objeto-enviador de um pedido dos supostos objetos-receptores, possibilitando com que múltiplos objetos-receptores possam ser dinamicamente enfileirados para manipular o pedido transparentemente.

Command – sua intenção é fazer com uma requisição de um comando possa ser encapsulado como um objeto uniforme, permitindo com que objetos-clientes possam ser parametrizados flexivelmente com diferentes objetos-comandos intercambiais.

Interpreter – sua intenção é definir objetos que possam representar e interpretar intercambialmente uma determinada gramática textual qualquer.

Iterator – sua intenção é definir uma forma com que objetos agregados dentro de um objeto possam ser seqüencialmente acessados por outros objetos sem expor os detalhes internos de seus relacionamentos e implementações.

Mediator - sua intenção é definir um objeto utilizado para encapsular o relacionamento entre dois outros objetos, fazendo com que o determinado relacionamento destes dois objetos alvo possam ser implementado de forma indireta, flexível e intercambial.

Memento - sua intenção é definir uma forma de capturar e armazenar o estado de um objeto de forma com que essa objeto possa ser restaurada para o estado original anterior.

Observer - sua intenção é definir uma forma que possibilite um objeto agregador notificar e atualizar automaticamente outros objetos agregados dependentes quando ocorrer uma alteração no estado no objeto agregador.

State - sua intenção é definir uma forma que possibilite um objeto variar intercambialmente seus comportamentos quando mudanças internas no seu estado acontecerem.

Strategy - sua intenção é definir um objeto que possua determinados comportamentos que sofram variações intercambiais dependendo de outros objetos clientes que os manipulam.

Template Method - sua intenção é definir objetos que implemente um algoritmo previamente formatado dentro de um comportamento, fazendo com que outros objetos possam intercambialmente substituir partes das funcionalidades desse algoritmo.

Visitor - sua intenção é definir uma forma que possibilite que diversas operações possam ser dinamicamente aplicadas para um objeto, sem a necessidade alterar sua estrutura de definição.

Dicas

Se porventura você é um desenvolvedor que deseje não perder nem uma oportunidade de aplicar um padrão GOF, deve obrigatoriamente entender e decorar cada um dessas motivações. A dica principal é que o candidato primeiro precisa entender a motivação do padrão para depois memorizar sua intenção. Caso existe algum padrão GOF que você não tenha compreendido, separe um tempo de qualidade para estudá-lo para que posteriormente você tenha condições de memorizar sua motivação. Vale lembrar também que a dica serve para ser aplicada para outros catálogos.

“Olhem para o Senhor e para a sua força; busquem sempre a sua face.” 1 Crônicas 16:11

Arquitetura da Soluções Web Mobile MVC

Postado em Updated on

images“Pode-se criar uma interface rica para aplicações de forma nativa ou utilizando HTML5 e JavaScript. Aplicações nativas podem oferecer uma experiência mais rica para os usuários, mas podem levar mais tempo e ser mais caras de desenvolver para vários sistemas operacionais. As tecnologias HTML5 e JavaScript abrirão a porta para as interfaces independentes de dispositivo. Isso significa que as interfaces com o usuário podem ser criadas utilizando bibliotecas de componentes JavaScript que renderizam componentes visuais utilizando elementos do HTML5. O HTML5 traz novas funcionalidades que suportam a mobilidade e o desenvolvimento de interfaces ricas.

Este artigo apresenta frameworks e estruturas usadas para implementar o lado cliente das aplicações móveis com base em JavaScript e HTML5. A interface com o usuário e os elementos de navegação são todos componentes renderizados no navegador, enquanto os servidores de aplicações têm somente o papel de fornecer acesso aos dados JSON para a interface com o usuário. Como a intenção aqui é fornecer uma arquitetura de referência, o exemplo implementa apenas algumas funcionalidades básicas.Muitas abordagens para desenvolver aplicações para navegadores desktop podem ser utilizadas nas aplicações baseadas em navegadores móveis. No entanto, as aplicações móveis apresentam desafios não existentes nos navegadores para desktop.”

Veja o artigo completo no site da InfoQ.

“Filho meu, não te esqueças dos meus ensinos, e o teu coração guarde os meus mandamentos; porque eles aumentarão os teus dias e te acrescentarão anos de vida e paz.” Provérbios 3:1-2

Java Spring Architect

Postado em

logo-spring-103x60Mesmo depois dos avançados da especificação do JEE 6, vemos que ela ainda esta muito longe de se igualar as opções oferecidas pela plataforma Spring. Vale a pena lembrar que da mesma forma que as especificações vão melhorando ao longo do tempo, o Spring também vai evoluindo em uma velocidade muito mais rápida, uma vez que não depende de nenhum tipo de votação comunitária.

Eu mesmo ao longo dos meus 14 anos de Java, sempre tive a cautela de preferir produtos JCP ao invés de proprietários, visando o grande ideal da portabilidade e a independência de vendor, mas hoje eu venho publicamente concluir que tenho percebido que ao longo do tempo tenho adotado os produtos Spring mais e mais. Motivo? O mesmo pelo qual o Spring foi criado: ser uma opção muito mais rápida, barata e leve de um lightweight container que ofereça serviços plugáveis de infraestrutura para soluções corporativas com a mesma qualidade.

Hoje a minha dica é sobre os principais livros de Spring atualizados para os interessados em se aprofundar nessa poderosa plataforma:

51nY36Dqo5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Spring in Action  é o livro mais básico que te ensina os pilares do uso de serviços no Spring. Nele você também aprendera os serviços e recursos mais básicos que ele proporciona.

415x7PWAe5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Just Spring Integration  é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para integração de soluções definidos pelo catalogo de patterns de integração conhecidos pelo EAI.

51RXnaly93L

Spring Data é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para persistência de dados relacionados com banco de dados relacionais e NoSQL.

Existem outros livros mais específicos de outros serviços que você também pode estar estudando como, por exemplo, Spring Bath in Action e Pro Spring Security

Uma vez que você domine todos estes serviços, você praticamente se tornara um “Arquiteto Java Spring”, dominando contextos de soluções mais modernos da atualidade e apto para projetar soluções corporativas de pequeno, médio e grande porte.

“Não retarda o Senhor a sua promessa, como alguns a julgam demorada; pelo contrário, ele é longânimo para convosco, não querendo que nenhum pereça, senão que todos cheguem ao arrependimento.” 2 Pedro 3:9

Oracle Certified Master Java EE Enterprise Architect – Dicas de Estudos

Postado em Updated on

1225170121VW4zYKEm Abril de 2013 eu fui aprovado na certificação Oracle Certified Master, Java EE Enterprise Architect, e hoje eu gostaria de compartilhar as minhas dicas para os novos candidatos. Confesso que essa foi a prova mais difícil, demorada e cansativa que eu já fiz, mas que também foi a que mais me fez aprender e crescer como profissional. Esta certificação é composta por 5 fases:

Fase 1: Curso Obrigatório

Nesta fase o candidato é obrigado a fazer pelo menos um curso oficial da Oracle de Java em qualquer empresa parceira. Esse curso pode ser feito em qualquer momento da certificação – antes, durante ou depois. A minha dica é: se o candidato já tem experiência em Java e arquitetura, deixe para fazer o curso no fim. Se caso não, use os cursos para adquirir conhecimento para a prova fazendo os antes. Existe uma grade completa de cursos de Java para o candidato adquirir know-how básico para essa certificação.

Fase 2: Java Enterprise Architect Certified Master Exam

Nesta fase o candidato tem que passar em um exame de 64 questões com a pontuação mínima de 57%. O conteúdo do exame cobre conhecimentos em princípios de design, arquiteturas de software, integrações entre soluções, mensageria, especificações e tecnologias Java, padrões de projetos e segurança.

Livros de estudos:

  • Livro Sun Certified Enterprise Architect for Java EE Study Guide Mark Cade, Humphrey Sheil
  • Livro Sun Certified Enterprise Architect for Java EE Study Guide (Exam 310-051) Paul Allen, Joseph Bambara
  • Oracle Certified Master, Java EE Enterprise Architect Practice Guide by Amritendu De

Mesmo os dois primeiros livros tenham o mesmo objetivo, cada um pontua e reforça aspectos diferentes, sendo necessário o estudo de ambos. Outro detalhe importante é que essa certificação cobre muitas outras coisas que estes livros não abordam. Sendo assim, é importante que o candidato faça primeiramente a leitura deles para poder diagnosticar assim o que sera necessário estudar a parte.

Resumo:

Durante os estudos e simulados eu acabei fazendo um resumo de todo o que se precisa saber e memorizar para se passar nessa parte da prova. Sendo assim, os candiados podem usar esse resumo para memorização e para saber quais são os tópicos necessários de estudo a parte caso não conhecimento sobre o assunto. [Donwload do Resumo].

Simulado:

Sobre simulados, eu perdi muito tempo fazendo muitos simulados pela web mas quase todos estão defasados. O único que foi suficiente e que valeu a pena mesmo, foi esse da whizlabs. Use o cupom de desconto ”whizoffer10” para ter 10% de desconto.

Fase 3: Java Enterprise Architect Certified Master Assignment

Nesta fase o candidato é responsável por desenvolver um projeto completo baseado em um documento de requisitos. Neste documento vem descrito o cenário de negócio da corporação, os requisitos do produto a ser desenvolvido e que você esta sendo contratado para ser arquiteto responsável pela elaboração e a criação dessa nova solução. Como em qualquer projeto, o arquiteto precisa analisar o cenário da corporação, bem como seus requisitos e fazer a tomada de decisões de design.

Livros Sobre Decisões de Design

A minha primeira dica é relacionada aos livros que você pode ler para aprender quais são as decisões de design mais comuns em soluções corporativas e quais são os prós e contras de cada uma delas. Segue os livros:

  1. POJO in Action by Chris Richardson – Esse livro apresenta versões de produtos Java antigas, mas as decisões de projeto ainda continuam a mesma. Eu indico como leitura inicial para que os candidatos aprendam o core básico das decisões, desprezando os produtos tecnológicos antigos utilizados pelo autor.
  2. Patterns of Enterprise Application Architecture by Martin Fowler – Esse livro é o mais indicado para essa fase dois da certificação aonde Martin Fowler descreve detalhadamente cada decisão de design dentro de uma solução corporativa acompanhando com os seus prós e contras. Ele pode até ser utilizado como “regra de bolo” para suas decisões de projeto durante a certificação.
  3. Domain Drive Design by Erick Vans – Esse livro aborda o principal design da atualidade que é o fato de se construir e documentar soluções orientadas a objetos sem gerar amarrações com tecnologias ou plataformas. Nele Erick Vans te ensina a visualizar e construir uma solução puramente orientada e objetos, independentemente de plataforma ou tecnologia.
  4. Design Patterns: Elements of Reusable Object Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides – Esse livro contém o catalogo de padrões mais básicos do paradigma da orientação a objetos que sem dúvidas nenhuma você precisa para resolver as estruturas das classes/componentes na solução.
  5. Real World Patterns Rethinking Practices by Adan Bien – Esse livro trás o estudo feito pelo Adan Bien que readapta e aposenta os antigos padrões da versão J2EE para as versões mais atuais do JEE 6+. Nele você aprendera como e quais padrões continuar usando e aqueles que não precisam mais ser utilizados.

Cada livro te oferece conhecimento voltado para uma parte da solução da certificação e o ideal seria que o candidato investisse na leitura destes livros antes de encarar a prova, uma vez que o tempo de entrega da segunda fase é de apenas seis meses.  

Estudo de Casos Fictícios

A segunda dica é sobre livros e artigos que apresentam exemplos de soluções desenvolvidas para a segunda fase da prova, servindo também como estudo de caso para que os novos candidatos tenham uma noção básica e inicial de como a coisa é feita. Segue as dicas:

  1. Enterprise Enterprise JavaBean 3.0 by Bill Burke (chapter 21) – Nesse livro Bil Burke apresenta passos de como desenvolver uma solução JEE utilizando EJB3 recheado de detalhes e explicações que podem ser utilizados para aprender inúmeros detalhes semelhantes da segunda fase da prova.
  2. Sun Certified Enterprise Architect for Java EE Study Guide by Mark Cade and Humphrey Sheil – Nesse livro os autores cobrem todas as partes da certificação, apresentando nos capítulos finais uma solução exemplo com detalhes interessantes.
  3. Sun Certified Enterprise Architect for Java EE Study Guide (Exam 310-051) by Paul Allen and Joseph Bambara – Nesse livro os autores também cobrem todas as partes da certificação, apresentando nos capítulos finais uma solução exemplo com detalhes interessantes.
  4. Oracle Certified Master, Java EE Enterprise Architect Practice Guide by Amritendu De – Esse livro é o mais recente sobre essa certificação que foi lançado após eu ser aprovado no qual eu ainda não tive a oportunidade de ler, mas que como os outros, também possuem uma solução exemplo nos capítulos finais.
  5. Epractizelab Simulator – Simulador pago da empresa Epractizelab que traz um exemplo de um projeto e a solução que também pode ser utilizado como estudo. Como eu não comprei, não posso opinar se é bom ou não. Para todas as dúvidas acesse http://www.epractizelabs.com/certification/sun/scea-5-part23-exam.html
  6. Revista Mundo Java Edição 35 Artigo SCEA5 Certificação de Arquiteto – Artigo completo sobre um projeto e a solução fictício escrito por Marcio Varchavsky.

Criando a Solução:

Segue algumas dicas para você começar a sua solução. Preste atenção na extração de requisitos:

  • Descrição da história da empresa.
  • Descrição dos sistemas legados.
  • Descrição de casos de uso.
  • Descrição da infraestrutura necessária.

Documentação de requisitos da certificação é obscura, incompleto e pode até vir propositalmente com alguns erros. Você poderá precisar fazer algumas correções e ou suposições em cima do contexto para complementar o projeto, tornando o implementável. É justamente por isso que faz parte da entrega da solução um documento de decisões de projeto no qual você deverá descrever suas suposições e como elas afetaram a sua solução final. Preste atenção na extração dos requisitos não-funcionais e destaque as descrições associadas a cada exigência. Exemplos:

  • Número de demanda para uso da solução
  • Expectativa de aumento de escalabilidade.
  • Tempo de resposta de usuário final.
  • Tempo de resposta de comunicação nas integrações com outros sistemas.

Faça Suposições

Na questão das suposições, você tem dois caminhos a seguir:

  1. Suponha que alguma coisa já exista na solução proposta e assim não faça nada relacionado com aquilo e documente essa suposição.
  2. Suponha que alguma coisa não exista na solução proposta e assim necessitando ser adicionando e considerado na arquitetura como parte da sua solução proposta. Tenha cuidado com esse caminho, uma vez que você estará aumentando seu projeto e consequentemente abrindo mais espaços para inconsistências e erros.

A minha dica sobre isso é: não assuma ou invente coisas que adicione complexidade ao seu projeto. Faça suposições de coisas que estão faltando com o objetivo de complementar as possíveis faltas de informações. Resista a tentação de fazer coisas mirabolantes.

Diagramas

Segue algumas dicas para a construção dos diagramas:

  • Os diagramas precisam estar desacoplados de qualquer detalhe de tecnologia ou framework especifico, independente de fornecedor.
  • A essência dos diagramas é apresentar a estrutura que resolve os problemas do contexto proposto e não a infraestrutura de tecnologia e frameworks adotada.
  • Mantenha os diagramas em alto nível. Ou seja, não se preocupe em mostrar coisas de baixo nível como algoritmos, detalhes de API, etc.
  • Comece com o diagrama de implantação, depois classes, depois sequencia e por fim o de componentes.
  • Não se esqueça de ir documentando todas as suposições e as decisões de design que você for fazendo ao longo da construção de diagramas.

Fase 4: Java Enterprise Architect Certified Master Essay Exam

Na última fase da prova, o candidato precisara responder a 8 perguntas relacionadas ao projeto desenvolvido. A minha dica aqui é a seguinte: responda às questões de arquiteturas durante a fase de projeto, ao mesmo tempo em que você produz o documento de decisões. Segue abaixo uma listagem de possíveis perguntas que poderá encontrar na prova:

  • How does your design handle availability? Why did you choose it? pros and cons of your approach?
  • How does your design handle reliability? Why did you choose it? pros and cons of your approach?
  • How does your design handle scalability? Why did you choose it? pros and cons of your approach?
  • How does your design handle performance? Why did you choose it?  pros and cons of your approach?
  • How does your design handle security? Why did you choose it? pros and cons of your approach?
  • How does your design handle extensibility? Why did you choose it? pros and cons of your approach?
  • How does your design handle maintainability? Why did you choose it? pros and cons of your approach?
  • Set of design patterns on which layer and why?
  • How does your design support session/state handling?
  • How does your design handle persistence?
  • How does your client tier talk to business tier?
  • How does your design handle Qos 5 Sec in peak time?
  • How does your design handle transactions?
  • How does your design handle authentication and authorization?
  • What technology u have used in presentation and business tier why?
  • How many SB’s you used and purpose of them?
  • Why have you chosen framework If any If not why not ?

Não deixe para pensar e elaborar essas respostas na hora da prova por que você não terá tempo hábil para isso. Respondendo elas antecipadamente, te ajudara a chegar a ultima prova bem preparado e até mostrar erros que você cometeu durante a elaboração do projeto, levando você refatorar alguma coisa.

Fase 5: Course Submission Form

Depois de fazer o curso obrigatório e ser aprovado nas três provas que compõem a certificação, nesta fase o candidato entrará na ferramenta da VUE para enviar a confirmação do curso obrigatório feito para o sistema da Oracle com o objetivo de notificar que o candidato finalizou a grade da certificação. Com isso, a Oracle enviara posteriormente o kit de credencial de profissional arquiteto Java. Para todas as informações, acesse a grade oficial da prova.

Eu me coloco a disposição para qualquer eventual dúvida relacionado a arquitetura ou sobre a certificação. Agora é renovar a metas e continuar avançando. Até a próxima pessoal!

“O caminho para a vida é de quem guarda o ensino, mas o que abandona a repreensão anda errado.” Provérbios 10:17

Plano de Evolução – Nível de Qualidade

Postado em Updated on

qualidadeEm uma das empresas que eu atuo como consultor, eu acabei construindo uma classificação que define a qualidade da solução produzida por uma equipe de desenvolvimento Java. Esse plano foi utilizado para conscientizar qual era a real situação da qualidade do código produzido pela corporação e principalmente para traçar um plano de evolução para cada programador da equipe. Hoje eu gostaria de publicar o plano com objetivo de receber sugestões sobre o assunto. Segue abaixo:

Nível 1

É classificada como “nível 1” uma equipe de desenvolvimento que consegue codificar suas soluções Java compatível com as seguintes práticas:

  1. Java Code Convention – o código da solução é escrito seguindo o padrão mundial de organização e nomeação dos elementos de programação.
  2. Java Doc – o design da solução é 100% documentada ao mesmo tempo em que é desenvolvida.

Nível 2

É classificada como “nível 2” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1”, acrescidas simultaneamente das novas seguintes práticas:

  1. Princípios OOP – o código da solução contempla o uso de princípios básicos e elementares da programação orientado a objetos.
  2. Padrões de Projeto – o código da solução contempla o uso correto de padrões de projeto.

Nível 3

É classificada como “nível 3” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 e 2”, acrescidas simultaneamente das novas seguintes práticas:

  1. Java Efetivo – o código da solução contempla o uso correto dos idiomas de programação Java descrito pelo Joshua Bloch em seu livro Java Effective.

Nível 4

É classificada como “nível 4” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1, 2 e 3”, acrescidas simultaneamente das novas seguintes práticas:

  1. Certificação de Programador Java Oficial – o código da solução contempla o uso adequado dos recursos básicos de programação e API JSE resultantes do conhecimento adquirido pela certificação oficial de programador Java.

Nível O 

É classificada como “nível O” uma equipe de desenvolvimento que codifica suas soluções Java sem nenhuma das praticas e diretrizes citadas nos outros níveis.

Dicas

Gestores responsáveis pelas equipes podem utilizar estes níveis de qualidade para propor uma plano de evolução individual a cada membro programador. Vale lembrar que o níveis podem ser cronologicamente ou randomicamente evoluídos, tudo dependendo do perfil individual de cada um, experiência com a linguagem/plataforma, disposição para aprender e força de vontade. O post fica aberto para comentários e sugestões sobre o assunto.

Disse Jesus: “Nem ele nem seus pais pecaram, mas isto aconteceu para que a obra de Deus se manifestasse na vida dele”. João 9:3