Tecnobank - Herdar um app que não compilava
Estabilização e evolução de um aplicativo iOS e Android recebido de outro fornecedor, com os dois projetos parados antes da primeira linha de código nova.
A tarefa parecia pequena
A Tecnobank trabalha com dados para o mercado de financiamento de veículos. O pedido foi objetivo: acrescentar a consulta de cobranças ao aplicativo que já existia, e ajustar o design para a versão definitiva.
O aplicativo vinha de outro fornecedor, com iOS em Swift e Android em Kotlin. O trabalho seria de evolução, não de construção.
O que a primeira semana revelou
Nada disso era possível sem antes resolver o que estava embaixo.
- O código-fonte não chegou no início do projeto e, quando chegou, os arquivos estavam corrompidos e não abriam. O projeto iOS não compilava. Eram mais de oitenta erros antes de qualquer alteração. O projeto trazia duas ferramentas de dependência ao mesmo tempo, CocoaPods e Carthage, duplicando frameworks sem justificativa técnica identificável. A versão de ambiente indicada pelo cliente não era compatível com o que o código exigia na prática. O Android em Kotlin dificultava a leitura por uma equipe que precisava produzir rápido sobre base desconhecida.
Um aplicativo herdado que não compila não é um detalhe de setup. É o projeto inteiro parado antes de começar.
Destravar primeiro, entregar depois
A ordem de ataque foi ditada pelo que bloqueava.
Android primeiro. Era o caminho mais curto até um build rodando. Os erros de compilação foram corrigidos logo nos primeiros dias, e a partir daí existia uma base sobre a qual mostrar resultado ao cliente.
Depois o iOS. A limpeza da árvore de dependências foi o trabalho central: atualização e correção item a item dos pacotes, e remoção da segunda ferramenta de dependência que duplicava frameworks. Com a árvore limpa, o projeto voltou a compilar e pôde ser atualizado para a versão de linguagem que as bibliotecas exigiam.
Os defeitos herdados. Com o build de pé, apareceram os problemas de uso. O aplicativo quebrava ao tocar nas linhas da tabela de contrato, e a correção exigiu atualizar manualmente o componente de abas, incluindo o recurso de célula que faltava no pacote. O botão flutuante da tela inicial também não se comportava, e teve o controle de exibição ajustado.
A funcionalidade contratada
Com a base estabilizada, a consulta de cobranças entrou onde deveria: no perfil de instituição financeira, acessível pelo botão flutuante da tela inicial.
A tela lista as últimas cobranças com mês de referência, vencimento, data de pagamento, valor do boleto e situação. Foi implementada no Android e distribuída para homologação do cliente ainda durante o ciclo.
Em paralelo correu a frente de design. O protótipo cobriu o aplicativo inteiro, e não apenas a tela nova: login, menu inicial, consulta de registro, validação de certidão, fatura e cobrança, registro de contrato e os acessos de despachante e cidadão.
O registro de contrato trouxe a complexidade real do domínio: o layout de campos muda por estado, e o levantamento cobriu sete unidades da federação, cada uma com o seu conjunto.
O protótipo passou por rodadas sucessivas de validação com o cliente, com ajustes de conexão entre telas entre uma rodada e outra.
O diagnóstico que virou recomendação
Ao longo do trabalho ficou claro que os problemas do código herdado não se esgotavam no que bloqueava a entrega contratada. O que apareceu foi sintoma de uma base que nunca tinha sido auditada.
A X-Apps registrou isso formalmente e propôs ao cliente uma análise estrutural do software, para mapear os erros da base antes de investir em funcionalidade nova. Também apresentou o caminho alternativo: reescrever o aplicativo do zero, com estimativa comparando duas tecnologias multiplataforma.
Apontar o que está por baixo faz parte do trabalho, mesmo quando o escopo contratado é outro. O cliente decide o que fazer com a informação, mas precisa tê-la.
Stack e práticas
- iOS em Swift e Android em Kotlin, ambos herdados de fornecedor anterior. CocoaPods para dependências no iOS, com remoção do Carthage que duplicava frameworks. Atualização manual de componente de interface de abas, com inclusão do recurso de célula ausente. Adobe XD para protótipo de baixa e de alta fidelidade, com link de visualização para o cliente. Distribuição de builds de homologação a cada avanço. Testes dos endpoints do cliente com coleção de requisições, para separar o que era erro de aplicativo do que era erro de serviço. Reuniões de validação de protótipo com a área de negócio do cliente.
Recebeu um aplicativo de outro fornecedor?
Código herdado costuma vir sem documentação, sem histórico e sem garantia de que compila. A primeira entrega de valor, nesses casos, é o diagnóstico honesto do que existe. A X-Apps assume a base, destrava o build e diz o que encontrou.