Desacoplamento

Vamos falar um pouco desse assunto.

É um assunto bem interessante e gerou uma baita confusão hoje lá no escritório. Não vou entrar em detalhes sobre a confusão causada pois envolve questões políticas e comerciais que não tenho o menor interesse e acho que não cabe nesse blog.

Mas o interessante dessa questão é justamente a confusão que gera. O que é desacoplamento? Eu entendo como um tipo de isolamento entre camadas ou aspectos diferentes.

Por exemplo, quando instanciamos um objeto para utilizar seus métodos e propriedades, estamos criando uma dependência para aquele objeto. Se ele por algum motivo este objeto não estiver presente no momento do desenvolvimento, o programa que depende deste objeto sequer compilará.

Isso em um ambiente de desenvolvimento isolado não causa muitos problemas, pois normalmente todos objetos estão a disposição do desenvolvedor, ou ainda este os está criando, então essa equipe tem controle total sobre as dependências do projeto.

Mas em um outro cenário, como o que estou vivenciando na empresa onde trabalho, temos uma outra situação. Duas equipes de empresas diferentes estão trabalhando em um mesmo projeto.

Não pense que ao ler este blog você encontrará todas as respostas. Na verdade, eu não tenho essas respostas, pois ainda estou fazendo as perguntas. A experiência nos está guiando para um rumo que não está dando certo, portanto, é a melhor forma de se obter as respostas.

Quando as coisas vão bem, não sabemos se está dando certo por um ou por outro motivo, não importa. Mas quando as coisas dão errado, procuramos de forma mais objetiva resolver esses problemas e com isso vamos achando as soluções. E dessa forma temos certeza que são as respostas certas, pois as perguntas começam a surgir; e essas sim importam!

O que acontece é que a outra equipe está desenvolvendo a camada de interface, no caso, Web. Nós estamos desenvolvendo a camada de serviços.

A confusão começou pela decisão de passar a fórmula para desenvolver a camada de serviços para a outra equipe, que não entendeu nem para que serve essa camada.

Ou seja, nós estamos desenvolvendo essa camada de serviços e a outra equipe também. Depois a idéia era juntar os pedaços. Aproveitaríamos a camada Web desenvolvida pela outra equipe, e a camada de serviços deles seria descartada e a nossa utilizada no lugar.

Isso gerou uma baita confusão, pois a outra equipe desenvolveu a camada de serviços de forma errada e agora nos acusa de ter gerado muito acoplamento.

Surgiu então a dúvida, como desacoplar o desenvolvimento das duas equipes? Eis a pergunta que realmente importa!

Existem alguns níveis de desacoplamento. Um deles é gerar interfaces, em forma de contrato de todas as classes que compõem a camada de serviços. Depois passar essas interfaces em uma DLL separada para a outra equipe e eles saberiam exatamente como acessar os métodos necessários para o desenvolvimento.

Mas este nível de desacoplamento não seria suficiente, uma vez que apenas as interfaces, sem implementação não são suficientes para os desenvolvedores da outra equipe sequer compilarem os seus códigos. Pois a única coisa que eles poderiam fazer seria tipar os objetos. Mas não instanciá-los. Toda e qualquer instância depende da classe concreta.

A solução seria então adotar um framework específico para isso baseado no padrão de injeção de dependência e inversão de controle. Ou seja, os objetos seriam injetados de forma declarativa (leia-se configurações em arquivos XML) para não gerarem dependência no ato da compilação. Invertendo-se assim o controle de quem precisa do quê.

Agora nesse exato momento, estou ponderando onde erramos, pois a abordagem utilizada foi exatamente a explicada no parágrafo anterior. Para isso, o arquiteto decidiu utilizar o framework Spring.Net.

Aparentemente todos os problemas pareciam estar resolvidos, mas não. Acredito que nosso erro foi exatamente em passar a receita para esse modelo de desenvolvimento para a outra equipe, que no final das contas se deparou com dois problemas, e não apenas um, como eles esperavam.

O que quero dizer é que eles além de aplicar a injeção de dependência, tiveram que estudar e implementar a programação dos serviços. E isso não é tarefa fácil.

Acredito que deveríamos ter passado para eles apenas as nossas interfaces, e os orientado a apenas injetar as implementações. E não a ter que implementar também o que seria injetado, pois essa deveria ser nossa responsabilidade.

O resultado é que gerou tensão entre as duas equipes e ainda o resultado final do produto que eles criaram ficou confuso e ruim. Sem falar que ficou muito diferente do nosso.

Como a camada de serviços da outra equipe ficou diferente da nossa, não pudemos então apenas substituir a programação deles pela nossa. Essa era a idéia original, que foi pelo buraco.

O que se segue é que amanhã a equipe de fora vai para dentro, trabalhar ao nosso lado, para que possamos sincronizar os códigos e atingir o objetivo.

Frustrante.

Até a próxima,
Graccs.