Fragmental

A melhor coisa desse lance todo de vídeo em flash barato, portais de conteúdo em vídeo, screencasts, etc. é que nós, pobres brasileiros afastados de tudo que é legal em tecnologia, podemos assitir palestras e não apenas pegar os PDFs.

Recentemente eu lidava com 3 grandes sistemas legados, fracamente relacionados entre si e construídos em paralelo. O problema é que a relação forma a coisa mais odiosa que se pode ter no gerenciamento de dependências: dependências cíclicas!

A coisa surgiu como um projeto dividido em dois módulos.

Projeto waterfall, na primeira mudança foi ‘dado um jeitinho’ e uma funcionalidade que o backoffice precisava já estava disponível no sistema…

Em breve surgiu o outro projeto no horizonte e o arquiteto resolveu que haviam funcionalidades de um que podiam ser aproveitadas no outro. Pena que ele não olhou para os diagramas UML que desenhou com tanto carinho.

Mas tudo bem. Tudo seria resolvido com a versão 2.0 do projeto. Basta fazer uns ajustes aqui, reutilizar aquilo ali…

Neste ponto o projeto ficou ingerenciável. Simplesmente não se podia tratar um bloco de software isoladamente, era tudo parte de um grande emaranhado de componentes frágeis que compartilhavam código e possuíam nível de acoplamento absurdo. Passar um componente para produção indicava passar e testar todos os componentes. Pior que isso: para subir a versão 2.0 do projeto precisávamos manter a primeira versão porque ela era uma dependência transitiva!

Corrigir este problema não é tarefa simples, mas Uncle Bob nos dá algumas regrinhas muito úteis:

• REP - Reuse-Release Equivalnece Principle: Tudo que é criado apra ser reutilizável deve ser empacotado corretamente. Software criado para reuso deve ser projetado para isso do início, de maneira lógica. Não deve haver código não-reutilizável num pacote reutilizável.
• CRP - The Common Reuse Principle: Classes num pacote são reutilizadas em conjunto, se você reutiliza uma reutiliza todas. Uma pacote deve ser uma unidade atômica, as classes que estão dentro dele devem fazer sentido apenas se usadas em conjunto. Não devem haver classes utilizadas isoladamente num pacote reutilizável, a unidade de reuso é o pacote, não a classe.
• CCP - The Common-Closure Principle: Uma generalização do Single Responsibility Principle (SIP). Para o SIP uma classe deve ter apenas um motivo para ser alterada, se mais de um tipo de mudança no sistema afeta a classe provavelmente ela pode ser dividia em mais de uma, ela representa conceitos demais. O mesmo se aplica para pacotes. Um pacote também deve seguir o Open-Closed Principle (OCP) e se proteger de mudanças ao mesmo tempo que está aberto à extensão.
• SDP - The Stable-Dependencies Principle: Um pacote que se espera ser volátil (mudar facilmente) não pode ser dependência de um pacote que se espera estável (mudar quase nunca). Pacotes estáveis devem depender apenas de pacotes estáveis. Pacotes voláteis podem depender de outros voláteis, mas idealmente devem também depender apenas de pacotes estáveis. Muitos pacotes voláteis em uma corrente de dependências causa um estrago muito grande no ‘efeito dominó’.
• SAP - The Stable-Abstractions Principle: Um pacote deve ser tão abstrato quanto estável. É mais que certo que quanto mais próximo uma abstração chegar da realidade mais facilmente ela muda. Um pacote abstrato (e neste caso isso geralmente significa classes abstratas mesmo) é mais estável porque não se rpende a detalhes de implementação.

Aplicando essas e outras técncias fatalmente chegamos a uma situação ainda ruim, mas ao menos gerenciável.

E finalmente ao que consideramos aceitável.

Tudo ao gasto de alguns meses sem desenvolvimento de coisas novas, só arrumando a bagunça. Note que este sistema não foi originalmente criado por amadores e sim por uma consultoria top top top multinacional.

Acontece que, como um dos envolvidos no projeto original me disse durante o projeto “essas coisas funcionam muito bem na teoria mas a prática é outra”, logo antes de afirmar que nunca lera nada sobre gerenciamento de dependências e “trabalhava muito bem sem isso”.

Será que é mesmo a teoria que possui problemas?