SOA: Sem Objetivo Altruísta?

Há mais ou menos um ano, na empresa onde trabalho, teve início esforços para a adoção de uma arquitetura SOA.

Uma consultoria renomada intercionacionalmente foi contratada para realizar as primeiras análises. Foram realizadas entrevistas e reuniões com o pessoal que melhor apontasse o cenário atual da empresa relacionada ao desenvolvimento de software: qual o tamanho dos projetos, como é feito o controle de versão, se existe uma arquitetura corporativa, se existe serviços corporativos, qual o grau de reúso, se há padrões de nomenclatura, etc. Análises pertinentes ao processo de implantação, suporte e produção também foram levantadas.

Feito isso, elaborou-se um plano de ação que identifica o atual estágio e qual é o desejado, e como isso será atingido. Para tanto criou-se um planejamento estratégico que guiará o caminho. Passos importantes já foram dados: a escolha de um modelo para o Comitê Gestor SOA e sua criação, contratação de pessoal qualificado e levantamento dos projetos candidatos a fazer uso dessa arquitetura.

Visto isso, não há dúvidas que exista um patrocínio do alto escalão, o que é muito positivo já que uma mudança como essas envolve toda a organização.

Seguindo o planejamento, uma das fases é a disseminação dessas ações à todos os envolvidos diretamente, que até então não haviam participado dessas discussões. Isso ocorreu através de uma palestra.

Iniciou-se com conceitos básicos para tomar conhecimento sobre SOA, apresentando os seus inúmeros benefícios. Prosseguiu-se daí chavões como reúso, ativos de software, arquiteturas flexíveis, interoperabilidade, chavões ditas “a baciada”. Sem mencionar BPEL, BPM, orquestração de serviços…

Éramos apresentados a uma nova “Bala de Prata”, incluso seu Tookit: ferramentas para gerenciamento de serviços, monitoramento, versionamento, roteamento e outra$. Além da tão e velha conhecida promessa na qual a pessoa de Negócios desenha o processo (arrastando caixinhas), e o desenvolvedor num piscar de olhos gera uma nova funcionalidade.

É importante dizer que SOA pode ser vista como uma escolha arquitetural que visa a criação e reutilização de Serviços consequentemente obtendo redução de custos, maior qualidade de software, maior produtividade, enfim, um meio inteligente de criar sistemas em nível corporativo. É uma decisão isenta da adoção de novas ferramentas.

Daí a bronca com tal apresentação. Esperava-se que as análises, entrevistas e reuniões levantassem quais são as maiores dificuldades existentes hoje. Se é baixa qualidade, se há alto índice de manutenção, se os projetos atrasam, se os usuários estão insatisfeitos, ou seja, que fossem apontados os porquês da empresa deixar de atingir resultados ainda melhores.

Feito isso, dizer como a adoção de uma arquitetura SOA traria benefícios, ou seja, faltou mencionar um dos seus principais objetivos: o alinhamento de TI com o Negócio.

Espero que apenas a apresentação tenha seguido tal caminho, senão seremos vítimas de mais uma moda tecnológica que tem fim em si mesma.

Um pouco de programação…

Abrindo parênteses no assunto de ansiedade e aproveitando a deixa sobre testes automatizados, surgiu a oportunidade de experimentar um pouco do framework para testes, o TestNG.

Até então eu utilizava o JUnit, mas sem as novas features introduzidas através do Java 5. O JUnit é bastante apropriado e satisfatório caso você crie uma pequena estrutura para prover reúso a fim de facilitar asserções com diferentes cenários, reaproveitamento de métodos utilitários, etc. E ainda, com o emprego de anotações, seria possível escrita de menos código, tornando-o mais limpo/legível. Mas…esses benefícios justificariam a substituição da tão batida e velha conhecida versão anterior? Provalvemente não.

Por isso, como surgiu a oportunidade para experimentar algo novo, fui atrás do TestNG. Ele surgiu após o JUnit, e soube tirar proveito, atendendo algumas necessidades importantes.

A mais interessante que empreguei até agora, foram os Data Providers. Através deles você escreve o teste e parametriza os cenários. Muito útil, já que facilmente são escritos N casos de teste rapidamente. Há também o ganho da legibilidade, pois facilmente é possível levantar quais casos foram validados.

