Esse post não tem o intuito de falar de boas práticas, de abordar padrões, técnicas mirabolantes, ou nada disso. É sobre fazer concessões para obter um resultado, levando em conta recursos disponíveis como know how, equipe e principalmente tempo. Parece familiar? Ok, mas também não é e nem passa perto de ser uma sugestão para você fazer algo que mereça ser colocado em produção. Estou aqui para falar de Provas de Conceito, PoC’s ou do inglês Proof of Concept e como consegui entregar uma porcaria extremamente funcional que encantou clientes.

Mas você não tem vergonha de dizer, de antemão que é uma porcaria? Não. Todas as partes estavam cientes de que um projeto foi realizado em 6 dias úteis, ignorando dezenas de padrões arquiteturais, mas cumpriu seu objetivo com graciosidade. Apresentar um fluxo complexo de negócio, envolvendo uma app android, um dashboard web, contanto com recursos de geolocalização, envio de imagens, análise cognitiva, autenticação e profile, enfim, um projeto de baixa/média complexidade, mas com um prazo extremamente agressivo. Tudo começou numa sexta-feira da qual próxima segunda-feira era um feriado. O prazo original era a quinta-feira dessa semana, no entanto conseguimos adiar por mais uma semana. Isso nos deu ao todo 7 dias úteis, já que a primeira semana tinha apenas 4 dias, e na quinta-feira da semana seguinte apresentaria o projeto em outro estado, só tínhamos de terça a quarta.

Embora nós lá na Ebix tenhamos diversos produtos, nada do que foi sugerido para o cliente era exatamente algo que já tínhamos, então fomos obrigados a criar para a apresentação, do zero. Por diversos motivos não tínhamos como usar outro time, então fui obrigado a desenhar uma estratégia para atender essa loucura. Foi insano, tanto quanto divertido e proveitoso.

O fluxo de negócio era relativamente simples. Uma app web, gerava um incidente, este incidente aparecia no aplicativo, e o usuário do aplicativo tinha de atender esse incidente. Isso envolve geolocalização, identificação do endereço de destino, integração com mapa e outras coisas mais. Ao final do atendimento, esse usuário precisava tirar algumas fotos, que eram avaliadas com análise cognitiva, e quando não condiziam com o esperado, era sugerido que tirasse novas, mas sempre ficando a cargo do usuário decidir manter ou não. Ao final do processo, o chamado era concluído e então mais um item apareceria no dasboard web.

Eram integrações demais para uma simples prova de conceito, o que permite pouco mock, e essa era a maior complexidade, garantir que tudo isso funcionaria de forma integrada, com esse prazo. Provas de Conceito não vivem sem mock, mas esse caso era diferente, era necessário ter tudo integrado, por mais rústica que fosse a integração entre as partes. Era hora de fazer concessões.

A imagem ao lado apresenta exatamente a dinâmica de decisão: Precisava ser rápido e barato, então quem sairia comprometida nessa história era a qualidade. Mas onde sacrificar a qualidade sem dar um tiro no próprio pé?

Principais decisões

Banco de Dados

Nessa dinâmica, imaginei que em primeiro lugar, usássemos um banco NoSQL, e não serviria qualquer um. Precisava ser o MongoDB, pois além das collections de dados, usaria o GridFS para armazenar os arquivos das imagens tiradas no celular.

Dashboard – SPA

Um único dashboard, com diversos filtros, que tal um SPA. Bom, a intenção era essa, e ficou com a outra pessoa que compôs o time dessa pequena jornada.

API

Com base no que eu já havia feito com MongoDB e NodeJS, pensei em criar uma API que não fizesse processamento, apenas CRUD, seria uma interface web para o MongoDB, responsável por gravar, ler e consultar qualquer collection do MongoDB, dado os parâmetros, realizaria o necessário, inspirado no Firebase. Assim a lógica de insert estaria na app mobile, enquanto a lógica de query estaria no dashboard. O ganho: Um único deploy de API para toda a vida (curta) do projeto. Uma vez no ar, todos os envolvidos estavam prontos para conversar, pois o meio de integração entre ambos era o MongoDB, que agora tinha uma API de CRUD, bem eficaz.

Mobile APP

