Em 2018, quando é possível pagar até mesmo um shawarma usando o Android Pay, um smartphone é a principal ferramenta financeira para o usuário. Agora, as pessoas querem resolver com a ajuda dele em geral todos os problemas relacionados ao dinheiro. Portanto, os aplicativos móveis correspondentes se tornaram especialmente relevantes.
Para aplicativos financeiros desenvolvidos pela CFT para vários clientes, o número total de instalações é de milhões - ou seja, poucos podem se orgulhar dessa experiência nessa área. Aproveitando o fato de a empresa estar presente em nossa conferência Mobius, perguntamos ao chefe do grupo de desenvolvimento de aplicativos Android
Mikhail Emelyanov várias perguntas sobre como é o desenvolvimento do Android na CFT.
- Primeiro, conte-nos brevemente sobre "CFT" para aqueles que nunca ouviram esse nome antes.- A empresa atua no mercado de fintech há mais de 25 anos: quando apareceu, não havia sequer um conceito de fintech, mas, mesmo assim, produzia produtos e serviços que hoje são chamados dessa maneira. Na verdade, o próprio nome "Center for Financial Technologies", que apareceu no início dos anos 90, ainda permanece relevante e fala por si.
É claro que muita coisa mudou nos últimos tempos (quem poderia imaginar o Android em 1991?), Mas a essência permaneceu a mesma: a CFT desenvolve e desenvolve soluções de TI e serviços tecnológicos que tornam as transações financeiras simples e convenientes (incluindo transferências de dinheiro). e pagamentos).
A empresa apareceu no Novosibirsk Academgorodok e seu principal centro de desenvolvimento ainda está localizado lá. Mas agora, além dele, existem escritórios em muitas outras cidades da Rússia, bem como em Chisinau, Almaty e Dushanbe. O crescimento continua: novos serviços e unidades estão aparecendo constantemente, a direção de P&D está se desenvolvendo ativamente.
- E quantas pessoas estão envolvidas especificamente no desenvolvimento móvel, e você pode dar exemplos de aplicativos desenvolvidos na CFT?- Temos uma equipe móvel distribuída em Novosibirsk, Tomsk e São Petersburgo. Agora são mais de 50 pessoas, mas a empresa tem planos para o desenvolvimento móvel que precisamos crescer duas vezes mais rápido para combiná-los.
Nossos aplicativos mais populares para iOS e Android são
transferências de dinheiro (mais de 1,3 milhão de downloads no Google Play), escritórios de pagamento
Beeline e
Corn .
Além disso, nosso
provedor de serviços bancários on-line
, Faktura.ru, possui mais de 100 aplicativos móveis personalizados para iOS e Android. No total, a equipe do Faktura.ru implementou 340 projetos de banco on-line para clientes corporativos e privados. Em geral, cerca de 130 bancos operam nessa plataforma de tecnologia.
- O trabalho com finanças tem suas próprias especificidades - como o desenvolvimento do Android em CFT difere da empresa "média"?- Como trabalhamos com dados pessoais e finanças do usuário, uma das principais regras são os requisitos estritos para a proteção das informações. Lidamos regularmente com tópicos como segurança bancária móvel no nível da API e durante a transferência de dados, autenticação biométrica, chaveiro, fixação de SSL etc. Acumulamos muita experiência relevante, por isso a Mobius acabou de
apresentar o relatório "Fundamentos da segurança de aplicativos móveis".
Mas, ao mesmo tempo, o desenvolvimento móvel na fintech não se transforma em uma conformidade contínua com os requisitos de segurança, divorciados dos desejos das pessoas vivas. Os usuários finais ainda são milhões de cidadãos comuns. Agora todo mundo controla as operações de dinheiro de um smartphone - elas pagam pelos serviços, transferem dinheiro. E nossos produtos finais são direcionados especificamente para essas pessoas.
Portanto, na fintech, é bastante interessante envolver-se apenas no desenvolvimento móvel: os usuários finais estão, de fato, com você. Portanto, os aplicativos não devem ser apenas seguros, mas também simples, o mais tecnológicos possível. Não estamos criando algo no vácuo, mas um produto para o consumidor.
- Além de proteger as informações, você também precisa ser especialmente estável: se uma startup pode obter erros na produção, ela espera confiabilidade das finanças. Mas, ao mesmo tempo, transformar-se em uma “cachoeira” lenta e coordenar tudo por meio ano também é impossível. Como você resolve esse problema?- Primeiro de tudo, com uma abordagem arquitetônica. Nós adotamos a idéia de arquitetura limpa como padrão e seus princípios estão sendo desenvolvidos em aplicativos reais. Criamos novas aplicações no âmbito da divisão em camadas, responsabilidade única e entidades pouco conectadas.
Lucro: o uso de várias tecnologias sem a necessidade de reescrever todo o código, de alta qualidade através de testes e, o mais importante - escalabilidade simples, o que é muito importante para nós.
Também temos a revisão de código mais rigorosa, quase toda a equipe participa dela e detectamos a maioria dos momentos difíceis na fase de revisão, para que eles não atinjam a produção.
Bem, é claro, testando - em quase todos os lugares onde cobrimos testes de unidade, alguns desenvolvedores escrevem código usando a metodologia TDD. Obviamente, a interface do usuário não está no TDD, mas também não esquecemos o teste da interface do usuário: junto com uma equipe de testadores, trabalhamos para garantir que eles usem o Espresso da maneira mais eficiente possível.
- Como a fintech exige conservadorismo, em alguns casos isso pode interferir no uso de novas tecnologias. Portanto, é interessante perguntar o seguinte: que novidades você experimentou no Android no ano passado? E que tecnologias, a propósito, você usa?- Muitas tentativas. Quando o Google lançou a versão do Android Architecture Component, decidimos experimentá-lo e implementá-lo em um dos novos projetos. Mas tivemos um problema: por exemplo, não vimos em seu ViewModel um meio suficientemente eficaz para resolver o problema do ciclo de vida de nosso projeto. Mas o LiveData nos pareceu útil para a camada de apresentação.
Depois que o resultado da AAC não correspondeu às expectativas, nós o cortamos, substituindo-o por uma abordagem mais eficiente. Graças à arquitetura limpa, não é necessário refazer o aplicativo inteiro, basta refinar a camada de apresentação. Há outro exemplo usando a nova sala ORM.
Agora estamos desenvolvendo ativamente em Kotlin. Na Mobius, muitos se perguntaram "por que Kotlin está em toda parte", mas isso é implorado. Ele fornece mais recursos do que o Java pronto para uso: há muito menos código, mais funcionalidade. Muito pode ser feito com uma única linha de código, como declarar classes. Agora também estamos tentando corotinas em um dos projetos.
Em geral, gostamos da maneira como o Kotlin se desenvolve e está satisfeito por sua comunidade estar crescendo. E desde que se tornou tão difundido, agora, para não desenvolvê-lo, é preciso ter crenças e princípios muito fortes.
Também usamos RxJava / RxKotlin, popular Retrofit e Dagger 2, o Data Binding do Google, planejamos experimentar o RxBinding, por um longo tempo tudo pode ser listado. Em geral, a fintech não interfere no jogo completo com várias tecnologias.
- Os componentes da arquitetura Android não combinavam com você - mas você pode recomendá-los a outras pessoas? Quão intensiva foi a migração para eles: os projetos já existentes deveriam pensar sobre isso ou é melhor deixá-lo novo?“Embora o AAC não atenda às nossas expectativas, eles se saem bem em algumas tarefas: por exemplo, salvar e restaurar dados ao alterar a orientação da tela. Portanto, se em um projeto com um monte de suporte de código legado para alterar a orientação não for implementado de maneira ineficaz, pense em usar o AAC. Mas para implementá-lo de uma maneira infeliz não funciona, você primeiro precisa preparar a arquitetura, corrigir erros críticos e encontrar pontos de integração para não processar o aplicativo inteiro.
- A sala acima mencionada é uma tecnologia relativamente recente que muitos ainda não tiveram tempo de experimentar. Portanto, é interessante: qual foi sua experiência com ela?- Quarto nos agradou. Usando anotações, você pode descrever facilmente a criação de tabelas, definir transações, etc. Há suporte interno para Kotlin, Rx, LiveData. Um dos pontos negativos da versão estável atual (1.1.0) é a falta de comandos para limpar o banco de dados e a necessidade de configurar as comunicações manualmente. Ainda havia pequenas coisas desconfortáveis ao usar o Room in Kotlin, mas elas gradualmente decidiram com o lançamento de novas versões. Por exemplo, os métodos de transação padrão nas interfaces tornaram-se suportados apenas no 1.1.0-alpha2.
Em geral, com o Room, trabalhar com bancos de dados se tornou muito mais conveniente e eficiente.
- Existe um ponto de vista: "todas as suas ORMs são astutas, as abstrações ainda fluem e você precisa descer para o nível SQL" - o que você acha disso?- Em qualquer tecnologia, para resolver tarefas não triviais, você precisa escrever código, mesmo SQL. O principal é que isso não se transforme em sobrecarga. No Room, você também pode escrever consultas SQL manualmente (por exemplo, migração ou consultas complexas), mas por meio de anotações é muito mais conveniente fazer isso. Por exemplo, você pode extrair dados de várias tabelas usando Relação.
- Como a CFT é mais antiga que o Android, a questão do Legacy provavelmente é relevante para você. Você costuma refatorar?- Certamente, o código legado existirá em qualquer projeto. E a afirmação popular "qualquer código escrito hoje, amanhã se torna legado" é bastante verdadeira.
O mesmo acontece conosco. Existem aplicativos lançados há vários anos. Se houver razões objetivas para alterar o código inteiro (bugs, baixa escalabilidade, falta de tecnologias efetivas etc.), fazemos isso. Realizamos refatoração passo a passo; em paralelo, liberamos recursos em que o código é processado por componentes, camadas ou apenas telas.
Também no uso da tecnologia. Por exemplo, em um de nossos projetos, o Volley foi usado como um cliente http. A tecnologia não é nova e queríamos mudar para OkHttp + Retrofit. Para fazer isso, analisamos as conexões no projeto com o cliente restante, preparamos a arquitetura para a transição e a mudamos de uma só vez, sem gastar muito tempo nela.
- A CFT tem cursos, incluindo Android - e o que você ensina lá? E o que, na sua experiência, falta mais aos desenvolvedores iniciantes do Android?- Sim, existem vários projetos educacionais na CFT. Para estudantes juniores - SHIFT School, no âmbito do qual realizamos um curso de desenvolvimento básico do Android baseado no NSU. E para estudantes seniores e juniores - o projeto Focus Start, onde existem 6 cursos multidirecionais, incluindo desenvolvimento móvel (Android e iOS). O programa do curso Android fornece conhecimento aprofundado de Android, Java, Kotlin, Rx. Já lançamos vários sets, alguns dos melhores graduados se tornaram nossos funcionários.
Freqüentemente, os desenvolvedores iniciantes do Android não têm a experiência de usar OOP, o princípio do SOLID. Alguns não entendem a diferença entre os padrões MVC - MVP - MVVM e os princípios de Arquitetura Limpa, por isso eles entendem mal a lógica de negócios.
Também existem lacunas no Android SDK, Java, um entendimento do multithreading e como ele é implementado no Android. Bem, os básicos: entender Rx, Dagger, Retrofit. Muitos não tentam ler a documentação de várias tecnologias.
Mas nossa prática mostra que os intensivos treinamentos fecham as lacunas com rapidez e eficiência o suficiente para trabalhar em TI.