É claro que existem muito mais funcionalidades. Para um primeiro contato, a impressão foi positiva e, caso você tenha tempo disponível, vale a pena investir umas horas num “test drive”.

Ansiedade X Testes

Dando sequência ao post anterior sobre ansiedade, falaremos sobre testes escritos, ou melhor, sobre a ausência deles.

Na pressa por assegurar que um código recém escrito esteja funcionando, o desenvolvedor opta pela forma mais rápida de testá-lo. Em java, uma das vias mais fáceis, é através da escrita do método main() na própria classe em questão. Geralmente o primeiro caso de teste é o tão conhecido “happy path”. Em questão de minutos, a lógica foi escrita, o programa executado, correções executadas e pronto. Pronto? Se houvesse somente um fluxo e nada mais, tudo bem.

Considerando que a pessoa lembrou que existem outros cenários, o que é feito geralmente? Ela edita o código, muda os valores (em vez de criar um novo teste) e repete o processo até obter sucesso. Feito. Dois casos testados e assegurados.

Esse processo ocorre mais algumas vezes e no final das contas têm-se apenas um teste escrito. Caso esses testes fossem estruturados através de um framework, como o JUnit por exemplo, todos os fluxos alternativos permaneceriam escritos.

A grande vantagem dessa abordagem é sobre a manutenibilidade e qualidade do código gerado já que outros desenvolvedores fututuramente irão deparar-se com a sua manutenção. Dessa forma, testes de regressão poderão ser executados facilmente a fim de garantir que a aplicação ainda funciona (em alguns casos, os próprios testes deverão ser ajustados).

De quebra, com a adoção de um framework para escrita de testes, existe a integração com ferramentas que realizam a build do projeto (ant ou maven). Qual a vantagem? Dependendo da configuração, você obriga que o projeto será empacotado se e somente se todos os testes rodem com sucesso.

Concluindo, a ansiedade na etapa de escrita de testes muitas vezes leva o programador a pensar que é perda de tempo estruturar os testes já que num primeiro momento gasta-se mais tempo; o ganho dessa automação geralmente não surti resultados instantâneos, mas quando começa a produzir efeitos, com certeza haverá um alto grau de confiança na alteração de uma lógica, alta rapidez na adequação da aplicação às regras de negócio e resumindo, um alto grau de qualidade.

Até a próxima.

Ansiedade

Ansiedade. Esta aí um dos grandes males que acometem uma grande massa de desenvolvedores de software. Aquela vontade incontrolada de ver as coisas rodando, não importando de qual jeito, mas desde que esteja lá: “funcionando”!

Se essa ânsia fosse acompanhada de esmero na execução do trabalho ela seria benigna. Infelizmente é o contrário que ocorre. Testes são deixados de lado, regras de negócios são entendidas parcialmente, fluxos alternativos são esquecidos, a documentação inexiste ou é escassa/confusa. No final das contas o trabalho deixa a desejar.

“Nós não temos tempo pra isso! O gerente pediu pra ontem!”. Isso é bastante comum, mas não é sempre. Estamos tratando do caso em que existe tempo disponível, mas o imediatismo pelo resultado acaba seduzindo o profissional.

A contrapartida é que esse ganho de tempo é efêmero. No próximo post veremos algumas das consequências.

Inauguração

O primeiro post oficial desse blog. A vontade de criá-lo já tem um certo tempo. Há tempos existe o querer de fazer saber a face insana do mundo da Tecnologia da Informação.

O lado tão discutido ultimamente, de prazos, de cascatas, do imediatismo, da picaretagem (essa disfarçada por vocabulários gentis) etc é tão manjado que seria insano chover mais ainda no molhado. Então qual será a temática proposta?

Inicialmente a pretensão é apresentar o lado daqueles que fazem, daqueles que sofrem com decisões gerenciais. Hmm…eles serão defendidos? Não, não. A idéia será apresentar sua parcela de responsabilidade a fim de deixar não somente a opção cômoda de vítima.

Dessa forma, o conteúdo será uma mistura de temas técnicos, gerenciais e comportamentais.