Obra prima de Hieronymus Bosch, pintor holandês contemporâneo de Leonardo da Vinci

Se a engenharia de software tivesse um inferno, poderíamos nos arriscar, como Dante Aligheri, a descrever os sete pecados capitais do desenvolvimento de software que os porquinhos de software cometem em base diária. Mary Poppendieck, uma das autoras do Lean Software Development, descreva 7 formas de desperdício no desenvolvimento de software. Apresento e contextualizo estes pecados capitais abaixo no dia a dia do trabalho de software.

1. Funcionalidades extras. Pesquisas de institutos como o Standish Group (XP Conference, 2002) mostram que metade das funcionalidades de um software são raramente ou nunca usadas. Ainda assim, é muito comum que desenvolvedores “criativos” introduzam funcionalidades não desejadas em seus software que não trazem valor agregado algum para os seus clientes. A redução do desperdício tem forte relação com escrever menos linhas de código.

2. Transferência de responsabilidades, conhecimentos, ações e feedbacks. O uso de papéis muito especializados é um sintoma deste problema. “Arquitetos” e “projetistas” que não sabem codificar, “desenvolvedores” que não sabem testar ou implantar software e “gerentes de projeto” que se orgulham de não entrar em temas técnicos são exemplos de handovers (repasses) e fontes comuns de desperdício.

3. Defeitos. Se orgulhar de ter um time de testes que encontra muitos defeitos é no mínimo contra-produtivo. Devemos nos lembrar que defeitos são desperdícios, ou dinheiro jogado fora. As ações de projetos devem impedir que defeitos sejam introduzidos em primeiro lugar, e não focar em pegar defeitos ao final.  Um exemplo simples é no ciclo tradicional de especificação, codificação e testes. Ao invés, o teste deve validar e corrigir a especificação antes que a primeira linha de código seja escrita, visto que a maior parte dos defeitos nasce ainda na especificação do software. Da mesma forma, é papel do desenvolvedor usar técnicas diversas (refatoração, teste de unidade e integração contínua) para reduzir a quantidade de defeitos introduzidas no software.

4. Débito Técnico. Fazer código de má qualidade tende a gerar débito técnico no código, módulo e arquitetura de um produto. O débito técnico gera um efeito muito ruim a médio e longo prazo e gera efeitos colaterais no produto em pontos não imaginados. Livros como “Clean Code”, do Robert Martin, exploraram a criação de código de qualidade

5. Trabalho em progresso. Manter uma longa lista de tarefas com o status em  ”execução” esconde problemas e eventualmente gera desperdício. Cada pessoa de um time deve manter o mínimo número de tarefas abertas. Cada tarefa aberta deve ser rapidamente terminada para reduzir o seu tempo de ciclo, evitar retrabalhos e trabalho multitarefa. Um exemplo vem da metodologia japonesa chamada Kanban, que introduz o conceito chamado (WIP). O WIP (Work In Progress) tem um valor limite pequeno (tipicamente 3) e impede que uma pessoa tenha mais de 3 tarefas em execução. Um outro exemplo de combate a este desperdício é a prática de entregar software com frequência para os usuários chave, que limita o tamanho do backlog de tarefas em aberto para todo o time de desenvolvimento.

6. Trabalho multitarefa. Há algum tempo este mito assola os times de software, atolados no trabalho de novas demandas e na resolução de defeitos e adaptações de diversos softwares em paralelo. Estudos diversos mostram que o fator multitarefa reduz a produtividade, gera desmotivação e trabalho de pior qualidade, o que introduz mais defeitos e gera mais trabalho em progresso.

7. Esperas e atrasos. Provocar esperas e atrasos gera um efeito nocivo na produtividade do time e é também uma forma de desperdício. Por exemplo, enviar um email para uma equipe de desenvolvimento validar um documento de casos de uso gera espera, atraso e descontinuidade do trabalho. Apresentar este documento ao vivo melhora o entendimento para todos e também reduz ciclo de validação do documento gerado. Allistar Cockburn descreve a prática chamada de “Radiadores de Informação” em seu método ágil chamado Crystal Clear, que consiste em manter pessoas próximas e privilegiar a comunicação ao vivo com o uso de quadros brancos. Outros métodos ágeis como o Scrum ou o XP também advogam práticas similares.

