Na vida de quase qualquer equipe de desenvolvimento, chega um momento em que a criação de nossa própria estrutura passa do status de "Que diabos devemos perder tempo?" para o status "Idéia legal!". Tivemos esse momento há cerca de dois meses, quando começamos a estragar o controle de voz das transferências usando o Siri no aplicativo móvel cliente do PSB Mobile, o PSB Mobile. Analisamos nossa experiência e, com base nisso, mostraremos como entender que chegou a hora das estruturas.
"De que estrutura, do que você está falando?"
Anteriormente, o cliente iOS do banco para indivíduos era desenvolvido em terceirização. Decidiu-se reescrever tudo do zero. Criamos um processo SCRUM com sprints de duas semanas, o trabalho começou a ferver - estávamos procurando e adicionando novos recursos, chips. Nesse estágio de pesquisas ativas, era difícil prever o que criaria raízes, o que não criaria. Planejar tudo 40 passos à frente não faz sentido. Ninguém pensou nos detalhes como a universalidade - crie sua própria estrutura, aloque partes do código em bibliotecas separadas para reutilização. A probabilidade de que isso não faria sentido era muito alta.
WWDC nos conectou
Por que o SCRUM é bom - geralmente entramos em contato com a empresa como cliente. Ao mesmo tempo, mudanças importantes começaram a ocorrer. Começamos a entender melhor o produto, tarefas de negócios, processos de negócios do banco em que o aplicativo está envolvido. E o mais importante, os negócios, por sua vez, começaram a considerar o desenvolvimento do aplicativo como um processo, começaram a entender melhor como trabalhamos, começaram a concordar conosco que existem tarefas importantes, cuja solução não produz um efeito momentâneo perceptível.
Ajudou-nos a conviver com os negócios ... da conferência da WWDC De alguma forma, nossos clientes comerciais assistiram aos anúncios de novas oportunidades da Apple e subiram no Apple Developer com curiosidade. Surpreendentemente, tudo ficou muito mais claro do que o esperado. Desde então, não apenas estamos envolvidos em tarefas de negócios, mas os negócios não têm mais medo da tecnologia: eles tentam ler as especificações em si, obtêm informações sobre os problemas, ajudam na análise e nos problemas de desenvolvimento. Eles começaram a perceber que era inútil esperar um aumento claro do produto a cada duas semanas - afinal, existem sprints de serviço, dos quais não há crescimento concreto. O entendimento mútuo chegou ao ponto em que concordamos em refatorar 20% do tempo de sprint.
A evolução das bicicletas
Com o crescimento do departamento de desenvolvimento, o preenchimento do aplicativo com novos recursos, o surgimento de várias equipes trabalhando simultaneamente em diferentes tarefas, novas nuances começaram a aparecer. Algumas das subtarefas das equipes poderiam ser semelhantes e imediatamente houve o desejo de não reinventar a roda, mas antes de tudo esclarecer se alguém tinha um código pronto.
Geralmente, não há reclamações sobre o código de nossos desenvolvedores, portanto ele pode ser usado repetidamente - e não apenas dentro da estrutura da metodologia usual de reutilização de código. Provavelmente, já nesta fase de nossas cabeças surgiu a idéia de separar algumas coisas em bibliotecas separadas para o bem comum. Porém, dentro da estrutura das tarefas existentes, não foi possível encontrar tempo para esses processos. Precisava de algum motivo, e logo os negócios o lançaram para nós.
Extensão de gatilho
Havia uma tarefa de dar suporte à interface de voz - para que você possa efetuar pagamentos a outros clientes do banco via Siri via número de telefone. Ele diz: "Transfere muito dinheiro para essa pessoa". E se essa pessoa é cliente do Promsvyazbank, o cartão da pessoa aparece na tela, o valor da transferência, a pergunta "enviar dinheiro?" e botão enviar. Uma função semelhante já existe em alguns aplicativos bancários, mas queríamos fazê-lo para que, por um lado, fosse seguro e, por outro, o cliente não precisasse entrar no aplicativo bancário.
Trabalhar com o Siri envolve escrever uma extensão separada e, quando começamos a planejar, percebemos que era hora de desenvolver nossas próprias estruturas. Em nosso projeto de aplicativo, uma camada de rede foi implementada e surgiu uma opção (na verdade não): escreva essa camada novamente ou coloque-a em um contêiner separado, disponível no aplicativo principal e em uma extensão separada.
No processo, surgiu uma subtarefa de arquitetura para remover parte do código em estruturas separadas. Havia quatro no total:
- Camada de rede (meio) - aqui está todo o trabalho com a rede, classes de modelo, serviços de API. Essa camada é gerada automaticamente.
- Entrar
- Utilitários - Utilitários e Ajudantes
- Armazenamento - Armazenamento Seguro
É claro que este não é o nosso know-how. Portanto, é costume fazer em tais situações, essa é a melhor prática de todos os desenvolvedores que se prezam. Mas é importante como chegamos a isso. Foi nesse momento que
três sinais principais se uniram para criar a estrutura:
- Desenvolvemos uma base de código suficiente
- Os negócios começaram a entender nossas (ou seja, suas) necessidades arquitetônicas.
- Surgiu uma tarefa adequada
Novos horizontes
Depois de perceber que tudo acabou sendo simples. Na próxima reunião de desenvolvedores, discutimos os detalhes, escolhemos a
vítima da pessoa responsável que estará envolvida na refatoração principal, alocamos tempo a ele - tempo integral para esta tarefa. O resto dos desenvolvedores quase não afetou. Mas quando começamos a colocar a camada de rede na estrutura, surgiram imediatamente idéias de que outras partes do código usadas com freqüência deveriam ser colocadas na biblioteca. Nossas possibilidades arquitetônicas se expandiram subitamente. Começamos a vida com um grau adicional de liberdade.
Mas nós o usamos sem fanatismo. Para decidir se codificará o código em um módulo separado ou não, examinamos os registros em atraso e determinamos se esse módulo será reutilizado em vários locais. Caso contrário, não se preocupe.
Vemos os benefícios de usar nossas estruturas? Definitivamente sim. Agora, vemos quais partes do código necessárias como parte da nova tarefa já estão no repositório. O desenvolvimento de novos serviços é mais rápido, menos erros de programação, a qualidade dos serviços finais é maior.
Se você precisar de novas extensões para iOS, já temos as estruturas necessárias, você pode experimentar imediatamente. Quanto ao serviço já implementado com o Siri, ele está disponível para usuários bancários há mais de um mês - agora estamos coletando análises, inclusive para entender como e para o que mais usar a interface de voz.
Um pouco de futurologia
A história com a Siri nos fez pensar não apenas em estruturas, mas em interfaces em geral. A humanidade ainda não aprendeu a medir a concentração da atenção, apenas de alguma maneira indiretamente. Por exemplo, quanto pior o UX e a interface do usuário, maior o desperdício de atenção, mais o funil de conversão diminui a cada etapa. Uma transferência de dinheiro regular por meio de um aplicativo bancário requer várias ações do usuário: abra o aplicativo, faça login, pesquise em uma lista e, na segunda, insira o destinatário. Com o Siri, este é um desbloqueio mais um comando de voz. A autorização ocorre em primeiro plano através do Face ID. E em alguns cenários, você nem precisa trazer o telefone para você. Por exemplo, quando você está dirigindo e o telefone está montado próximo, a câmera pode reconhecê-lo facilmente.
Olhe ao seu redor: os assistentes de voz estão começando a conquistar ativamente o espaço circundante. O hype em torno do alto-falante inteligente Yandex, as máquinas de lavar roupa que falam e entendem os pedidos, os controles remotos de TV que reconhecem a voz. Quanto mais os usuários estiverem cercados por interfaces de voz, mais estarão prontos para se comunicar com os aplicativos bancários.
As interfaces gráficas nessa situação perderão seu monopólio, dos principais meios de comunicação, elas simplesmente se transformarão em uma confirmação visual da ação, em uma maneira de sinalizar que o computador o entendeu corretamente.
Para o desenvolvedor, essa mudança, em princípio, não é assustadora. Com a arquitetura certa, o aplicativo pode ter qualquer número de interfaces: visual, voz, neuro. O principal é usar abordagens que correspondam ao nível atual de maturidade da equipe.