1

Método Ágil vs. Sistema Legado

#Java #JPA #REST
Gustavo Damasceno
Gustavo Damasceno

No mês passado tive uma experiência enriquecedora como desenvolvedor Java para um importante banco comercial do Brasil. Gostaria de compartilhá-la pois representa uma situação que muitos "devs iniciantes", assim como eu deverão passar no futuro. Por razão de sigilo, nenhuma menção explícita será feita às partes envolvidas.

O objetivo era fazer um CRUD simples e uma transferência de cálculo que ocorria do Front-End(JSF) para uma arquitetura de microsserviços.

Os chefes das partes envolvidas, a contratante e a contratada, decidiram estipular "dailys" para fazer um acompanhamento "supostamente ágil" do processo. Para isso, uma tentativa de cronograma foi organizado a fim de que os mesmos pudessem se reportar também aos seus superiores. Com o CRUD não houve nenhum problema, pois o mapeamento e acesso ao Banco de Dados é uma coisa comum para o dia a dia do desenvolvedor. Porém, em relação à transposição do serviço de cálculo, pudemos perceber o quanto uma gestão de comunicação humana deve ser um quesito primordial para o sucesso de uma empresa.

Desde o momento inicial que ingressei no projeto, as informações estavam atravessadas. O projeto havia passado pela mão de dois desenvolvedores e nenhum tinha conseguido avançar com a entrega do mesmo. Ainda bem que houve comunicação com os colegas "devs operários" que mais experientes para conhecer melhor o "status" do projeto. Ao mesmo tempo, o que se viu na realidade foi um grande desencontro de informações em relação a um projeto que estava estagnado. Quando retirado da gaveta, é uma responsabilidade que cai nas mãos do "operário" vigente.


Teoricamente, calculei que o "job" não deveria levar menos de duas semanas, visto que eu já tinha feito um serviço REST e entendia basicamente de assincronia. O que aconteceu, na realidade, foi o aparecimento de obstáculos desafiadores.


Entre as cobranças dos chefes para se respeitar um "prazo", os próprios desenvolvedores da empresa contratante não tinham o "conhecimento" requerido para resolver o problema. O fato de contratarem uma terceira empresa expressou muito bem essa necessidade. Porém, percebi que além disso, era a hierarquia e a gestão da empresa que tornava dificultoso o desenvolvimento. Em diversos momentos, recebíamos alterações vindas de "cima" que nos obrigava a atualizar na "fábrica" o que estávamos escrevendo em termos de tipagem e até o compartilhamento de serviços por consumidores distintos. O cenário se configurava numa organização hierárquica, com prazos e chefes, arquitetos e engenheiros estipulando o que os "operários" deveriam implementar, com poucas oportunidades de comunicação com o que vinha de cima.


No meu caso, a transposição deveria passar por um serviço REST, recebendo uma entrada Json e enviado para uma Fila(MQ) que finalmente deveria retornar a resposta do cálculo para o usuário. Até aí sem problemas... somente enquanto falamos em "teoria". É na hora da implementação que o nosso "valor" é medido. Vamos ao caso:


O fato de haver uma fila(consumida por todos os "subscribers") para processar os cálculos, impossibilitava a "sincronia" de resposta da requisição feita inicialmente pelo usuário. Na arquitetura da empresa, a ideia inicial seria usar o "bean" @MessageDrivenBean que funciona com o "Publish/Subscribe Pattern". Porém, descobriu-se que era praticamente impossível enviar esse cálculo diretamente para o requerente sem pensarmos em questões de paralelismo (requisições de outros "users" sendo feitas ao mesmo tempo), tempo de processamento da fila, e o garantia do fluxo de conexões HTTP, JPA e JSF(cujo servidor é conteinerizado). Em suma, um cenário de feira em que todo mundo quer ofertar e receber produtos sem nenhuma organização.


Quando recebi uma planta do projeto idealizado, e isso só ocorreu decorrido um mês, percebi que o meu estresse emocional e a comunicação desencontrada não era somente de minha responsabilidade mas também da equipe. Finalmente, recorri à uma reunião para verificar com os próprios engenheiros se poderíamos validar essa ideia. Obtivemos pouca ou nenhuma resposta dos planejadores (parece a questão da hierarquia funcionava como um "escudo" para o acesso a esses profissionais, ao mesmo tempo em que alegavam falta de tempo). Ao frigir dos ovos, depois de falar com 3 ou 4 profissionais sêniores, decidimos recorrer a uma Prova de Conceito (PoC).

Então, já fatigados pelo insucesso de implementação daquela ideia inicial, resolvemos recorrer à mais simples das funcionalidades: gravar o dados saídos da fila no BD e fazer o controle da aplicação acessá-la diretamente depois de decorrido um certo tempo. Ou seja, torná-la novamente síncrono. Defendida essa PoC com sucesso, outros obstáculos ainda se interpuseram: requisição mal-sucedida de http no REST, JPA adormecido, erro de gravação no BD, HTML desatualizado, etc. Por fim, consegui contornar alguns desses problemas de conexão e time-out com com a classe CompletableFuture - com recurso de outras threads - para forçar o fluxo da mensagem.


Conclusão. Não conseguimos implementar a "ideia" original que pretendia usar os microsserviços sem o BD. Com essa experiência percebi que não obstante o grau de conhecimento dos vários níveis de desenvolvedores, somos nós "operários" que estamos à frente do código e que temos de tomar as melhores decisões. Nosso estudo e esforço de comunicação são apenas variáveis para tomarmos decisões.


Nem sempre o que vem de cima pode ser feito. Uma obra de Oscar Niemeyer, por exemplo, depende tanto da sua ideia quanto das tecnologias disponíveis para ser implementada. Fazer o "concreto" desafiar a lei da gravidade depende acima de tudo dos "operários" que colocarão um tijolo acima do outro, com ou sem método "ágil". ;)

0
15

Comentários (2)

0
Gustavo Damasceno

Gustavo Damasceno

20/05/2021 17:31

Eu acho que sempre dependerá de como chegamos naquele círculo de indivíduos.

Saber observar e escutar primeiro, para aos poucos adquirir uma autonomia certamente.

Obrigado pela resposta. Sucesso igualmente.

0
Alfeu Junior

Alfeu Junior

19/05/2021 17:05

Obrigado pelo relato, Gustavo!


Eu que estou apenas começando a minha jornada na programação e em Java sempre me pergunto constantemente como são tomadas as decisões em equipe ao se deparar com um problema. O bom é saber que se tem autonomia para propor algo diferente com o intuito de se resolver o problema. Sucesso!

Biografia