Eliminar desperdícios é chave para gera software mais eficaz e em menos tempo para clientes. Um bom livro sobre este tema é o livro: Implementing Lean Software Development: From Concept to Cash, de Mary e Tom Poppendieck.

Quando olhamos códigos Java, C# ou PHP nas empresas, entretanto, parece que voltamos à idade média. Vemos funções com 500 linhas de código, o uso indiscriminado de colar e copiar ou o uso abusivo de switch-cases . Imundíceis de toda sorte, documentadas na literatura especializada como  bad smells. Livros clássicos como Code Complete – Steve McConnell; Refactoring – Martin Fowler ou Clean Code – Robert Martin apresentam e documentam práticas para banhar e deixar o seu código limpinho e sexy.

Apesar disso, ainda parece difícil adotar uma boa prática como a refatoração de código e internalizá-la no seu dia a dia de programação.

Como criar o hábito da refatoração no seu código?

A prática de refatoração já é documentada há muito tempo na literatura, mas muitos desenvolvedores ainda não aderiram ao hábito por motivos diversos. Se você é um deles, recomendo quatro práticas simples para formar o hábito da refatoração diária.

1. Comece muito leve.
   Que tal se você se dedicar a refatorar o seu código 1 minuto por dia? Você consegue fazer isso amanhã? Não parece muito, certo?Em verdade o ponto mais importante para o desenvolvimento de um hábito é a repetição de uma prática. Em um minuto, talvez você somente consiga aplicar o padrão Extract Method com o Eclipse ou o Visual Studio, mas isso já é ótimo. É um pequeno banho. Repetir o processo todo o dia irá gerar formar um senso de repetição, que é para mais importante para formar um hábito.
2. Vigie as suas conversas internas.
   A nossa mente, inconscientemente, pode criar conversas internas sobre o quão difícil a refatoração pode ser. Vigie seus pensamentos e os interrompa o mais rápido possível. Se você deixar as conversas internas ganharem corpo, elas irão racionalizar o mal hábito de não refatorar o seu código em base diária.
3. Em caso de falha, implemente um plano de ataque
   Talvez você se esqueça de refatorar o seu código em algum dia. Neste caso, você deve ter um plano de ataque para refatorá-lo no dia seguinte custe o que custar. Se você ficar três dias sem dar banho no seu código, o hábito pode ir embora e o seu código voltará à idade das trevas.
4. Se orgulhe do seu código limpinho
   Um código refatorado tem métricas de qualidade superiores, tem melhor legibilidade e irá gerar menos defeitos que um código porquinho. Se orgulhe disso e saboreie o momento da refatoração. Afinal, o código é a sua criação e você não quer que o seu filhinho seja porquinho, quer?

Para os mais curiosos, recomendo a leitura do livro The Clean Coder, do Robert Martin, que apresenta e discute a atitude do desenvolvedor moderno, que considera o banho diário uma prática bacana (para si mesmo e para o seu código).

Conheça o padrão VETRO

Vamos aprender a usar este padrão em um exemplo fictício onde precisamos buscar os dados de um determinado cidadão do sistema da receita federal e gravar estes dados em um banco de dados local em formato SQL.

1. VALIDAR. 

O primeiro passo recomendado de toda integracão é realizar a validação dos dados recebidos. A validação pode verificar se o objeto de dados (um esquema XML ou texto JSON) está bem formado.  

Como os dados são gerados por aplicações externas, é sempre boa prática “desconfiar” dos dados que estão sendo recebidos, pois eles podem ter sido modificados na estrutura de negócio ou no formato técnico sem aviso prévio.

No exemplo dado, poderíamos checar se a mensagem XML com os dados de um cidadão estão em conformidade com o esquema XSD esperado.

2. ENRIQUECER

O termo enriquecer tem por objetivo adicionar dados adicionais ao pacote de dados recebido. Muitas vezes isso é necessário para que o pacote de dados esteja compatível com o formato esperado pelo destinatário.

No exemplo dado, poderíamos enriquecer a mensagem XML com os dados do cidadão com a informação do login do usuário que esteja usando a aplicação. Estamos considerando que esta informação nova poderia ser usada para auditoria

3. TRANSFORMAR

O próximo passo é realizar a transformação dos dados (seja no formato dos dados ou protocolo técnico). No nosso caso, queremos extrair da estrutura XSD e colocar em um formato universal da plataforma que estamos usando.

