Quais problemas surgem ao aumentar a equipe móvel em 10 vezes? Por que razões, na mesma empresa, os desenvolvedores do Android preferem usar bibliotecas conhecidas e, no iOS, costumam criar suas próprias soluções? Como é a vida dos desenvolvedores móveis na fintech?
O Center for Financial Technologies participou da nossa conferência Mobius e, nesse sentido, perguntamos a dois funcionários da CFT:
Kirill Zuev era responsável pelo iOS e
Mikhail Emelyanov era responsável pelo Android.
O texto ficou tão expandido que até criamos um índice para que fosse fácil ir para uma parte específica:
Sobre empresa
Grupo JUG.ru: Pergunta introdutória: conte-nos sobre a empresa e o que você faz pessoalmente nela.Kirill : É impossível dizer brevemente, pois as áreas de negócios da CFT são muito diversificadas. Mas tente os "grandes detalhes" sobre os produtos e serviços mais populares.
A CFT opera no mercado russo de fintech pela terceira década, e dizemos que o fizemos quando esse conceito não existia.
Hoje, a CFT está processando e produzindo software para um grande número de várias organizações financeiras, companhias de seguros, empresas estatais e varejo.
Este é o ecossistema Golden Crown, que inclui um conjunto de serviços nos formatos b2c e b2b: troca de moeda online, transferências em dinheiro e dinheiro online, pagamentos de empréstimos, programas de fidelidade, transporte e cartões sociais.
O centro de processamento "KartStandart": emissão e aquisição de cartões de sistemas de pagamento Mastercard, Visa e "Mir".
O Sistema Federal "Cidade" agrega várias dezenas de milhares de serviços diversos: do pagamento de jardins de infância e serviços públicos ao pagamento de impostos e à reposição de cartões de transporte.
Os serviços bancários on-line do Faktura.ru são usados por mais de 130 bancos. Os sistemas bancários automatizados da CFT são usados por organizações ainda mais diferentes.
A CFT emprega grandes divisões de P&D, ML e AI, que são integradas em quase todas as áreas da empresa. Temos uma poderosa equipe de segurança da informação. Em geral, são mais de 3.000 pessoas que estão ocupadas resolvendo tarefas da fintech nos últimos 26 anos.
Um dos produtos “jovens” da CFT baseia-se no serviço “Golden Crown - Money Transfers” (que já tem 16 anos) - é o “Money Transfers Online”, uma direção que lançamos em 2016. E hoje é uma locomotiva de desenvolvimento móvel na CFT: no total, 70 pessoas trabalham nela no iOS e no Android. E esse número continua a crescer, planejamos crescer para centenas até o final do ano.
Também existem instruções móveis nas divisões "Cartões pré-pagos" (eles estão desenvolvendo soluções para os cartões "Milho", "Beeline", "Kari" etc.), no Faktura.ru, o sistema "Cidade".
E Misha e eu estamos apenas na divisão "Transferências de dinheiro online", envolvida no desenvolvimento, expansão e introdução de equipes aos processos de desenvolvimento. Inicialmente, trabalhamos na Diretoria de "Cartões Pré-pagos", as equipes eram pequenas, de plataforma, e vivemos de acordo com os conceitos de 2014-2015.
Mikhail : Quando todos estão sentados no mesmo escritório, eles trabalham, se comunicam.
Kirill : Essas pequenas equipes quentes e de lâmpadas, para 10 a 15 pessoas, levando em consideração tudo - tanto os testes quanto o back-end. E agora temos novos desafios.
Michael : Sim, organizar o trabalho de 10 desenvolvedores é uma coisa, e 50 é outra. Isso inclui todos os processos para o desenvolvimento, dimensionamento da equipe, seu desenvolvimento profissional e o próprio projeto: se nossos engenheiros resolverem problemas técnicos, estaremos envolvidos no desenvolvimento da arquitetura do projeto. Estamos à procura de problemas que interfiram no dimensionamento deste projeto e tentamos resolvê-los de todas as maneiras.
Grupo JUG.ru: Voltaremos às questões de crescimento, mas por enquanto me diga o seguinte: como o desenvolvimento móvel em CFT é diferente de outras empresas e o que é semelhante? O que você precisa saber sobre isso para quem nunca trabalhou na fintech? Você já precisa de algum conhecimento especial na fase da entrevista?Kirill : Quando conversamos com candidatos provenientes de terceirização, eles desejam trabalhar em uma equipe de produtos, um desejo de estabilidade. Mas eles sempre têm preocupações: o fintech é uma espécie de pântano, estritamente regulamentado e cercado de segurança, no qual será desconfortável se engajar no autodesenvolvimento do ponto de vista do desenvolvedor.
Sempre dizemos que, no nosso caso, o desenvolvimento móvel é exatamente o mesmo que qualquer desenvolvimento de produto no mercado. Fintech não é uma palavra para descrever o modo de vida, mas simplesmente uma linha de trabalho, algo que enfrentamos todos os dias.
Esses são os mesmos clientes de banco móvel, vários pagamentos, serviços de pagamento sem contato e assim por diante. Mas isso não significa que você precise de habilidades ou conhecimentos especiais: qualquer desenvolvedor móvel legal pode começar a fazer fintech se estiver interessado.
Obviamente, precisamos de um conhecimento mínimo no nível primário: como é um cartão bancário, o que é uma conta bancária. Porém, se houver um conhecimento mais profundo, será mais fácil e rápido entender os desejos dos analistas. Existem desenvolvedores que querem entender não apenas "como fazer a tarefa", mas também "por que".
Também há especificidade própria, por exemplo, os requisitos do regulador representado pelo Banco Central. Mas, como regra, tudo isso é levado em consideração nos requisitos de negócios e basta lê-los, fazer as perguntas necessárias e tudo ficará claro.
Existem certos pontos do ponto de vista da segurança da informação, isso é compreensível: fintech é sobre segurança. Mas não posso dizer que os desenvolvedores de dispositivos móveis sejam a primeira linha de defesa. Ainda assim, os produtos fintech são projetados de forma a serem seguros no back-end e no armazenamento de dados.
Sim, acontece que um desenvolvedor vem de uma startup e começa a dizer que a API pode ser projetada melhor: eles dizem, aqui você pode fazer uma solicitação e nós fazemos três. Mas isso se deve ao fato de a API ser projetada de forma a não fornecer a totalidade das informações. E quando o desenvolvedor entende que esta é uma decisão de engenharia, e não um movimento estúpido da parte dos desenvolvedores, ele imediatamente aceita.
E do ponto de vista da segurança de aplicativos móveis, tivemos um relatório sobre o Mobius passado. Não descobrimos a América lá e não mostramos truques de hackers, mas mostramos uma lista de verificação que um desenvolvedor de aplicativos fintech deve seguir para não cometer erros tolos:
Não os comprometemos, porque há uma revisão de código e há recomendações da equipe de segurança que nos fizeram uma excelente lista de verificação. Indica onde a vulnerabilidade deve ser resolvida e por quem (do lado da inteligência de negócios, desenvolvedor de back-end, desenvolvedor móvel ou testador ) Todas essas áreas de responsabilidade são conhecidas por nós, apenas seguimos as regras.
É importante entender que não estamos apenas vendo latas chatas, mas tentando virar o rosto para os clientes, incluindo o lado tecnológico. Portanto, sempre buscamos inovações como pagamentos sem contato.
Nossos “bancos” iOS em 2018 ficaram em 4º e 5º lugares no
ranking da Markswebb na categoria
Banco diário.
Estamos tentando ser um aplicativo que "não tem vergonha de mostrar para a mãe", que pode ser usado por pessoas distantes de smartphones e por quem entende muito de tecnologia. Por que alguns bancos móveis são bem-sucedidos e outros não? Porque eles são feitos tecnologicamente, com animação, talvez até com algum tipo de referência cultural.
Michael : acrescentarei brevemente que estamos realmente focados nos clientes - pessoas que andam pelas ruas. Como realizamos operações com dinheiro, nos esforçamos para torná-las o mais utilizáveis possível e mais fácil para as pessoas.
Ao mesmo tempo, quando os funcionários vêm até nós, precisam entender o que realmente "fazer pelas pessoas" não é rabiscar "como eu vejo" de joelhos. Antes de trabalhar na CFT, fiz quase todo o design e fiz o UX sem um designer. Mas a empresa não trabalha assim para nós. Há todo um laboratório de UX com designers que realizam experimentos e existem grupos focais que testam hipóteses.
E quando uma pessoa chega até nós, ela deve entender que tudo será focado em facilitar o uso do produto pelo cliente, para não morrer ao preencher um formulário de 50 campos. O trabalho está focado nas necessidades do usuário final.
O segundo são os requisitos de qualidade do código. Temos requisitos realmente altos de qualidade, revisão, arquitetura limpa, aplicação dos princípios do SOLID em todas as camadas. É inaceitável sacrificarmos a qualidade por uma questão de tempo.
E isso é adjacente à tecnologia moderna, não há atraso por trás da indústria. Todos os produtos Android agora estão escritos em Kotlin e iOS no Swift. No Android, usamos Rx, Dagger, em alguns projetos de rotinas. Quando novos desenvolvedores chegam, solicitamos feedback regularmente para entender o que as pessoas gostam e não gostam. E não me lembro que os funcionários reclamaram que algo estava desatualizado e se ofereceram para mudar alguma coisa. Temos apenas tempo para lançar idéias, "vamos tentar o MVI em tal e tal módulo", e todo mundo começa a gerar.
Quando uma pessoa chega à nossa equipe, ela deve estar pronta para entender a pilha de tecnologias modernas e poder navegar nela. Congratulamo-nos com isso. Talvez isso seja até um paradoxo: uma pessoa vai para a tecnologia financeira, para o desenvolvimento bancário, esperando o conservadorismo, e precisa saber como Rx e Kotlin trabalham com todos os presentes. Parece-me que isso é uma característica única.
Crescimento da equipe móvel
Grupo JUG.ru: Você já disse que está resolvendo problemas que surgem com o crescimento da equipe. Existe um exemplo concreto?Michael : Por exemplo. Quando seis pessoas em uma equipe realizam uma revisão de solicitação pull, 3-4 pessoas em uma solicitação pull, elas passam com rapidez suficiente (especialmente se as pessoas estiverem no mesmo escritório). A situação muda drasticamente quando os funcionários trabalham em diferentes cidades e fusos horários, e a equipe cresce e células separadas aparecem dentro dela (equipes de desenvolvimento unidas por um líder de equipe).
Percebemos que, com um aumento orgânico no número de revisores, as solicitações de recebimento começaram a demorar até 5-6 dias. Isso foi um problema: não foi possível entregar os recursos ao negócio a tempo.
Também havia um problema com o fluxo git: se você fica sentado em um galho e vê por muito tempo, nesse momento a outra equipe também pode ver 2-4 recursos em outros galhos, e tudo isso é congelado nos galhos até as datas de lançamento, sentimos dor na forma de um conflito de mesclagem.
O segundo problema foi resolvido alterando o fluxo git. Eles começaram a aplicar a abordagem de desenvolvimento baseada em tronco, ou seja, despejando diretamente no ramo de desenvolvimento, os ramos de recursos abandonados. Porém, como é impossível derramar funcionalidade inoperante, isso interromperá o projeto e aplicamos a abordagem de alternância de recursos. E, assim, reduziu o prazo de emissão da funcionalidade para o ramo de lançamento em vários dias. Eu falei mais sobre isso no Twitter
@mobileunderhood .
Houve um problema com a revisão. Anteriormente, cerca de 4-5 pessoas participaram de nós, uma vez que a qualidade do código é importante para nós, temos princípios e abordagens bastante rígidos para a qualidade. Estávamos com medo de que, se reduzirmos o número de revisores, nossa qualidade se deteriorará. Nesse caso, para 50 desenvolvedores, por exemplo, 30 realizam análises de qualidade e o restante são desenvolvedores juniores ou intermediários que ainda não desenvolveram uma habilidade real.
Portanto, seguimos um caminho diferente e criamos a fórmula “1 líder + 1 desenvolvedor sênior + 1 qualquer desenvolvedor”. Inicialmente, usamos essa fórmula na estrutura das equipes: por exemplo, o desenvolvedor da equipe “A” emite uma solicitação de recebimento, faz uma revisão com o curador e algum desenvolvedor individual. Cerca de 20 solicitações pull aparecem em um dia e meio: se pela manhã fizermos uma revisão de todos, no meio do dia seguinte haverá cerca de 20 novas.
Mas encontramos outro problema. Se um desenvolvedor coloca constantemente a liderança e a liderança vizinha de outra equipe, as oportunidades ficam sobrecarregadas. Eles estão menos envolvidos no desenvolvimento e passam mais tempo revisando. Cerca de 20 solicitações pull são um trabalho sério, se você abordá-lo qualitativamente.
E fomos ainda mais longe. Eles deixaram três vagas para revisores, deixaram as mesmas funções (equipe técnica, desenvolvedor sênior e qualquer outra), mas não se incomodaram em que devessem ser pessoas da sua equipe. E agora temos solicitações de recebimento ocorrendo em um dia, no máximo uma vez e meia. Chega de histórias longas.
E tudo isso em combinação com a alternância de recursos: quando um desenvolvedor assume um recurso, ele em primeiro lugar faz uma sinalização de desativação no código para que ele seja iniciado a frio. E então começa o desenvolvimento. Tudo isso é verificado em um dia, independentemente da cidade em que a equipe esteja.
Uma história separada com fusos horários. Se fizermos uma solicitação pull em São Petersburgo, doaremos à noite, depois em Novosibirsk +4 horas, e enquanto tivermos outra noite, eles já assistirão a solicitações pull de manhã. Eles saem do trabalho - nós recebemos seus pedidos e assistimos. Acontece um fluxo contínuo constante, no qual os fusos horários funcionam à mão.
Kirill : Sim, voltando à pergunta sobre a empresa: além de termos mais de 3.000 funcionários, nossos centros de desenvolvimento estão localizados em três cidades (Tomsk, Novosibirsk e São Petersburgo) e equipes móveis são distribuídas entre elas. É um pouco complicado que haja um atraso de quatro horas, mas o dia útil total da empresa é estendido para 12 horas.
Michael : Os fusos horários ajudam mais do que apenas uma revisão. Nós formamos um único desenvolvimento Android, não existe algo que em cidades diferentes tudo seja separado. Nossas equipes são multifuncionais, mas unidas pelas características da plataforma, como comunidades. Existem padrões, princípios gerais e práticas aceitas, incluindo estilo de código e similares. E, portanto, se surgirem problemas repentinos que exijam uma correção ou outra ação urgente, posso assumir aqueles que agora têm horário de trabalho, mesmo que não tenham sido originalmente responsáveis por esse código. Pessoas de outras cidades podem ajudar enquanto dormimos e vice-versa.
Grupo JUG.ru: quando uma equipe cresce, nenhum desenvolvedor já pode conhecer toda a base de código ou é fácil esclarecer qualquer coisa de uma pessoa sentada nas proximidades. Nesse caso, provavelmente, outro desafio surge: manutenção de registros?Kirill: Aqui vale a pena dizer isso: quando planejamos o crescimento da equipe 10 vezes, percebemos que não lançaríamos 10 vezes mais recursos (ou mesmo 7 vezes). Com esse crescimento, apenas para manter o nível anterior de qualidade, são necessários esforços adicionais. E um dos exercícios para novos desenvolvedores foi escrever a documentação antes de começar a fazer algo.
Assim, em pouco tempo, abordamos os principais componentes do aplicativo na documentação. E eles começaram a deixar os Jones entrarem nesses componentes, porque com essa documentação já é possível pagar revisões e testes de código. Era um zoom de "escape atrasado".
Agora que um ano se passou, preparamos a base e agora trazemos aos desenvolvedores que vieram há um ano para o nível máximo de produtividade. Quanto mais avançamos, mais fácil se torna. Com base na documentação criada, construímos listas de verificação com a estrutura e a interação dos componentes, com nossa integração com os principais serviços, e agora tudo isso não causa pânico: “Eu vim aqui para programar e você tem uma empresa aqui”.
Michael : vou complementar o Cyril. Depois que a equipe teve mais de 30 funcionários, houve um período em que os líderes de equipe e os desenvolvedores seniores passaram muito tempo com um ou dois desenvolvedores supervisionados, porque eles transmitiam informações constantemente. Nós entendemos isso com antecedência e começamos a agir. Portanto, o Android alocou um espaço separado no Confluence e reuniu todos os princípios, práticas e convenções para o desenvolvimento não apenas neste projeto, mas também em outros.
Quando um funcionário chega a uma equipe, ele primeiro se senta e estuda como conduzimos o desenvolvimento, quais são as regras e práticas e qual arquitetura do projeto. Ele nem pega o código enquanto estuda. Em seguida, responde às perguntas de controle. Qualquer treinamento sem perguntas de segurança não é eficaz o suficiente.
Agora, fomos ainda mais longe e estamos criando o sistema de treinamento automatizado Galileo. Sua essência está em vários níveis de graduação da educação, desde os princípios de desenvolvimento e metodologias, desde princípios arquitetônicos até princípios das línguas Kotlin.
Após essa imersão, metade das perguntas é removida. O que o lead fez antes agora é automatizado. Quando o desenvolvedor vai diretamente para a produção, em uma semana ou duas, ele faz perguntas pontuais, o que não é um problema. E antes disso havia realmente um problema.
Acredito que, mesmo que o projeto seja para 10 pessoas, você ainda precisará documentar com antecedência. Não se debruça sobre esse assunto, mas estabeleça alguns princípios. Haverá um dimensionamento - e, de qualquer forma, quando um novo desenvolvedor chegar, a documentação remove várias perguntas e economiza muito tempo do curador.
Temos documentação da plataforma (para Android e iOS) e existem projetos (cenários de negócios e similares).
Kirill : Mudamos para algum crowdsourcing. Quando um recém-chegado chega, eles lhe dizem: "Veja, é isso que ler no primeiro dia, aqui no segundo". Lá, configurando, fornecendo vários acessos, ferramentas e assim por diante. E se uma pessoa se deparar com um problema, uma de suas tarefas é escrever o problema na mesma lista de verificação para o próximo recém-chegado. Essas coisas buscam objetivos diferentes ao mesmo tempo: também preparamos documentação para as próximas gerações e ensinamos ao iniciante o valor de documentar o que ele faz. E ele não tem medo do que escrever.
Particularmente zeloso começa imediatamente a desenhar diagramas UML, o que é incentivado. Quando alguém dá um bom exemplo, todos se envolvem. E não estamos derrotando ninguém, pois entendemos que é necessário tempo, e damos esse tempo.
Bibliotecas de terceiros contra o desenvolvimento interno
Grupo JUG.ru: Eu gostaria de falar um pouco mais sobre a "cozinha interna" no contexto do iOS e Android. Tanto quanto entendemos, você tem no iOS uma política de rejeitar soluções de terceiros, mas o Android inicialmente também tentou escrever tudo sozinho, mas depois o deixou. PorqueMichael : O Android tem sido historicamente assim. Em 2013, quando estávamos fazendo um banco móvel para o cartão Kukruza, quase não havia padrões para arquiteturas e bibliotecas no desenvolvimento do Android. Até o próprio Google não entendeu onde deveria desenvolver o Android. Iniciamos o desenvolvimento quando ainda não havia o Android 5, tínhamos o KitKat 4.4 como a versão máxima.
Como não existem bibliotecas, nós nos escrevemos. , , . : , HTTP-
Volley , API- Retrofit ( ). , . , . Dagger , , Retrofit, «», .
- , , , - . Volley . , , - .
, - . , , Rx , . , . . . , - .
, : «, , », : «- - , », .
, , , -. Kotlin, - 1.0 . , best practices . .
« » « », . , -. .
, : , - , , . , , , , , - . , . , -, .
: iOS, , . . - — , . - AFNetworking, — 40-50 ( ). .
Mobius (
): third-party . , , , , . , , .
— , SSL- , - , .
, , . , ReactiveCocoa, 4-5 . -, , -, , ? , Swift, .
, , , . Android Dagger , , Google. Apple - , . , Swift, , , Swift.
6 , 2011 . 6-8 : , ? , , — SnapKit ( ) , , — , -, . , , .
— . , , , , , , .
: iOS Swift. — , , , . UI-, , -.
Swift — , Objective-C , . , , , , , , …
3 « » VIPER -, : «, MVP, VIPER». MVP- - . , , .
Swift Kotlin
Grupo JUG.ru: Michael em @mobileunderhood escreveu "estamos deixando o Java completamente, estamos reescrevendo tudo no Kotlin". Normalmente, mesmo quando o novo código já está escrito no Kotlin, o Java existente é alterado muito lentamente e pode permanecer em produção por muitos outros anos. Por que você decidiu fazer isso de forma mais ativa? E você se livra do código Objective-C como ativamente no iOS?Michael : Eu sempre gostei de Java. Eu sempre a amei, até passei no certificado Oracle e ela estava bem comigo. Mas o desenvolvimento de Java no Android e o desenvolvimento de Java na empresa são duas coisas diferentes. E alguns anos atrás, quando o Kotlin estava apenas começando, o uso do Java em sua forma simples, sem bibliotecas, começou a se cansar. Construções longas, um pouco de açúcar sintático, aqui alguns colegas com C # também jogaram o que têm, mas não o fazemos, geralmente desmotivamos. Eu queria escrever um código que execute a lógica e gastar menos tempo escrevendo esse código, usar mais itens, é mais fácil entender e ler o código.
Então vieram coisas como Lombok. No começo, gostei e depois parei, porque é algum tipo de biblioteca adicional que permite simplificar o código, envolvê-lo em açúcar sintático, mas esse é apenas um plug-in, não o compilador Java. E a classe de dados Kotlin e a classe Java comum, com todas as propriedades e métodos de encapsulamento get / set, são coisas completamente diferentes.
E decidimos por um longo tempo pela primeira vez experimentar o Kotlin no nível de um projeto. Nós escrevemos, algumas coisas nos confundiram - bem, Kotlin e Kotlin, meio que tentamos, ok, existe um projeto, voltamos ao Java. Eles retornaram e, depois de algum tempo, percebi que não era mais possível desenvolver em Java. É isso, estou cansado dela, não posso mais vê-la.
Aparentemente, eu me acostumei a algumas coisas sintáticas, ao minimalismo do código. E no final, foi decidido que precisamos usar o Kotlin. É melhor percebido e lido. Alguns desenvolvedores foram contra, mas me parece que isso é uma questão de hábito. Prática introduzida: escreva novos projetos no Kotlin. E os projetos antigos permaneceram em Java. Mas quando ocorreu uma grande refatoração, copiamos tudo para Kotlin. Adquirimos experiência para fazer isso rapidamente. Isso não significa que convertemos os arquivos Java para o Kotlin com teclas de atalho e, em seguida, corrigimos esse código - nós mesmos o reescrevemos imediatamente no estilo do Kotlin.
Há literalmente dois projetos Java restantes, e a transição está acontecendo gradualmente também: novos módulos são escritos no Kotlin, novos testes no Kotlin e a lógica antiga em Java. Se a lógica mudar devido à refatoração, escrevemos no Kotlin. E um desses projetos está passando por muita refatoração no momento. Assim, colocamos a migração em andamento e, após dois anos com Java, permaneceu literalmente um projeto e meio.
Ninguém foi particularmente contra. Havia certo ceticismo de que “Kotlin é apenas hype”, é claro, mas nos ajudou muito quando o Google reconheceu oficialmente o Kotlin para o desenvolvimento do Android, para nós era apenas uma bomba. Não era mais necessário convencer os engenheiros: você está na onda de todos os desenvolvedores modernos ou fora deste mercado.
Kirill : E com Swift, a primeira reunião foi assim: eu precisava fazer uma pequena apresentação para uma de nossas conferências em Novosibirsk, e quando trouxe um pedaço de código para a tela no Objective-C, ficou claro que não podia ser lido em nenhum tamanho de tela. E então eu escrevi esse trecho de código para a apresentação no Swift, embora não houvesse uma única linha "rápida" no projeto.
Depois, testamos o Swift no projeto Golden Crown Transport Card, que escrevemos do zero. Corremos alguns momentos de linguagem por lá. Foi interessante o que estávamos fazendo de errado, um pouco começamos a trabalhar para criar nosso próprio guia de estilo. Do segundo Swift, também “passamos” para o terceiro, tomamos um gole de tristeza, que depois assombrou a todos.
E se você olhar para as solicitações pull que temos agora, 95% do código Swift está escrito lá. Não temos uma super tarefa de transferir todo o código disponível do Objective-C para o Swift a qualquer custo. No entanto, a participação do código Swift no aplicativo móvel Money Transfer é de 60 a 65%. Emitimos um “resumo rápido” no qual desenhamos um gráfico para arquivos Swift / Objective-C, linhas de código e dependendo do lançamento e data tudo é visível. Um compartilhamento de 65% não significa que copiamos 6 dos 10 arquivos - principalmente crescimento devido a novos arquivos.
Tentamos diferentes técnicas de transição, por exemplo, no banco móvel para o cartão Corn, fizemos uma transição unidirecional (ou seja, nosso código Swift é baseado no Objective-C, mas não transferimos as construções Swift de volta para o Objective-C). Não estamos arrastando a funcionalidade Swift para acelerar o processo de mudança para o Swift dessa maneira. Nesse caso, quando ele realmente fica instável e o código Objective-C exige todas as dependências do Swift, podemos dizer que é hora do componente mudar completamente para o Swift.
Como os produtos do serviço Golden Crown - Money Transfer são mais importantes que a velocidade de desenvolvimento do que simplesmente aumentar a participação da Swift, temos histórias bidirecionais. Eles podem parecer menos bonitos do ponto de vista dos adeptos do Swift, mas como essa abordagem dá ao produto a capacidade de se mover mais rapidamente.
Os desenvolvedores vieram sem o conhecimento do Swift, o idioma foi dominado em duas semanas e começou a funcionar. Às vezes, eles temem que tenhamos 60% de Swift, mas tudo bem, ainda não houve um caso em que um funcionário não foi capaz de dominá-lo. Existem histórias opostas - quando descobrem que temos 40% de Objective-C, eles começam a dizer que somos retrógrados e você precisa primeiro reescrever tudo no Swift e depois cortar recursos. Mas aqui tudo é individual e trabalhamos individualmente.
Existem projetos mistos, projetos mistos unidirecionais, existem projetos limpos no Swift, tentamos de tudo. Tudo funciona muito bem, não há bala de prata.
Grupo JUG.ru: Sobre Swift e Kotlin, eles dizem "porque são semelhantes, tornou-se conveniente para os desenvolvedores para Android e iOS olharem o código um do outro". Você tem desenvolvedores para plataformas diferentes olhando para o código um do outro ou não?Kirill : Lembro-me de histórias em que desenvolvedores de Android que escreveram em Java examinaram o código de desenvolvedores de iOS no Objective-C e vice-versa, quando escrevemos um dos componentes mais complexos do aplicativo móvel para o mapa de Corn - o famoso designer de formulários, Um exemplo de arquitetura de interface do usuário orientada a back-end. Há uma interação muito intensa com o back-end por meio de um determinado protocolo, e não fazer o mesmo foi simplesmente criminoso. Claro, nós espiamos.
E agora temos diferentes abordagens arquiteturais em aplicativos, os aplicativos são baseados em diferentes arquiteturas de interface do usuário. O máximo em que podemos espiar é a camada de negócios, e mesmo assim devemos procurar na direção das ferramentas de teste que permitem escrever em uma das linguagens de programação.
Os aplicativos, de fato, são um cliente para o serviço. Na maioria das vezes, responde à entrada do usuário e exibe dados do servidor. Em algum lugar para escrever algo completamente errado é bastante difícil. E nesse sentido, talvez, haja alguns exemplos.
Michael : Eu tenho exemplos. Como agora temos equipes multifuncionais, os desenvolvedores de iOS e Android quase simultaneamente executam a mesma funcionalidade de negócios em plataformas diferentes, analisando cada vez menos o código um do outro, porque não há nada para olhar e todo o desenvolvimento ocorre sem problemas.
Mas quando alguém segue em frente, ao mesmo tempo, percebe que parte da maioria dos chips é implementada, quando as dicas de negócios “olham como o Android é feito” e a análise ainda não está pronta, há momentos em que os desenvolvedores de ambos os lados pode aparecer e ver como é feito. E aqui realmente ajuda que Swift e Kotlin são muito semelhantes.
No mobileunderhood, compartilhei minha experiência que tive quando trabalhei em um projeto no qual não tínhamos uma equipe multifuncional, mas uma espécie de startup para pagar empréstimos. E eu gostava de olhar para o desenvolvimento do iOS, era interessante como eles resolvem certos problemas, talvez até joguem algo neles. E eles adoraram me jogar. E constantemente, por horas, ficamos na lousa e conversamos sobre como o polimorfismo puro parece no iOS e no Android, como cozinhá-lo.
Trata-se de discutir o que é abstração, de algum tipo de conceito formal, e tudo acontece bastante divertido, e começa com o código usual. Você olha e pensa: por que você fez isso, há muita sobrecarga? E eles me explicam que tudo é planejado e conscientemente vai em frente, para não gastar 2-3 dias procurando a melhor solução, se, por exemplo, esse código for alterado no sprint. Eu penso: pessoal esperto, precisamos fazer isso algumas vezes, e não pensar por cinco dias em algum tipo de arquitetura interna, sobre a qual mais tarde se revela que não é necessário.
Como resultado, muitas vezes eu aparecia e olhava o código Swift. Olhei para o Objective-C também, mas eu gosto mais do Swift. Embora não o tenha desenvolvido, não acho que haja dificuldades em escrever código. Os desenvolvedores do Android têm a mesma coisa.
Kirill : Em geral, não temos apenas uma equipe de plataforma, na qual dizemos a eles: "Você é o melhor porque a Apple deu essa ferramenta". Os funcionários do iOS e do Android interagem, participam do planejamento juntos e trabalham em questões com analistas de sistema.
E eles também agem juntos em relação aos desenvolvedores de back-end, se tentarem criar uma API não tão adequada. E nessa simbiose, eles podem espionar tudo no repositório, temos um sistema aberto e todos os desenvolvedores têm acesso ao repositório.
Na diretoria de "Cartões pré-pagos", tínhamos histórias quando os back-ends eram costurados e, em seguida, os desenvolvedores do Android configuravam o ambiente, o ambiente e filmavam algumas correções de bugs, apenas para ajudar.
Michael : Lembrei-me de um caso muito recente. Lá, para que o cliente fosse mais sutil para nós, o back-end precisava fazer mais trabalho, então nossos truques para dispositivos móveis se uniram e começaram a avançar com sua ideia geral. Todos se reuniram, discutiram como se sentiriam confortáveis em ambas as plataformas, foram aos desenvolvedores de back-end e anunciaram como se sentem mais confortáveis trabalhando e o que viola o conceito de thin client. Os defensores concordaram com eles.
Agora, se uma plataforma disser: "Faremos tudo", e a segunda recusar, dizendo que é difícil, elas forçariam a segunda a concordar e concordar de alguma forma. E então tudo aconteceu juntos. Portanto, sinergia, o desenvolvimento da equipe está funcionando. E os idiomas realmente ajudam nisso. Afinal, se Java e Objective-C são hemisférios completamente diferentes em termos de sintaxe e princípio, então Kotlin e Swift estão realmente muito mais próximos.
Cyril : A propósito, há exemplos em que os caras se tornaram comutadores, e até duplos, alternando entre plataformas. Houve quem mudou para o iOS, se familiarizou, "colocou as mãos nele" e voltou ao Android. E então ele saiu no DevOps. Nesse sentido, também estamos abertos, esses momentos são simplificados.
É ótimo que o pessoal queira desenvolvimento profissional, mesmo em planos diferentes. Damos oportunidades e eles mesmos escolhem o caminho que desejam desenvolver, e quase todos os nossos funcionários são motivados pelo produto, pelas tarefas em que trabalham, o que é muito legal.
Grupo JUG.ru: Última pergunta: e o desenvolvimento de plataforma cruzada?Kirill : Nossa empresa tem um produto em desenvolvimento para o sistema Federal City. É aí que o React Native é escolhido para implementação. E não sentimos ciúmes por isso, porque é sempre interessante conduzir um experimento e descobrir como ele terminará. Além disso, temos desenvolvedores de front-end que conhecem bem seus negócios e é interessante tentar algo novo e inserir novas plataformas.
Michael : Temos projetos no React Native, mas isso é um pouco errado, porque é feito por desenvolvedores de front-end, e os desenvolvedores de iOS e Android não se sobrepõem muito.
Quanto à plataforma cruzada, eu pessoalmente o vejo para equipes pequenas: quando há poucos recursos no iOS e Android, e o projeto precisa ser feito para ambas as plataformas, por que não? Temos recursos suficientes e, como os produtos são tecnologicamente sofisticados, podemos oferecer um desenvolvimento separado para iOS e Android.
Também aconteceu historicamente que, quando realizamos a maioria de nossos projetos, ainda não havia plataforma cruzada. Agora, naturalmente, pensaríamos em separar uma parte da lógica de negócios e da lógica abstrata em módulos gerais, porque ninguém gosta de fazer um trabalho. Mas, historicamente, não temos isso.
No entanto, isso não significa que sempre será assim. Temos muitas tarefas e projetos promissores da empresa, existem protótipos e, mais cedo ou mais tarde, tentaremos a Kotlin Multiplatform da JetBrains ou a Flutter, o que é mais interessante para nós.
A plataforma cruzada ainda não foi padronizada em uma forma industrial, na qual você pode utilizá-la e usá-la em uma empresa. A julgar pela comunicação com os desenvolvedores de plataforma cruzada e seus relatórios, agora existe uma constante “execução” e solução de problemas. Portanto, você pode pegar e arquivar um projeto, mas com mais freqüência será apenas uma luta contra um rake, e não acho que os recursos de negócios possam ser vistos com eficiência. Recentemente, o JetBrains foi questionado no relatório se é possível usar a versão multiplataforma do Kotlin na produção, e eles dizem que ela ainda está em uma forma experimental.
No outro extremo, há um Flutter, que decolou no ano passado, isso é realmente interessante, o Google não está investindo pouco nesse negócio. E eu sei que muitos fazem projetos de estimação no Flutter, que já são apresentados em lojas de aplicativos. E isso é mais interessante para nós. Ficamos um pouco cansados do Kotlin, com o Kotlin / Native temos que coletar muitos ancinhos, mas o Flutter with Dart é uma coisa completamente nova.
Adoramos tudo o que há de novo, portanto, definitivamente teremos desenvolvimento de plataforma cruzada. Não especificamente no aplicativo de transferência de dinheiro, mas em alguns pequenos aplicativos separados.
Grupo JUG.ru: Obrigado pelas respostas detalhadas!