Denis Neklyudov est intéressant pour les développeurs Android pour plusieurs raisons. Il est engagé dans le podcast Android Dev, prend la parole lors de conférences, assiste aux sommets GDE - en général, est impliqué dans la vie de la communauté de diverses manières. Et puisqu'il vit maintenant aux États-Unis et travaille à Lyft, il peut comparer la situation occidentale avec la situation russe.
Et à la veille de Mobius 2019 Piter, où il
parle de «l'architecture en mettant l'accent sur la mise à l'échelle», nous lui avons demandé un peu de tout cela. Comment un podcast russe peut-il intéresser les auditeurs occidentaux? Comment vous sentez-vous de travailler là où des centaines de développeurs mobiles comptent? Quel est le problème avec les solutions de Google pour les développeurs Android? Et quel est le problème avec l'utilisation des smartphones en général?
Podcasts
- Vous participez à Android Dev Podcast , et récemment Flutter Dev Podcast est également apparu - comment ce «bourgeonnement» s'est-il produit?- Au départ, j'étais le troll Flutter le plus important. Ceux qui étaient au sommet du GDE ne vous laisseront pas mentir. J'ai dit directement aux principaux gestionnaires de Google: de quel type d'artisanat s'agit-il, comment pouvez-vous le mettre à côté de notre sérieux Android pour adultes?
Mais quelques mois après avoir dit tout cela, ils ont été libérés, j'ai tout essayé de mes propres mains, j'ai regardé ce que vous pouvez faire à ce sujet et j'ai réalisé que ce n'était pas du tout un jouet.
Au début, nous avons perçu qu'il y avait une sorte de machine virtuelle, JavaScript. Et puis il s'est avéré que tout est compilé en code natif et fonctionne vraiment rapidement sur les deux plates-formes. Dans le même temps, le réglage est assez ancien pour une telle plate-forme expérimentale, semble-t-il. Et il s'est avéré que le langage Dart n'est pas si mal. Oui, ce n'est pas Kotlin que nous connaissons, mais un langage très adulte et bon avec tous les charmes des langages de programmation modernes.
J'ai changé d'avis et il est devenu clair que Flutter avait des perspectives. Même React Native, Xamarin et d'autres cadres tiers se sont répandus, et ici le support Google, et même des rumeurs sur le nouveau système d'exploitation Fuchsia, où Dart et Flutter seront utilisés en premier lieu.
Mais nous ne couvrirons pas toutes les nouvelles de Flutter dans Android Dev Podcast. Et puis j'ai eu l'idée que ce serait bien de faire un podcast séparé. Je me suis tourné vers mon vieil ami des années universitaires, Zhenya Saturov, en disant: «Voulez-vous prendre l'initiative? Je ne tirerai pas le deuxième podcast, mais tu es plus jeune, peut-être que tu le prendras. " Et c'est ainsi que Flutter Dev Podcast est né.
- Lorsque la même entreprise Google développe à la fois le développement natif d'Android et Flutter, les développeurs novices peuvent ne pas savoir "où dois-je aller". Cela vous semble-t-il un problème?- Si les débutants n'arrivent pas à se décider, laissez-les passer immédiatement au développement de jeux sur Unity! Mais sérieusement, il y a un effet décrit, mais Google est assis sur deux chaises depuis si longtemps: web et natif. Il y a des choses comme Progressive Web Apps qui sont également en cours de développement chez Google. Il semble qu'il existe des plates-formes natives, pourquoi animez-vous votre PWA? Et il y a aussi des initiatives comme WebAssembly liées à l'exécution de tout ce qui est possible dans le navigateur (Google était originaire du monde du web).
Par conséquent, Google n'est pas la première fois à créer des emplois différents pour différentes catégories de résolution du même problème. C'est un énorme colosse où à l'intérieur il y a différentes petites entreprises qui luttent les unes avec les autres. Il n'est donc pas surprenant qu'il y ait de la concurrence au sein d'une même entreprise.
- Poursuivre le sujet des podcasts: la société Lyft, où vous travaillez, a cette année son propre podcast sur le développement mobile. Avez-vous quelque chose à voir avec ça?- Ils l'ont commencé avant mon arrivée: lorsque la société va faire un podcast, ce n'est pas "enregistré, organisé", mais un long processus pour se mettre d'accord sur ce dont vous pouvez parler, dont vous ne pouvez pas parler. Mais ils ont promis de m'inviter à l'un de ces sujets (ils n'ont pas appelé l'hôte).
Il existe de nombreux podcasts sur le développement mobile - récemment,
une autre langue russe est apparue. Je pense que plus il y en a, mieux c'est: la qualité de ceux qui veulent être au top est meilleure. Mais il est clair que les auditeurs doivent consommer de plus en plus de matériel. Il en va de même pour les mitaps, les conférences, les plateformes de rapports.
- Il existe également un podcast The Context avec Artyom Zinnatullin , et puisque vous travaillez maintenant avec lui dans la même entreprise, la question est, voulez-vous unir vos forces d'une manière ou d'une autre.- Pour autant que je sache, Artyom a déjà manqué certaines éditions de The Context en raison de l'emploi élevé au travail. Mais il vient aussi avec joie dans Android Dev Podcast, tout dépend des sujets. Artyom ne modifie pas les éditions, mais est livré avec un avis d'expert. Et j'aime souvent faire du montage, et ici nous faisons des choses complètement différentes.
- Lorsque vous êtes engagé dans des podcasts en russe tout en vivant à l'étranger, cela ressemble-t-il à deux vies parallèles, où votre podcast n'est pas écouté au travail, et dans le podcast, vous ne savez quelque chose sur votre travail que par vos mots?- À Singapour, cela n'a pas été ressenti, mais aux États-Unis, on a vraiment l'impression qu'il s'agit de deux mondes différents. En Russie, ils me connaissent, mon nom a déjà un certain poids. Personne ne me connaît aux États-Unis et en réponse aux mots «j'ai un podcast», ils demandent pourquoi ils ne l'ont pas entendu. Parce qu'il est en russe. Ici, bien sûr, je perds.
Par conséquent, mon initiative personnelle est de faire des sorties en anglais du podcast, de parler davantage en anglais pour élargir le public. Ce dont nous discutons en Russie est tout aussi pertinent en Occident, il existe de nombreuses niches non remplies. Il me semble que les sujets que nous abordons dans le podcast seraient intéressants à couvrir plus souvent ici.
- Les auditeurs anglophones ont déjà des podcasts comme Fragmented - que pensez-vous qu'Android Dev Podcast peut donner, qu'ils n'ont pas?- J'ai toujours voulu croire que nous sommes plus proches de l'auditeur. Nous n'essayons pas d'être objectifs, et souvent notre opinion personnelle reste l'opinion personnelle exprimée en public. Mais en même temps, cette opinion a une grande expérience derrière nous, et nous ne sommes pas gênés dans nos déclarations.
Peut-être qu'en Occident, cela ne fonctionnera tout simplement pas, alors Fragmented est un podcast plus raffiné, où il n'y a pas assez de fond, de détails et de difficultés (que beaucoup ne comprennent tout simplement pas). À la recherche d'un nombre élevé d'auditions pour un large public, certains podcasts suppriment des sujets de discussion complexes.
- Ne parlant pas de podcasts, mais de développement Android, ressentez-vous une différence notable entre les États-Unis et la Russie?- Je pense que oui. Je ne suis pas encore prêt à juger strictement, mais le sentiment principal (pas aussi dur qu'à Singapour) est que tout le monde s'intéresse très faiblement à son métier et à ses compétences. Ici, lorsque l'entreprise a de nombreux développeurs sur la même plate-forme, les gens s'assoient et font leurs tâches, pour eux, Android n'est pas leur vie, pas leur passion, pas leur passe-temps, mais simplement une liste de tâches qu'ils doivent mettre en œuvre.
Grande échelle dans le développement mobile
- Vous travaillez dans une entreprise où il y a plus d'une centaine de développeurs mobiles. Est-ce qu'ils posent constamment la question "Vous avez une application sur un écran environ, que devrait faire une telle foule là-bas?"- J'ai moi-même d'abord posé des questions à ce sujet. La réponse vient quand vous entrez dans tout cela.
Premièrement, nous ne pouvons pas dire que nous avons une application à écran unique. Pour commencer, il y a deux applications (conducteur et passager), puis, si nous parlons de l'expérience des passagers, nous avons une application avec des voitures, des scooters, des vélos, des voitures autonomes et avec des puces différentes pour différentes régions (paiement et utilisateur) .
Et deuxièmement, beaucoup de difficultés viennent avec l'échelle. Il y a beaucoup de travail lié à la réflexion sur les métriques, à la création d'expériences, au suivi de la progression de votre travail précédent. L'échelle sous forme de millions d'utilisateurs affecte le temps de développement, maintenant je comprends mieux cela.
Nous sommes divisés en petites sous-commandes interfonctionnelles, où tout le monde est responsable d'une section. Quelqu'un est responsable du voyage, quelqu'un pour les vélos et les scooters, et c'est ainsi que se forment deux douzaines d'équipes différentes, dans lesquelles il y a deux ou trois développeurs. Je suis responsable de la partie relative à l'identification des utilisateurs. Et j'aimerais qu'un autre collègue apparaisse pour cette partie, augmentant notre compteur total.
Si nous parlons des développeurs de petites applications, qui sont pleines parmi nos lecteurs, il se trouve simplement que nous sommes simplement constitués d'une douzaine de petites applications à l'intérieur d'une grande.
La situation est similaire dans de nombreuses applications importantes. Et la division en équipes de fonctionnalités, et le développement axé sur les métriques, où les métriques conduisent tout, et l'approche de démarrage, lorsque nous créons pour la première fois MVP, puis le portons à un bon état: pour certains, c'est sous la forme de l'ensemble du produit, et pour quelqu'un sous la forme d'une caractéristique interne. Même Google met ses petites équipes de manière à ce qu'elles ressemblent à une startup et essaie de minimiser la bureaucratie et les longs cycles de développement.
- Et à quoi ressemble le travail d'un employé particulier dans une telle situation? Pouvez-vous parler de certaines de vos tâches volumineuses?- Il m'a fallu deux mois pour créer un profil utilisateur, même si ce n'est pas difficile en soi. L'écran lui-même est nouveau, auparavant l'utilisateur n'avait pas de profil, il n'y avait que des paramètres. Outre le fait qu'il fallait faire le fini, il s'est avéré que du point de vue architectural, certains composants n'étaient pas suffisants, il m'a fallu entrer dans l'architecture, aider les gars.
J'ai également décidé d'expérimenter avec Dagger, cela a également pris du temps. Il a également fallu réfléchir aux métriques, construire un tableau de bord, collecter des analyses du succès de l'expérience, cela a pris du temps. Ensuite, j'ai commencé à ajouter des écrans existants des paramètres aux écrans internes du profil et à les mettre à jour.
La mise à jour selon la «règle du scout» a nécessité une refactorisation de ce qui a été touché. La refactorisation de la dernière architecture a également pris du temps. De plus, nous avons un système de conception et certains composants ne sont pas mis en œuvre à partir des derniers éléments approuvés. Qu'attendre l'équipe qui écrit ces éléments, je les ai pris et aidés à leur copier leur travail, afin de ne pas être bloqué.
De tout cela, deux mois de travail se sont formés, qui à première vue semblaient quelques semaines.
- Lorsque vous voulez "expérimenter avec Dagger" pendant la tâche, ces expériences sont-elles encouragées?- Dépend du niveau de l'ingénieur. Je pense que s'il est ingénieur débutant, alors lui et le gestionnaire ont clairement compris qu'il n'est pas distrait par des expériences architecturales, car lui-même est toujours vert pour cela.
Et à partir d'ingénieurs expérimentés, il est directement dans leurs responsabilités de contribuer à quelque chose de large: à l'échelle de l'organisation, ou du moins à l'échelle de l'application. Par conséquent, il n'y a nulle part où aller: même si ce n'est pas très intéressant de s'engager dans l'architecture, mais que vous souhaitez vous développer, vous devez connecter votre vie à quelque chose de plus que de simples fonctionnalités.
- Et si vous avez expérimenté et que le résultat a été un succès, cela devient alors une politique générale, ou peut-il rester au sein de l'équipe?- Très rarement, il reste à l'intérieur d'une équipe. Habituellement, si quelqu'un commence une expérience, cela est immédiatement cohérent avec l'équipe d'architecture de base et est ensuite considéré comme une bonne pratique générale. Par exemple, maintenant deux équipes expérimentent en parallèle avec Redux pour comprendre lequel d'entre nous va gagner, dont la solution sera plus universelle, et nous commencerons à l'utiliser dans toute l'entreprise.
- L'augmentation du nombre de personnes dans une équipe est également la croissance de la «paperasse» lorsque vous ne codez pas, mais faites quelque chose de connexe. Il est clair que cela est nécessaire, mais dans quelle mesure cela ralentit-il le développeur par rapport à la façon dont, dans un petit projet, il «présenterait simplement»?- Encore une fois dépend du niveau d'ingénieur. Si l'ingénieur est moyen ou débutant senior, il n'est pas obligé d'écrire beaucoup de documents, il s'assoit et détermine les caractéristiques sous la supervision de son ingénieur senior. Mais l'ingénieur senior acquiert déjà des responsabilités managériales, comme dans toute autre entreprise. Il ne peut pas se permettre de parler avec son patron s'il s'agit d'une startup, ou d'écrire des documents pour son manager, s'il s'agit d'une grande entreprise.
- Lorsque vous créez une application Android pour un taxi, les problèmes et les problèmes actuels sont-ils les mêmes que ceux des autres grandes applications, ou avez-vous vos propres spécificités?- Les problèmes auxquels nous sommes confrontés sont très similaires. Par exemple, le problème de l'assemblage multi-module ajoute la même préoccupation aux ingénieurs d'infrastructure au quotidien, il n'est donc pas surprenant que Uber, Facebook, Airbnb et Lyft utilisent le même système de construction Buck.
D'autres le regardent également, atteignant notre échelle, ce qui confirme que les problèmes sont les mêmes. En parallèle, les mêmes processus se produisent - par exemple, tous deviennent lentement réactifs. Eh bien, quelqu'un est plus conservateur, quelqu'un a toujours des rappels, pas de réactivité, et même pas de Kotlin, car l'échelle et les qualifications des développeurs ne le permettent pas.
La différence par rapport à la situation dans la CEI est que nous nous rencontrons souvent et disons: "Les gars de Gradle, aidez-nous." Autrement dit, alors que le CIS utilise des outils écrits dans la vallée, ici, nous communiquons également constamment les uns avec les autres.
Google a-t-il raison
- Récemment, Jake Wharton a émis un certain nombre de critiques à l'égard des solutions de Google pour le développement Android, et vous en êtes d'accord avec certaines d'entre elles. Que pensez-vous exactement que Google fait de mal?- Il y a eu une discussion sur le fait qu'il n'était pas nécessaire d'appeler le ViewModel et d'y mettre le contexte. Avec cela, je pense que beaucoup seront également d'accord. Je suis très contrarié que beaucoup considèrent les bibliothèques de Google comme une source indéniable et la plus correcte.
Les candidats viennent à nos entrevues et 9 sur 10 utilisent des composants d'architecture Android pour résoudre les tâches que nous leur avons définies pour décrire la conception de l'application qu'ils écriraient. Ici, je ne peux pas être en désaccord avec Jake que le ViewModel a des problèmes controversés, bien que tout le monde aime vraiment le cycle de vie.
En ce qui concerne la bibliothèque Data Binding, Android Summit était indicatif cet automne, où sur une conversation au coin du feu, cinq questions sur dix portaient sur quelque chose qui ne fonctionnait pas dans Data Binding. L'outil était trop puissant, et à mon avis personnel, il n'a jamais été pensé pour un assemblage rapide et multi-modules. Mais en même temps, tout le monde le considérait comme la vérité.
En fait, c'est assez pratique, mais Google, à mon avis, n'a pas alloué suffisamment de ressources pour continuer à le prendre en charge. Et puis la communauté a craqué: ils ont fait confiance à Google, mais nous n'avons pas assez d'assistance.
"Certaines personnes ne sont pas satisfaites du fait que de nombreuses solutions de Google ne sont apparues que ces dernières années:" Une bonne cuillère pour le dîner, vous avez été affalé pendant des années et la communauté l'a compris, mais maintenant vous vous êtes réveillé. " Qu'en pensez-vous? Pourquoi l'entreprise se comporte-t-elle ainsi et est-ce mauvais?- Je vois tout cela du point de vue de l'allocation budgétaire et du point de vue de la stratégie de certains cadres supérieurs distincts qui avaient auparavant un point de vue ou n'étaient que d'autres personnes, mais maintenant ils ont changé, avec une approche différente.
Autrement dit, ce n'est pas Google, mais seulement quelques personnes qui prennent des décisions dans l'équipe d'allocation des ressources Android. Ils ont donc obtenu des ressources, des développeurs et des développeurs de bibliothèques qui voulaient faire exactement cela - il y avait des solutions de Google. Et c'est vraiment bien qu'ils soient apparus! Je suis plus bouleversé pour une communauté qui croit inconditionnellement ce qu'on lui a dit et ne donne aucune évaluation critique.
- Google, dans un récent didacticiel vidéo de développement Android sur Udacity, fournit un mélange de choses de base dont tout le monde a besoin et de solutions comme la liaison de données. Voyez-vous le problème en ce que les débutants peu familiers avec le contexte les percevront comme une vérité incontestable, et non comme une option optionnelle?- Les cours vidéo sur Udacity sont une autre histoire. Je connais les cours Android depuis 2016, lorsque nous avons suivi le premier cours Study Jam sur eux. Là, en général, tout s'est parfaitement déroulé, les choses de base ont été parfaitement expliquées. Mais sur les huit leçons du cours, deux sont au milieu - des sujets ContentProvider indigestes, infranchissables et très complexes. Pourquoi un débutant saurait-il comment ContentProvider est structuré, déjà en 2016, ce n'était pas clair.
J'avais encore des questions sur la façon dont ils composaient les sujets et mettaient les accents. Par conséquent, les mots que tout est mélangé là-bas maintenant, ne me surprennent pas du tout. Mais les cours vidéo, auxquels il faut rendre hommage, sont généralement toujours un sujet compliqué. Ils deviennent obsolètes dès que vous les éteignez.
Il est très difficile de préparer du matériel de bonne qualité. Il existe de nombreux endroits dans la communauté où vous pouvez obtenir de nouvelles sources de mises à jour et comprendre ce qui se passe et comment. Mais si les débutants nous lisent - allez travailler dans n'importe quelle entreprise engagée dans le développement mobile, vous apprendrez immédiatement comment tout faire correctement. Quelque chose de plus ou moins pertinent, disons, de bouche à oreille.
- Ici, les débutants auront une question "comment s'y rendre sans expérience, si vous n'avez pas encore passé un an sur les cours".- C'est une très bonne question. Je crois que de nombreuses entreprises adéquates prendront l'informatique pour les connaissances de base sans connaître aucun cadre. Parce que vous pouvez toujours découvrir le cadre et acquérir des connaissances de base sur la résolution des algorithmes, la connaissance de la programmation orientée objet et un jugement juste adéquat sont difficiles à trouver. C'est la base. Avec la fondation, vous serez pris. Et si vous avez aussi l'anglais, les portes sont généralement ouvertes pour vous.
- Auparavant, vous étiez intéressé par la plateforme Android Things, et récemment tout est devenu plutôt triste pour elle. Quelle conclusion faut-il tirer de l'histoire? Que vous ne pouvez jamais faire entièrement confiance aux grandes entreprises et que vous devez utiliser n'importe quelle plate-forme en espérant que demain elle ne deviendra pas?- Conclusion - que nous devons surveiller les tendances. Ce n'est pas la première année qu'il y a une tendance à ce que n'importe quel appareil électronique, qu'il s'agisse d'un aspirateur ou d'un micro-ondes, commence à être contrôlé à partir du nuage, comme si nous, les paranoïaques, n'en étions pas tristes.
Android Things en tant que plate-forme est trop surchargé pour les tâches Android simples, alors qu'il n'aide pas beaucoup en termes de cloud ou de type d'apprentissage automatique (en raison, encore une fois, de problèmes de performances). Cela suggère qu'Android Things n'est pas si cool. Mais j'étais moi-même celui qui jusqu'à la dernière croyait que cette plate-forme est au moins une solution aux problèmes que les morceaux de fer avec Kickstarter cessent de mettre à jour. Que Google mettra au moins à jour le système d'exploitation et publiera des correctifs de sécurité.
, : , 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 » .