Por exemplo, se estivéssemos escrevendo estes códigos em Java ou C#, poderíamos criar um objeto POJO ou POCO com os dados do cidadão enriquecidos com o login do usuário.

4. ROTEAR

Agora estamos próximo do fim e neste passo estamos fazendo o roteamento da informação para o seu destino. No nosso caso, iremos abrir a conexão (IP e porto) com o banco de dados onde iremos salvar o nosso POJO ou POCO com os dados do cidadão.

Em cenários mais elaborados, o roteamento pode envolver rotas complexas.

5. OPERAR

Finalmente, iremos gravar os dados no banco de dados. O passo operar implica em entregar a informação para o destinatário final e terminar a rotina de integração.

O padrão VETRO pode ser implementado através do padrão de desenho cadeia de responsabilidades em Java ou C# e curiosamente forma a base de vários produtos de ESB do mercado. Em projetos SOA, chamamos estas lógicas de serviços de mediação, que também possuem a mesma estrutura básica.

Independente da tecnologia ou plataforma, entretanto, organizar um código desta forma nos fornece limpeza semântica e boa organização em lógicas de integração.

Boas integrações!

Pensamento do dia:
"Manifest plainness,
Embrace simplicity,
Reduce selfishness,
Have few desires.",
Lao-tzu

1.  Nenhuma abordagem arquitetural. Nenhuma abordagem arquitetural é utilizada pelos times.
• Vantagens: Ciclo de iniciação é encurtado e todas as decisões técnicas são adiadas para a fase de construção. Tende a funcionar bem para projetos muito simples como por exemplo cadastros Web em Intranets.
• Desvantagens: Adiamento do risco e possível retrabalho na fase de construção. Ausência de uma visão técnica compartilhada sobre estilos, plataformas e técnicas arquiteturais diversas.
• Análise: Possível sintoma de times pseudo-ágeis que afirmam não precisar realizar nenhum tipo de modelagem ou documentação.
2. Abordagem leve de alto nível. Esta técnica é chamada de envisionamento em algumas escolas ágeis e normalmente envolve que times discutam as principais questões técncias em tornos de quadro brancos por algumas horas ou alguns dias, se necessário.
   • Vantagens: Reduz o risco de projeto por trabalhar nas questões técnicas mais críticas do projeto. Também permite que o time compartilhe uma visão técnica compartilhada. Também gera um certo grau de flexibilidade ao adiar algumas opções tecnológicas para fases seguintes do projeto.
   • Desvantagens: Requer alta colaboração entre o time e pessoas com grande conhecimento técnico e experiência arquitetural.
   • Análise: O adiamento de algumas decisões pode levar a aumento do risco em projetos. Algumas vezes, a iniciação é o melhor momento para a tomada de decisões técnicas.
3. Interfaces detalhadas. Nesta abordagem, os principais componentes e sub-sistemas da arquitetura são identificados e detalhados em nível de API. A técnica é chamada de API First na comunidade Eclipse.
   • Vantagens: Permite que vários times trabalhem em paralelo nas APIs dos diversos componentes arquiteturais.
   • Desvantagens: Um maior gasto de tempo na iniciação e um risco de excesso de engenharia no começo do projeto o que pode aumentar o seu custo e tempo para entrega.
   • Análise: Excesso de desenho das APIs pode levar a um desenho dos elementos internos dos componentes. A falta de desenho das APIs pode levar a problemas não vistos na implementação com efeitos colaterais diversos.
4. Especificação detalhada de ponta a ponta. Nesta abordagem, todos os mecanismos arquiteturais são detalhados em todos as camadas arquiteturais do produtos sendo construído
   • Vantagens: O contrato técnico da solução é bem delimitado já no começo do projeto. Esta técnica também habilita que vários times trabalhem em paralelo e pode ser muito apropriado para projetos de preço fechado.
   • Desvantagens: Um investimento muito pesado em arquitetura no começo do projeto pode levar a gerência a crer que a arquitetura irá realmente funcionar, o que ainda não foi provado através de código. Além disso, todas as decisões técnicas foram baseadas em requisitos que podem ainda evoluir e aumentar o risco de retrabalho destas decisões. 
   • Análise: A análise técnica detalhada não remove questões críticas como times potencialmente fracos para trabalhar em arquiteturas sofisticadas. 

   .

