Parte do trabalho de um arquiteto de software consiste em empregar da melhor forma possível técnicas e boas práticas para construir uma aplicação levando em consideração variáveis como:

- tecnologias disponíveis;
- interesses de negócio;
- durabilidade da aplicação;
- custo;
- expectativa do usuário;
- skill da equipe técnica;
- entre outras.

Trocando em miúdos, uma decisão errada impacta significativamente na consonância entre essas variáveis. Vamos pegar como exemplo um problema conhecido por quem desenvolve software chamado alto acoplamento.

(Aqui em abro um grande parêntesis. O termo acoplamento às vezes é confundido com coesão, contudo são dois conceitos diferentes. Uma classe pode ser coesa e altamente acoplada com outras classes, como também pode acontecer de ser desacoplada de outras classes e possuir baixa coesão. Coesão está relacionado ao Princípio da Responsabilidade Única (PRU), ou seja, se uma classe possui mais do que um motivo para ser alterada, possivelmente ela está fazendo mais do que devia. Já o acoplamento refere-se ao quanto que uma classe depende de outra classe, assim sendo, o ideal seria termos sempre alta coesão e baixo acoplamento.)

Dentre as técnicas mais utilizadas para resolver o problema do alto acoplamento a injeção de  dependência (DI, dependency injection) ressurgiu com grande destaque, em parte graças a crescente prática de testes unitários e desenvolvimento baseado em testes (TDD). Martin Fowler certamente foi um dos grandes responsáveis pela popularização do termo injeção de dependência, considerado-o um tipo de IoC (Inversion of Control). Apesar de não ser nova, diversas bibliotecas de DI, conhecidas como lightweight container, facilitam a utilização desta técnica que, somada ao motivos do seu reaparecimento citados no início desse parágrafo, destacam-na com uma das “modas do momento”.

Um bom arquiteto, na minha opinião, deve tomar suas decisões levando em consideração as variáveis citadas no primeiro parágrafo, elencando uma série de questões pertinentes, e com base nelas procurando as respostas mais sensatas para a sua realidade. Pensando no tema injeção de dependência:

• A aplicação de DI pode representar um risco elevado levando em consideração o skill da equipe?
• A empresa tem como cultura a prática de testes (TDD ou qualquer outra técnica)?
• Se a aplicação não tem previsão de vida longa vale a pena aplicar DI?

E o caminho inverso também deve ser ponderado:

• Eu consigo aumentar o skill da minha equipe aplicando uma nova técnica?
• Eu consigo mostrar os benefícios de praticarmos TDD já que DI nos propicia isso mais facilmente?
• Eu consigo comprovar que os custos com manutenção serão menores se empregarmos melhores técnicas agora, ainda que isso onere um pouco mais o projeto?

Respondidas as questões, imbuído de tranqüilidade e principalmente harmonizando as variáveis em jogo o arquiteto pode partir para a tomada de decisão com mais assertividade. Deste modo, retomando a frase “o ideal seria termos sempre alta coesão e baixo acoplamento”, cabe ao arquiteto entender o quanto desse objetivo deve ser alcançado com o uso de DI.

Lembrem que a acepção da palavra “ideal” não deixa dúvidas:

ideal
adj.
1. Que só existe na idéia.
2. Que reúne toda a perfeição imaginável.
3. Conjunto imaginário de perfeições que não podem ter realização completa.

Arquitetura, Reverberando enterprise library, injeção de dependência, ioc

O título do meu post anterior foi um pequeno gracejo com o intuito de provocar alguma reflexão sobre a participação das pessoas em blogs de tecnologia da informação. Fora a única avaliação do post (de 1 ponto ), nenhum outro tipo de comentário foi realizado, até porque os comentários estavam bloqueados no post, propositalmente.

Vejo aqui no Brasil pouca participação nos blogs de tecnologia comparado com outros países (sempre encontro algum post de autor de blog reclamando da falta de participação), e quando digo participação refiro-me aos comentários. Seja para acrescentar alguma informação que faltou no post, discorrer sobre algum ponto forte ou fraco, dividir alguma experiência, ou até mesmo para sugerir outros assuntos um comentário é um meio rápido de disseminar conhecimento e informação, e infelizmente esse recurso é pouco utilizado (claro, essa é a minha opinião).

Um exemplo positivo com relação aos comentários em blog é a famosa série de posts do Rob Conery, chamada MVC-Storefront, onde além dos posts e vídeos produzidos pelo autor uma participação efetiva dos leitores através de comentários enriqueceram muito o conteúdo do blog. Óbvio, sempre existe aqueles comentários do tipo “Poxa, que legal, parabéns!”, mas no geral o conteúdo ganha um dinamismo providencial com as opiniões.

Acredito que o problema da pouca participação não seja exclusivo dos blogs, percebo que nos grupos de discussão isso também ocorre, com os chamados membros “read only”, pessoas que acompanham as thread como leitores somente.

Enfim, deixo aqui um novo post, com o bom formato Web 2.0, com o mecanismo de comentário habilitado, como de costume. Muito provavelmente não haverá nenhum comentário, ficaria positivamente surpreso se houvesse… Quem sabe, talvez o leitor que avaliou com 1 ponto o outro post possa dar alguma opinião agora, com os comentários habilitados?

Seria melhor imaginar que nada pudesse ser acrescentado? Hummm, acho que não.

Reverberando comunidade

O que vocês acham?

Reverberando comunidade

Sinceramente, não consegui formar uma opinião completa sobre isso:

http://msdn.microsoft.com/pt-br/beginner/bb308754.aspx

http://msdn.microsoft.com/en-us/devlabs/cc950524.aspx

Acho que estou ficando velho… e rápido demais.

Reverberando devlabs

Sempre achei fascinante a engenhosidade das Rube Goldberg Machines, a idéia de realizar operações extremamente simples através de uma engenharia complexa de eventos e ações é fabulosa (como entretenimento, claro). Pra quem não sabia, Rube Goldberg Machines foram originalmente criadas por Reuben Garret Lucius Goldberg numa série de cartoons que ficaram conhecidos internacionalmente. Hoje em dia existem até campeonatos incríveis de inventores que produzem esses aparatos, uma rápida busca no YouTube dá uma boa dimensão da coisa.

Abaixo coloquei um exemplo de uma máquina que tira creme dental do tubo. Repare que uma das ações consiste em fazer um pássaro mover um pino que sustenta um peso sobre o creme dental. Fantástico! Fala sério?

O fato é que, apesar de pitorescas, temos como certo que essas máquinas absurdas nunca seriam construídas na vida real, correto? Bem, infelizmente no desenvolvimento de software não é raro encontrarmos códigos ou soluções técnicas no melhor estilo Rube Goldberg. E a ocorrência deste tipo de problema se estende para analistas de sistema, arquitetos, e por aí vai.

Um desenvolvedor consciente deve desconfiar quando uma atividade simples requer uma grande cadeia de eventos e mecanismos para funcionar, e sempre se questionar se não existe um caminho mais curto e conciso para executar essa tarefa. Soluções muito rebuscadas só servem para dificultar a manutenção e o entendimento do código, ou seja, perda de esforço e investimento.

Se você fizer um retrospecto e chegar a conclusão que participou da construção de “Rube Goldberg Softwares” (com todo respeito aos geniais cartoons de Goldberg), sugiro que estude o quanto antes Design Patterns, técnicas de refactoring, boas práticas das tecnologias e metodologias que utiliza e convença os demais profissionais envolvidos a adotarem a mesma postura. Pode acreditar que vale a pena!

Um pássaro tirando um pino que sustenta um peso… Magnífico! :)

Reverberando boas práticas