Denis Neklyudov é interessante para desenvolvedores do Android por vários motivos. Ele está envolvido no Android Dev Podcast, fala em conferências, participa de cúpulas do GDE - em geral, está envolvido na vida da comunidade de várias maneiras. E como ele agora vive nos EUA e trabalha na Lyft, ele pode comparar a situação ocidental com a russa.
E na véspera do Mobius 2019 Piter, onde ele
fala sobre “arquitetura com foco em dimensionamento”, perguntamos um pouco sobre tudo isso. Como um podcast russo pode interessar os ouvintes ocidentais? Como é trabalhar onde centenas de desenvolvedores de dispositivos móveis contam? O que há de errado com as soluções do Google para desenvolvedores do Android? E o que há de errado em usar smartphones em geral?
Podcasts
- Você participa do Android Dev Podcast , e recentemente o Flutter Dev Podcast também apareceu - como isso aconteceu?- Inicialmente, eu era o troll Flutter mais importante. Aqueles que estiveram na cúpula do GDE não o deixarão mentir. Eu disse diretamente aos principais gerentes do Google: que tipo de arte é essa, como você pode colocá-la ao lado do nosso sério Android adulto?
Mas alguns meses depois que eu disse tudo isso, eles foram liberados, eu mesmo tentei de tudo com minhas próprias mãos, olhei o que você pode fazer sobre isso e percebi que isso não era um brinquedo.
A princípio, percebemos que havia algum tipo de máquina virtual, JavaScript. E, em seguida, verificou-se que tudo é compilado em código nativo e realmente funciona rápido nas duas plataformas. Ao mesmo tempo, o ajuste é velho o suficiente para uma plataforma experimental, ao que parece. E acabou que a linguagem Dart não é tão ruim. Sim, isso não é familiar para Kotlin, mas uma linguagem muito adulta e boa, com todos os encantos das linguagens de programação modernas.
Mudei de ideia e ficou claro que Flutter tinha perspectivas. Até o React Native, o Xamarin e outras estruturas de terceiros se espalharam, e aqui o Google oferece suporte e até rumores sobre o novo sistema operacional Fuchsia, onde Dart e Flutter serão usados em primeiro lugar.
Mas não cobriremos todas as notícias do Flutter no Android Dev Podcast. E então eu tive a ideia de que seria bom fazer um podcast separado. Voltei-me para o meu velho amigo da universidade, Zhenya Saturov, dizendo: “Você quer tomar a iniciativa? Não vou puxar o segundo podcast, mas você é mais jovem, talvez aceite. " E assim nasceu o Flutter Dev Podcast.
- Quando a mesma empresa do Google desenvolve o desenvolvimento nativo do Android e o Flutter, pode não estar claro para os desenvolvedores iniciantes "bem, para onde devo ir". Isso parece um problema para você?- Se os iniciantes não puderem decidir, vamos imediatamente para o desenvolvimento de jogos no Unity! Mas, falando sério, existe um efeito descrito, mas o Google está sentado em duas cadeiras há tanto tempo: web e nativo. Há coisas como os Aplicativos Web Progressivos que também estão sendo desenvolvidos no Google. Parece que existem plataformas nativas, por que você está movimentando seu PWA? E também existem iniciativas como o WebAssembly relacionadas à execução de tudo o que é possível no navegador (o Google era originalmente do mundo da web).
Portanto, o Google não é a primeira vez que cria empregos diferentes para diferentes categorias de solução do mesmo problema. Esse é um enorme colosso, onde por dentro existem diferentes pequenas empresas lutando entre si. Portanto, não é surpreendente que exista concorrência dentro de uma corporação.
- Continuando o tema dos podcasts: a empresa Lyft, onde você trabalha, este ano tem seu próprio podcast sobre desenvolvimento móvel. Você tem algo a ver com isso?- Eles começaram antes da minha chegada: quando a empresa faz um podcast, não é "gravado, definido", mas um longo processo de concordar sobre o que você pode falar e sobre o que não pode falar. Mas eles prometeram me convidar para um desses tópicos (eles não ligaram para o anfitrião).
Existem muitos podcasts sobre desenvolvimento móvel - recentemente apareceu
outra língua russa. Penso que quanto mais houver, melhor: a qualidade de quem quer estar no topo é maior. Mas está claro que os ouvintes precisam consumir mais e mais materiais. É o mesmo com mitaps, conferências, plataformas para relatórios.
- Também há um podcast The Context com Artyom Zinnatullin , e como você agora está trabalhando com ele na mesma empresa, a questão é: você deseja unir forças.- Até onde eu sei, a Artyom já perdeu algumas edições do The Context devido ao alto emprego no trabalho. Mas ele também chega com alegria no Android Dev Podcast, tudo depende dos tópicos. Artyom não edita edições, mas vem com opinião de especialistas. E eu geralmente gosto de editar, e aqui fazemos coisas completamente diferentes.
- Quando você está envolvido em podcasts no idioma russo enquanto mora no exterior, parece duas vidas paralelas, nas quais seu podcast não é escutado no trabalho, e no podcast você sabe algo sobre seu trabalho apenas com suas palavras?- Em Cingapura, isso não foi sentido, mas nos EUA é realmente sentido que esses são dois mundos diferentes. Na Rússia, eles me conhecem, meu nome já tem algum peso. Ninguém me conhece nos EUA e, em resposta às palavras "eu tenho um podcast", perguntam por que não o ouviram. Porque ele está em russo. Aqui, é claro, eu perco.
Portanto, minha iniciativa pessoal é fazer lançamentos em inglês do podcast, falar mais em inglês para expandir o público. O que estamos discutindo na Rússia é igualmente relevante no Ocidente: existem muitos nichos não preenchidos. Parece-me que seria bom abordar os tópicos que abordamos no podcast aqui.
- os ouvintes que falam inglês já têm podcasts como Fragmented - o que você acha que o Android Dev Podcast pode oferecer e quais eles não têm?- Eu sempre quis acreditar que estamos mais perto do ouvinte. Não tentamos ser objetivos, e muitas vezes nossa opinião pessoal permanece a opinião pessoal expressa em público. Mas, ao mesmo tempo, essa opinião tem uma grande experiência por trás de nós, e não sentimos vergonha em nossas declarações.
Talvez no Ocidente isso não aconteça, o Fragmented é um podcast mais refinado, onde há pouco conhecimento, detalhes e dificuldades em profundidade (que muitos simplesmente não entendem). Em busca de um alto número de audições para um público amplo, alguns podcasts removem tópicos complexos para discussão.
- Falando não sobre podcasts, mas sobre o desenvolvimento do Android, você sente uma diferença notável entre os EUA e a Rússia?Eu acho que sim. Ainda não estou pronto para julgar rigorosamente, mas o sentimento principal (não tão difícil quanto em Cingapura) é que todos estão muito fracamente interessados em sua profissão e suas habilidades. Aqui, quando a empresa tem muitos desenvolvedores na mesma plataforma, as pessoas apenas se sentam e executam suas tarefas, para eles o Android não é sua vida, sua paixão, seu hobby, mas simplesmente uma lista de tarefas que devem ser implementadas.
Grande escala no desenvolvimento móvel
- Você trabalha em uma empresa onde existem mais de cem desenvolvedores de dispositivos móveis. Eles constantemente fazem a pergunta "Você tem um aplicativo em uma tela, o que essa multidão deve fazer lá?"- Eu mesmo inicialmente perguntei sobre isso. A resposta vem quando você fica por dentro de tudo isso.
Em primeiro lugar, não podemos dizer que temos um aplicativo de tela única. Para começar, existem duas aplicações (motorista e passageiro) e, se falarmos sobre a experiência do passageiro, temos uma aplicação com carros, scooters, bicicletas, carros autônomos e com chips diferentes para diferentes regiões (pagamento e usuário) .
E segundo, muitas dificuldades vêm com escala. Há muito trabalho relacionado ao pensamento através de métricas, criação de experimentos, acompanhamento do andamento de seu trabalho anterior. A escala na forma de milhões de usuários afeta o tempo de desenvolvimento, agora entendo isso melhor.
Estamos divididos em pequenos subcomandos multifuncionais, nos quais todos são responsáveis por uma seção. Alguém é responsável pela viagem, alguém por bicicletas e scooters, e é assim que se formam duas dúzias de equipes diferentes, nas quais existem dois ou três desenvolvedores. Sou responsável pela parte relacionada à identificação do usuário. E eu gostaria que outro colega aparecesse para esta parte, aumentando nosso contador total.
Se falamos sobre os desenvolvedores de aplicativos pequenos, que estão cheios entre nossos leitores, acontece que simplesmente consistimos em uma dúzia de aplicativos pequenos em um grande.
A situação é semelhante em muitos aplicativos grandes. E a divisão em equipes de recursos e desenvolvimento orientado por métricas, onde as métricas conduzem tudo e a abordagem de inicialização, quando criamos o MVP e depois o colocamos em bom estado: para alguns, é na forma de todo o produto e para alguém na forma de um recurso interno. Até o Google coloca suas pequenas equipes de maneira que elas sejam como uma startup e tenta minimizar a burocracia e os longos ciclos de desenvolvimento.
- E como é o trabalho de um funcionário em particular em tal situação? Você pode falar sobre algumas das suas tarefas volumosas?- Levei dois meses para criar um perfil de usuário, embora não seja difícil por si só. A tela em si é nova, anteriormente o usuário não tinha um perfil, havia apenas configurações. Além do fato de que era necessário refazer o acabamento, verificou-se que, do ponto de vista arquitetônico, alguns componentes não eram suficientes, levou-me para entrar na arquitetura, para ajudar os caras.
Eu também decidi experimentar Dagger, também levou tempo. Também era necessário pensar nas métricas, construir um painel, coletar análises do sucesso do experimento, isso levou tempo. Então comecei a adicionar telas existentes das configurações nas telas internas do perfil e atualizar.
A atualização de acordo com a “regra do escoteiro” exigia refatorar o que foi tocado. A refatoração para a arquitetura mais recente também levou algum tempo. Além disso, temos um sistema de design e alguns componentes não são implementados a partir dos últimos elementos aprovados. O que esperar da equipe que escreve esses elementos, peguei e os ajudei a copiar seu trabalho para eles, para não serem bloqueados.
Fora tudo isso, dois meses de trabalho se formaram, o que à primeira vista pareceu duas semanas.
- Quando você deseja "experimentar o Dagger" durante a tarefa, esses experimentos são incentivados?- Depende do nível do engenheiro. Acho que se ele é um engenheiro de nível básico, ele e o gerente entendem claramente que não se distraem com nenhum experimento de arquitetura, porque ele próprio ainda é verde por isso.
E de engenheiros experientes, é responsabilidade direta deles contribuir para algo amplo: em toda a organização ou pelo menos em toda a aplicação. Portanto, não há para onde ir: mesmo que não seja muito interessante se engajar na arquitetura, mas deseje desenvolver, você precisa conectar sua vida a algo mais do que apenas recursos.
- E se você experimentou e o resultado foi bem-sucedido, torna-se uma política geral ou pode permanecer dentro da equipe?- Muito raramente, permanece dentro de uma equipe. Geralmente, se alguém inicia um experimento, isso é imediatamente consistente com a equipe de arquitetura principal e, posteriormente, é considerado uma boa prática geral. Por exemplo, agora duas equipes estão experimentando o Redux em paralelo para entender qual de nós vencerá, cuja solução será mais universal e começaremos a usá-lo em toda a empresa.
- O aumento no número de pessoas em uma equipe também é o crescimento do "trabalho de papel" quando você não codifica, mas faz algo relacionado. Está claro que isso é necessário, mas quanto isso diminui a velocidade do desenvolvedor em comparação a como, em um pequeno projeto, ele “apenas apresentava”?- Mais uma vez depende do nível de engenheiro. Se o engenheiro é médio ou iniciante, então não há necessidade de escrever muitos documentos, ele senta e descobre os recursos sob a supervisão de seu engenheiro sênior. Mas o engenheiro sênior já está assumindo responsabilidades gerenciais, como em qualquer outra empresa. Ele não consegue conversar com o chefe se for uma startup ou escrever documentos para o gerente, se for uma empresa grande.
- Quando você cria um aplicativo Android para um táxi, os problemas e os problemas atuais são os mesmos de outros aplicativos grandes ou você tem suas próprias especificidades?- Os problemas que enfrentamos são muito semelhantes. Por exemplo, o problema da montagem de vários módulos adiciona aos engenheiros de infraestrutura as mesmas preocupações todos os dias, por isso não é surpreendente que Uber, Facebook, Airbnb e Lyft usem o mesmo sistema de construção Buck.
Outros também olham para ele, atingindo nossa escala, e isso confirma que os problemas são os mesmos. Paralelamente, ocorrem os mesmos processos - por exemplo, todos se tornam reativos lentamente. Bem, alguém é mais conservador, alguém ainda tem retornos de chamada, sem reatividade e nem mesmo Kotlin, porque a escala e as qualificações dos desenvolvedores não permitem isso.
A diferença da situação na CEI é que muitas vezes nos entreolhamos e dizemos: "Caras de Gradle, ajudem com alguma coisa". Ou seja, enquanto o CIS usa ferramentas escritas no Vale, aqui também nos comunicamos constantemente.
O Google está certo
- Recentemente, Jake Wharton fez várias críticas às soluções do Google para o desenvolvimento do Android, e você concordou com isso. O que exatamente você acha que o Google está fazendo de errado?- Houve uma discussão que não era necessário chamar o ViewModel e colocar o contexto nele. Com isso, eu acho, muitos também concordam. Estou muito chateado que muitos percebam as bibliotecas do Google como uma fonte inegável e mais correta.
Os candidatos comparecem às nossas entrevistas e 9 em cada 10 usam o Android Architecture Components para resolver as tarefas que definimos para descrever o design do aplicativo que eles escreveriam. Aqui não posso discordar de Jake que o ViewModel tem problemas controversos, embora todos gostem do ciclo de vida.
Quanto à biblioteca de vinculação de dados, o Android Summit foi indicativo neste outono, onde, em um bate-papo junto à lareira, cinco em cada dez perguntas eram sobre algo que não estava funcionando na vinculação de dados. A ferramenta era muito poderosa e, na minha opinião pessoal, nunca foi lembrada para montagem rápida e com vários módulos. Mas, ao mesmo tempo, todos o consideravam verdade.
Na verdade, é bastante conveniente, mas o Google, na minha opinião, não alocou recursos suficientes para continuar a apoiá-lo. E então a comunidade reagiu: eles confiaram no Google, mas não temos suporte suficiente.
"Algumas pessoas estão descontentes com o fato de muitas das soluções do Google terem aparecido apenas nos últimos anos:" Uma boa colher para o jantar, você fica empolgado há anos e a comunidade já descobriu, mas agora você acordou. " O que você acha disso? Por que a empresa está se comportando dessa maneira e é ruim?- Eu vejo tudo isso do ponto de vista da alocação do orçamento e do ponto de vista da estratégia de alguns gerentes superiores separados que anteriormente tinham um ponto de vista ou eram apenas outras pessoas, mas agora eles mudaram, com uma abordagem diferente.
Ou seja, esse não é o Google, mas apenas algumas pessoas que tomam decisões na equipe de alocação de recursos do Android. Então eles conseguiram recursos, devrel e desenvolvedores de bibliotecas que queriam fazer exatamente isso - havia soluções do Google. E é definitivamente bom que eles tenham aparecido! Fico mais chateado com uma comunidade que acredita incondicionalmente no que lhes foi dito e não faz nenhuma avaliação crítica.
- O Google, em um recente tutorial em vídeo sobre desenvolvimento do Android no Udacity, fornece uma mistura de coisas básicas que todos precisam e soluções como a Ligação de dados. Você vê o problema de que os iniciantes não familiarizados com o contexto os perceberão como uma verdade indiscutível, e não como uma opção opcional?- Os cursos em vídeo sobre o Udacity são uma história separada. Eu conheço os cursos do Android desde 2016, quando fizemos o primeiro curso do Study Jam. Lá, em geral, tudo correu perfeitamente, as coisas básicas foram perfeitamente explicadas. Mas das oito lições do curso, duas estão no meio - tópicos ContentProvider muito indigestíveis, intransitáveis e muito complexos. Por que um iniciante saberia como o ContentProvider está estruturado, já em 2016 não estava claro.
Eu ainda tinha perguntas sobre como eles compõem tópicos e colocam sotaques. Portanto, as palavras de que tudo está misturado lá agora, não me surpreendem. Mas os cursos em vídeo, aos quais vale a pena prestar homenagem, geralmente são sempre um tópico complicado. Eles se tornam obsoletos assim que você os lança.
É muito difícil preparar material de boa qualidade. Existem muitos lugares na comunidade onde você pode obter novas fontes de atualizações e entender o que está acontecendo e como. Mas se os iniciantes nos lerem - vão trabalhar em qualquer empresa que esteja envolvida no desenvolvimento móvel, você será ensinado imediatamente como fazer tudo certo. Algo mais ou menos relevante, vamos saber, de boca em boca.
- Aqui, os iniciantes terão a pergunta "como chegar lá sem experiência, se você ainda não passou um ano nos cursos".- Esta é uma pergunta muito boa. Acredito que muitas empresas adequadas levarão a ciência da computação ao conhecimento básico sem conhecer nenhuma estrutura. Como você sempre pode descobrir a estrutura e obter conhecimentos básicos sobre solução de algoritmos, é difícil chegar a algum lugar com conhecimento de programação orientada a objetos e apenas julgamento adequado. Essa é a base. Com a fundação você será levado. E se você também tem inglês, as portas estão geralmente abertas para você.
- Anteriormente, você estava interessado na plataforma Android Things e, recentemente, tudo ficou bastante triste para ela. Que conclusão devemos tirar da história? Que você nunca pode confiar totalmente em grandes empresas e precisa usar qualquer plataforma com a expectativa de que amanhã ela não se torne?- Conclusão - que precisamos monitorar tendências. Este não é o primeiro ano em que existe uma tendência de que qualquer dispositivo eletrônico, seja um aspirador de pó ou um micro-ondas, comece a ser controlado a partir da nuvem, como se nós, paranóicos, não estivéssemos tristes com isso.
O Android Things como plataforma está sobrecarregado demais para tarefas simples do Android, embora não ajude muito em termos de nuvem ou algum tipo de aprendizado de máquina (devido, novamente, a problemas de desempenho). Isso sugere que o Android Things não é tão legal. Mas eu mesmo fui o único que até o final acreditou que essa plataforma é pelo menos uma solução para os problemas que os pedaços de ferro com o Kickstarter param de atualizar. Que o Google atualize pelo menos o sistema operacional e libere patches de segurança.
, : , Google Cloud Next , IoT Google - , — .
— , , . ?— Telegram- , , TikTok —
, - — . — . — , .
— , . , , .
— , TikTok ?— - , - , . , , — . , .
— 90 Seconds, — ? ?— . , . , Telegram, WhatsApp Google Docs, . B2B-, , . , , , — .
— , , . Twitter, — , ?— , , Telegram. , . , Twitter.
— : Mobius?— , . , over engineering, , .
, , , 60 ( Android). — , . , «2-5 2 » .