Já tivemos a oportunidade de trabalhar com as abordagens (2), (3) e (4) e percebo que o contexto é rei para guiar a nossa escolha.

Quando tive a oportunidade de trabalhar em uma empresa de produtos, a abordagem centrada em APIs era bastante natural e permitia estabelecer acordos claros de resultados técnicos entre os diversos times que estravam construindo os produtos. Foi sem dúvida uma experiência muito saudável.

Em outros momentos onde pude trabalhar com a abordagem (2) em empresas de menor porte com um pequeno time de bom nível técnico, os resultados também foram muito bons e aderentes a pressões críticas de tempo. Curiosamente, quando tentei usar a abordagem (2) em ambientes com pessoas mais imaturas tecnologicamente, os resultados foram péssimos.

Nos projetos que trabalhei com a abordagem (4), realmente o principal desafio é gerir as expectativas gerenciais e evitar preciosismos técnicos que não poderão ser acomodados por times não-seniores.

Frase do dia: “Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”,  Eliel Saarinen.

É lamentável, entretanto, que pessoas sem as mínimas noções de engenharia de software e muito menos de métodos ágeis levantem bandeiras como se fossem do seu time de futebol ou partido político preferido por simplesmente desconhecer e não aplicar técnicas ágeis.

Baseado nas essências de técnicas ágeis sólidas de métodos como o XP e a Entrega Ágil Disciplinada, coloquei aqui um teste de fragilidade técnica. Notas baixas indicam um desenvolvedor pseudo-agilista que carrega uma bíblia mas sem saber nem o pai-nosso e a ave-maria de cada dia.

Teste de Fragilidade – Proibido para Mocinhos e Mocinhas Chorões.

Para cada resposta A, some 3 pontos.
Para cada resposta B, some 2 pontos.
Para cada resposta C, some 1 ponto.
Para cada resposta D, não some pontos.