Quem me conhece sabe que não sei nada sobre desenvolvimento mobile, nunca fiz sequer um projeto antes desses, embora tenha feito API’s entregassem dados para apps, no entanto sempre deixei o desenvolvimento mobile de lado em função de outros assuntos. Na verdade, nunca foi minha prioridade e não queria perder o foco, já que é um mundo a parte. Bom, como estava sozinho nessa parte da jornada, precisava escolher algo que me soasse minimamente familiar e ReactNative, Java (Android) e Xamarim exigiriam um know how que não seria capaz de adquirir nesse pequeno espaço de tempo. Quando estivesse capaz de criar meu hello world, o prazo já teria acabado. Optei por Ionic, já baseado no Angular 4, um pouco mais burocrático que o AngularJS, mas com o passar do tempo, em 1 ou 2 dias já havia deixado de ser desconfortável, para ser interessante! S2 TypeScript!!!!

ALM

Bom, nada melhor que um GIT, com GitFlow, um Jenkins e containers!! Ah sim, tudo que estava na nuvem estava sob containers Docker. Sua praticidade é indiscutível! E o Jenkins, me ajudou a não me preocupar com build e deploy. Usei Continous Deployment para evitar interrupções no meu dia-a-dia, pois assim que qualquer commit chegasse na master uma nova versão era publicada. Isso economizou interrupções, já que tive de corrigir alguns bugs na API que entreguei.

Resultado

Tive a possibilidade de receber um escopo macro, e eu mesmo definir o micro escopo, de acordo com o que estava mais fácil e prático para implementar. Tive algumas poucas frustrações com o Ionic, mas em linhas gerais se saiu muito melhor do que eu imaginava, já que o hype negativo sobre mobile apps híbridas é algo monumental. O Jenkins e o processo de Integração Contínua e Continous Deployment ajudou bastante, pois na hora que adicionei novos containers como o restheart(vou falar dele no próximo parágrafo) sequer precisei me preocupar com o deploy, no próximo build ele simplesmente estava lá, esperando por novas conexões.

No fluxo de negócio, o usuário se logava na aplicação, cada usuário tinha sua fila de atendimento, e nesse atendimento ele visualizava o endereço para onde deveria ir, e um minimapa, contendo a localização atual e esse endereço. Uma rota (linha reta) apresentava uma visão de como seria o deslocamento.

Uma vez iniciado o atendimento, novos campos, dinâmicos, apresentavam um formulário para preenchimento, a maioria dos campos era destinado a fotos, das quais o usuário precisaria tirar fotos, estas por sua vez precisariam ser analisadas. Ao tirar as fotos, uma análise era feita para determinar se aquilo se tratava do que queríamos que ele tirasse foto. Uma vez ok, ele seguiria em frente, na medida que não estivesse ok, o usuário era avisado, com a sugestão para que ele tirasse outra foto, apenas uma sugestão.

Conclusões

Com essas escolhas o projeto foi entregue com sucesso no final da terça-feira, na quarta apenas validamos, refizemos testes, e na quinta, o grande dia, fui para São Paulo apresentar a solução e foi um sucesso.

A propósito, já no finalzinho do projeto encontrei um projeto chamado restheart que faz exatamente o que eu estava fazendo com minha API, e por isso já posso jogá-la fora, em breve o farei. O adicionei por volta da segunda-feira, como solução para integração com GridFS, o que me possibilitou realizar um único upload e a partir deste, enviar apenas uma URL para que o Computer Vision @ Cognitive Services pudesse analisar as imagens que o usuário estava fazendo upload.

Mas vale lembrar que as escolhas que fiz, não são factíveis de se fazer em cenários reais, de produção, onde qualidade é fundamental. Abaixo seguem algumas conclusões sobre as escolhas que fiz:

• Ionic é legal, mas não é nativo.
• Não ter uma API de negócio é um risco absurdo quando seu app possui alguma, mesmo que pequena, escala de distribuição, além do risco de segurança, inerente a se ter uma API burra.
• MongoDB: Sim, MongoDB é um excelente projeto e usaria nesse produto em produção. Não foi uma escolha pra PoC. E por favor, parem de achar que NoSQL não é confiável.

AVISO

Não usem esse post como métrica, PoC é PoC, um projeto desses leva pelo menos 8 vezes mais tempo para ser desenvolvido da forma certa.