1. O código fonte é o ativo mais importante resultante do trabalho do seu dia a dia. Você cuida dele apropriadamente? Se sim, quantas vezes por semana você aplica técnicas de refatoração sobre ele?
1. 5 vezes. [Dou banho todo dia no meu código e observo métricas de qualidade de código como complexidade ciclomática com rigor]
2. 3 ou 4 vezes [Ok. Às vezes me esqueço de dar banho no meu código.]
3. 1 ou 2 vezes [Então. Sou meio porquinho e não gosto muito de tomar banho e não me importo com o mau cheiro dos meus códigos também.]
4. 0 vezes [Refatoração? O que é isso?]
2. Defeitos são indesejados e podem ser comparados a resíduos industriais de empresas ou baratas em esgotos. Você tem disciplina de testes de desenvolvimento? Se sim, quantas vezes por semana você cria testes de unidade e executa testes de regressão sobre o seu código?
1. 5 vezes. [Piso em toda barata que vejo na rua! Portanto só saio do escritório com o teste de regressão executado com sucesso.]
2. 3 ou 4 vezes [Sou atento e gosto de fazer testes de unidade mas às vezes falho para executar smoke testes e testes de regressão no fim do dia]
3. 1 ou 2 vezes [Então. Sou meio preguiçoso para criar testes de unidade. Gosto de inventar desculpas e acho que isso é problema dos analistas de testes chatos que só fazem pegar no meu pé]
4. 0 vezes [Regressão? Tem a ver com vidas passadas, certo?]
3. Desenvolvedores normalmente trabalham em times e criam projetos através de repositórios como SVN, Microsoft TFS ou GIT. Quantas vezes por semana você tem contato com o seu repositório SCM?
1. 5 vezes. [Desço e subo código todo dia, conheço e uso padrões SCM com excelência.]
2. 3 u 4 vezes [Ok. Ás vezes deixo o meu código na minha máquina antes de ir embora para casa. Gosto de viver emoções fortes]
3. 1 ou 2 vezes ["I'm a cave man. I'm a jungle man. A young man. A young man. I fight with my hands....", Homem Primata, Titãs, Cabeça de Dinossauro.]
4. 0 vezes. [SVN? Isso é marca do novo isotônico, certo?]
4. Desenvolvedores normalmente trabalham em linguagens OO como Java, C# ou mesmo em linguagens híbridas OO-Procedural como C++ ou PHP. Quantas vezes por semana realizo modelagem ágil e organizo apropriadamente o meu modelo de classes executável?
1. 5 vezes [Conheço padrões de análise, padrões de desenho e padrões GRASP e os uso com parcimônia sobre os meus códigos. Além disso, faço junto do meu time diversas sessões de modelagem com o uso de quadro branco]
2. 3 ou 4 vezes [Gosto e aplico sessões de modelagem ágil, mas ainda não conheço plenamente técnicas de padrões e modelagem]
3. 1 ou 2 vezes [Veja bem, a minha empresa não tem quadro brancos, nem cartolinas, nem papel, nem caneta? O que posso fazer?]
4. 0 vezes [Comunicar com outros seres humanos em sessões de modelagem? Não, obrigado. Programar para mim é uma atividade individual. A propósito, o que é parcimônia mesmo?]
5. Times ágeis entregam software funcionando em pequenos incrementos para os seus usuários com o uso de técnicas como integração contínua ou entrega contínua. Quantas vezes por semana você gera produtos potencialmente demonstráveis (Alfas ou Betas) para o seu Product Owner, Analista de Negócio ou cliente.
1. 5 vezes. [Me espelho em projetos como a IDE Eclipse, que tem quase 50 milhões de linhas de código, é construído de forma distribuída no mundo inteiro e ainda assim gera produtos em base diária]
2. 3 ou 4 vezes [Gosto de liberar produtos com frequência para demonstração para o PO, mas tenho dificuldades em fazer isso e às vezes falho]
3. 1 ou 2 vezes [Estou começando a aplicar esta técnica, mas ainda tenho um longo caminho para trilhar neste aspecto.]
4. 0 vezes [Veja bem. Na minha empresa tudo é impossível fazer isso e além disso você já sabe que gosto de inventar desculpas para enrolar no meu trabalho, não é]
6. A priorização de requisitos e o cumprimento de acordos das metas dos sprints e metas diárias é parte indissociável de todo desenvolvedor ágil? Quantas vezes por semana você conversa com o seu time para reportar as metas diárias, impedimentos e o progresso em relação às metas semanais.
1. 5 vezes [Faço stand-up meetings faça sol ou faça chuva. Cumpro religiosamente as minhas metas diárias e reporto impedimentos imediamente quando os mesmos surgem]
2. 4 vezes [Ainda não tenho tanta disciplina e às vezes falho em cumprir minhas metas diárias e em me comunicar com o meu time.]
3. 1 ou 2 vezes [Então. Tenho dores de barriga com frequência, estudo à noite e minha namorada fica me ligando toda hora. Não tenho tranquilidade para produzir código e portanto falho as minhas metas com frequência]
4. 0 vezes [Já não te disse que não gosto de conversar com outros seres humanos!! *$*##&@)# ]

O mundo real e a pressão por entregas em produção, entretanto, é implacável. Gerentes e clientes pressionam os times técnicos por prazos cada vez mais arrojados. Como mágicas e unicórnios não existem, uma técnica chamada de gestão do débito técnico arquitetural pode ajudar nesta questão.

Débito Técnico Arquitetural

Uma arquitetura de software ideal implementa n táticas arquiteturais. Uma arquitetura evolutiva, ao invés, implementa m|m < n táticas arquiteturais. Uma tática arquitetural deliberadamente ausente será adiada na primeira entrega em produção. Esta ação irá gerar dois efeitos (um positivo e um negativo).

• O atendimento a prazos de negócio como por exemplo regulações ou pressões da área de marketing de uma empresa para lançar um novo produto;
• Um produto que deve um atributo de qualidade não realizada por alguma tática. Por exemplo, um código com manutenibilidade reduzida ou uma aplicação Web com ausência de portabilidade entre navegadores.

Os Juros do Banco Arquitetural

O banco arquitetural cobra juros altos, proporcionais ao tamanho do sistema em termos de seus requisitos e o custo da refatoração de cada caso de uso.

Débito Arquitetural = ƒ (Número de Requisitos, Custo Médio de Refatoração Arquitetural por Requisito)

Como exemplo, se um sistema tem 70 telas e o custo de refatoração e testes para portabilidade ao navegador Chrome é de 8 horas por caso de uso, temos um débito arquitetural de 560 horas. Se o custo médio de um profissional de uma fábrica de software é de 60 reais, então podemos até quantificar o débito técnico da arquitetural em R$ 33.600 reais.

É importante lembrar que que sistemas crescem em termos de suas funcionalidades ao longo do tempo e portanto o débito aumenta à medida que o tempo aumenta. Este aumento não é linear pois quanto mais tempo decorre menor se torna o conhecimento sobre os atributos de qualidade originalmente implementados, i.e., o custo de unidade da refatoração também tende a aumentar.

Ir ou não ao Banco Arquitetural?

Se o benefício de negócio é maior que o débito técnico gerado, então o uso de uma arquitetura evolutiva pode se tornar um bom negócio para a empresa. Embora isso incomode os engenheiros de software e arquitetos mais puristas, é importante entender que um projeto de software é apenas uma engrenagem no contexto de uma empresa e que muitas vezes o débito pode ser tornar uma questão de sobrevivência empresarial.

Por exemplo, se no exemplo anterior a área de marketing estimou que um produto lançado 2 meses antes devido a ausência de suporte ao Chrome poderá gerar R$ 100.000 reais de benefícios de negócio, então a portabilidade multi-navegador poderia ser hipoteticamente adiada para uma v2.0 do produto. O lucro com a decisão poderia gerar quase R$ 70.000 reais para a empresa, descontados já o pagamento do débito.

A análise no mundo real, naturalmente, deve ser mais criteriosa e pode considerar uma análise quantitativa de riscos para incluir ao valor do débito arquitetural. A mensagem final, entretanto, é que arquiteturas evolutivas podem ser excelentes mecanismos para responder a pressões de mercado e atendimento a elementos regulatórios.

Um arquiteto de integração é exposto a três soluções possíveis de RPC:

1. Criar uma API sobre SOAP/HTTPS, expor os serviços da empresa em WSDL e criar objetos de dados complexos em XSD.

2.Expor a API  sobre protocolo HTTPS através dos métodos GET/POST em um mecanismo REST.

3. Criar uma comunicação CORBA sobre GIOP/IIOP a partir do uso de COM+ ou WCF em .NET e consumir o objeto remoto através de um EJB (RMI/IIOP).

A lei da parcimônia nos diz para escolher a solução 2 neste contexto, dada que é a mais simples e irá resolver o problema sem a adição de mais complexidade à solução.

Se houver algum outra variável no problema, a solução é reavaliada naturalmente. Assumi no exemplo que nenhum outra questão se faz presente para tornar a explicação mais didática.

A lei da parcimônia é antiga e foi formulada por Willian of Ockham ainda no século 14. Ele descreveu o princípio que é conhecido como lâmina de Occam, que diz  que a explicação para qualquer problema deve assumir apenas as premissas estritamente necessárias à explicação do fenômeno e eliminar todas as que não causariam qualquer diferença aparente nas predições da hipótese ou teoria. Em outras palavras, este princípio recomenda assim que se escolha a teoria explicativa que implique o menor número de premissas assumidas e o menor número de entidades na solução.

Na arquitetura e desenho de software, este princípio nos diz que a solução mais simples para resolver um problema deve ser escolhida, quando temos diversas soluções para resolver uma determinada questão.

São contra-exemplos deste princípio:

• As famigeradas arquiteturas lasanhas do J2EE 1.3 e 1.4 com quase 10 camadas entre a tela  o banco de dados.
• Objetos de transferência TO/VO iguais aos objetos de domínio (POJO/POCO).
• Bancos de dados normalizados além da necessidade do problema.
• Padrões de desenho artificiais.
• Métodos/Funções com centenas de linhas de código.

Um bom exemplo da simplicidade aplicada é o método EssUP de Ivar Jacobson. Uma lâmina no contexto da essência arquitetural de um projeto é apresentada aqui para os interessados.

“We are to admit no more causes of natural things than such as are both true and sufficient to explain their appearances. Therefore, to the same natural effects we must, so far as possible, assign the same causes.”, Isaac Newton

Esta espécie está disfarçada entre nós em forma humana e por isso não é trivial reconhece-los em projetos. Mas algumas atitudes evidenciam a sua presença nefasta e danosa. Exemplos abaixo:

• “Testes de unidade automatizados!? Não. Eu sou apenas um desenvolvedor. O papel do teste é para o time de testes”.
• “Padrões de projeto. Não, obrigado. O meu código não precisa disto”
• “Refatoração? Para que? Eu já tenho experiência em escrever código.”
• “Idioms? Sim! Eu estudo inglês faz 6 meses!”
• “Métodos pequenos? Nossa. Que trabalho eu vou ter!”
• “Documentação de código? O meu código é tão bom que dispensa comentários”
• “Entregar código diariamente no repositório? Impossível! O nosso projeto é muito complexo para isso”
• “Integração contínua? Conheço não.”
• “Gerar builds para demonstração semanal com os usuários? Para que? Eu não gosto de usuários e prefiro ter um único contato no final do projeto com estes malditos!”

Se ainda assim você não reconhecer esta espécie, fique atento às frases abaixo que também os denunciam:

• “Eu vou tentar!”
• “Eu vou fazer o meu melhor, ok!”
• “Sim. Está em 90%. So falta testar.”
• “Estudar. Não preciso mais não. Eu já me formei em um curso SUPERIOR na Universidade Tabajara”

E você? Conhece algum desenvolvedor do planeta Weakland na sua empresa? 

Mas qual seria a decisão mais importante que um arquiteto deve tomar. A decisão sobre o estilo da arquitetura é sem dúvida uma destas decisões. Alguns estilos arquiteturais incluem:

• Cliente-Servidor
• P2P
• Multicamadas (n-tier)
• Centrado em serviços de negócio (SOA)
• Centrado em processos de negócio (BPMS)
• Centrado em computação paralela massiva (Grid)

No que tange à tecnologia, entretanto, o conceito da plataforma é sem dúvida a decisão mais importante. A plataforma é o elemento técnico que dá vida ao estilo arquitetural.

Um plataforma é um arranjo de softwares e servidores organizados de forma coerente para resolver problemas comuns no desenvolvimento de software. Dois exemplos comuns de plataformas incluem o Java EE e o Microsoft .NET. Um outro exemplo de um plataforma é o LAMP, que é um arranjo composto de sistema operacional baseado em Linux, servidor Web Apache httpD, servidor de banco de dados MySql e linguagens dinâmicas como PHP, PERL ou Python.

O Java EE,  .NET ou LAMP são usados normalmente para sistemas de informação Web. Naturalmente existem cenários da realidade de mercado onde necessidades mais específicas surgem. Para estes cenários existem outros tipos de plataformas de mercado, muito além do Java EE e o .NET.

Exemplos incluem:

• Plataformas de ERP/MRP (Enterprise Resource Planning/Material Resource Planning), usadas para automatizar processos de suporte de organizações. Exemplos de produtos nesta linha são o SAP ECC, o Oracle PeopleSoft e Oracle JD Edwards.
• Plataformas de portais usadas para a criação de sites que unifiquem informações de diversas fontes. Exemplos incluem o Microsoft SharePoint, o Oracle Portal ou o IBM WebSphere Portal.
• Plataformas de serviços interoperáveis para estilos centrados em serviços SOA. Exemplos incluem o Microsoft WCF ou o Apache Tuscany (padrão SCA).
• Plataformas de automação de processos de negócio (BPMS) para empresas que estejam e estágios avançados de implementações BPM. Exemplos incluem o IBM Business Process Manager ou o Oracle BPM.
• Plataformas de serviços de decisão (BRMS) para empresas que busquem flexibilidade e responsividade extrema para as suas regras de negócio. Exemplos incluem o IBM ILOG Operational Decision Management ou o Redhat JBOSS Drools.
• Plataformas de BI/ETL para o suporte a inteligência de negócios avançada. Exemplos incluem a suíte de produtos IBM Cognos, Microsoft SISS ou Oracle Hyperion.
• Plataformas de integração de aplicações chamadas de ESB (Enterprise Service Bus). Exemplos incluem o SAP PI, IBM WebSphere ESB e o Microsft BizTalk.

Se escolhemos uma plataforma arquitetural inadequada teremos graves problemas durante o projeto. Curiosamente, muitos “arquitetos” consideram a plataforma como dada e nem sequer pensam nisso. É a síndrome do arquiteto de uma plataforma só, que coloca a tecnologia na frente do problema.

Arquitetos de soluções racionais agem na direção inversa. Eles tem a mente aberta e fazem uma análise dos condutores arquiteturais. A partir destes condutores eles recomendam a plataforma mais apropriada que irá promover o melhor balanceamento dos condutores.

Em cenários mais sofisticados, uma solução pode exigir um conjunto de plataformas distintas. Em um caso SOA que estamos trabalhando atualmente, uma determinada empresa organizou a sua infraestrutura a partir de um conjunto de soluções integradas de BPMS, SOA e ESB.

Grandes fornecedores de mercado como a IBM, Oracle, TIBCO, SAP, Redhat, entre outros gigantes, possuem esquemas conceituais que nos permitem navegar neste mar de tecnologias. Deixo para os curiosos e aficionados pelo tema duas referências respectivamente da IBM e da Redhat.

Arquitetura Referência IBM

Arquitetura Redhat JBOSS Enterprise Middleware

Uma técnica para auxílio neste processo é fornecida por uma ferramenta da psicologiachamada de Janela de Johari que também usada em alguns círculos de engenharia de requisitos.

Adapto este conceito para o contexto de arquitetura de software, exibido na figura abaixo.

A figura mostra nem todo requisito é conhecido pelo nosso time e pelos nossos usuários e este desconhecimento (nosso, dos usuários ou de ambos) é fonte de muitos problemas.

Vamos contextualizar o conceito em um exemplo didático de um sistema de Internet Banking. É natural (para qualquer arquiteto e para os usuários chave de um Banco de Crédito) que aspectos de segurança devem afetar a arquitetura executável do produto sendo criado. Portanto, aspectos de autenticação, autorização e transporte seguro estariam no quadrante Q1, que é o dos requisitos arquiteturais óbvios. Até agora não temos nenhum problema.

Vamos considerar agora alguns requisitos de qualidade interna como a manutenibilidade ou a testabilidade, que são normalmente conhecidos pelo nosso time. Normalmente aspectos de qualidade interna não são percebidos diretamente pelos usuários chave, o que os coloca no quadrante Q4. Portanto, arquitetos devem tomar cautela extrema com estes requisitos pois eles não são normalmente percebidos pelos usuários e portanto não valorizados. A consequência é que eles podem causar aos usuários a sensação de baixa produtividade na execução de código pelo time de desenvolvimento. Ainda pior, eles podem encarecer o seu projeto sem percepção de valor similar para os seus usuários.

Vamos agora considerar alguma norma obscura do Banco Central que lide com algum aspecto regulatório. Se a maturidade dos usuários envolvidos no projeto e da equipe de arquitetura for baixa, este requisito regulatório, que pode afetar a arquitetura, estaria colocado no quadrante Q3. A lição aqui é óbvia. Os usuários normalmente não conhecem todos os requisitos e portanto devemos buscar requisitos que podem afetar a arquitetura em outras fontes de informação.

Finalmente, vamos lidar os requisitos mais perigosos, que são elementos óbvios para os usuários mas não óbvios para o time. Por exemplo, o usuário pode assumir que a portabilidade entre navegadores para dispositivos móveis é dada. O time, por sua vez, pode nem ter considerado esta possibilidade. Tipicamente estes requisitos do quadrante Q2 são fontes de desgaste durante o projeto e envolvem retrabalho para o time pois afinal eles são “óbvios” para os usuários.

Em cenários ideais gostaríamos de mover todos os requisitos para o quadrante 01, mas o fato é que sempre haverá requisitos nos quadrantes Q2, Q3 e Q4 também. Naturalmente a aplicação de métodos arquiteturais de coleta de requisitos reduzirá a probabilidade que isto aconteça. Algumas dicas rápidas para isso incluem:

• Realizar reuniões e oficinas de trabalho para mover os requisitos do quadrante Q2 para o quadrante Q1. Técnicas de leitura ambiental também são úteis neste contexto.
• Buscar outras fontes de informação além do ambiente e informações fornecidos pelos próprios usuários podem mover alguns requisitos do quadrante Q3 para o quadrante Q1.
• Educar usuários sobre os requisitos que eles não conhecem pode ajudar a levar requisitos do quadrante Q4 para Q1. Em outras situações, talvez devamos remover alguns requisitos de Q4 do escopo do nosso projeto.

Pensamento do dia: “O combinado não é caro”, Anônimo