Denis Neklyudov ist aus mehreren Gründen für Android-Entwickler interessant. Er nimmt am Android Dev Podcast teil, spricht auf Konferenzen, nimmt an GDE-Gipfeln teil - ist im Allgemeinen auf vielfältige Weise am Leben der Community beteiligt. Und da er jetzt in den USA lebt und bei Lyft arbeitet, kann er die westliche Situation mit der russischen vergleichen.
Und am Vorabend von Mobius 2019 Piter, wo er über „Architektur mit Schwerpunkt auf Skalierung“
spricht , haben wir ihn ein wenig nach all dem gefragt. Wie kann ein russischer Podcast für westliche Hörer von Interesse sein? Wie fühlt es sich an, dort zu arbeiten, wo Hunderte von mobilen Entwicklern zählen? Was ist falsch an Googles Lösungen für Android-Entwickler? Und was ist falsch an der Verwendung von Smartphones im Allgemeinen?
Podcasts
- Sie nehmen am Android Dev Podcast teil , und kürzlich erschien auch der Flutter Dev Podcast. Wie kam es zu diesem „Knospen“?- Anfangs war ich der wichtigste Flutter-Troll. Diejenigen, die auf dem GDE-Gipfel waren, werden Sie nicht lügen lassen. Ich habe den wichtigsten Google-Managern direkt gesagt: Was für ein Handwerk ist das, wie können Sie es neben unser ernstes Android für Erwachsene stellen?
Aber ein paar Monate nachdem ich das alles gesagt hatte, wurden sie freigelassen. Ich selbst habe alles mit meinen eigenen Händen versucht, mir angesehen, was man dagegen tun kann, und festgestellt, dass dies überhaupt kein Spielzeug ist.
Zuerst stellten wir fest, dass es eine Art virtuelle Maschine gab, JavaScript. Und dann stellte sich heraus, dass alles in nativen Code kompiliert ist und auf beiden Plattformen wirklich schnell funktioniert. Gleichzeitig ist das Tuning alt genug für eine solche experimentelle Plattform. Und es stellte sich heraus, dass die Dart-Sprache nicht so schlecht ist. Ja, das ist Kotlin nicht vertraut, aber eine sehr erwachsene und gute Sprache mit allen Reizen moderner Programmiersprachen.
Ich änderte meine Meinung und es wurde klar, dass Flutter Aussichten hatte. Sogar React Native, Xamarin und andere Frameworks von Drittanbietern haben sich verbreitet, und hier unterstützt Google und sogar Gerüchte über das neue Fuchsia-Betriebssystem, bei dem Dart und Flutter überhaupt verwendet werden.
Wir werden jedoch nicht alle Flutter-Nachrichten im Android Dev Podcast behandeln. Und dann kam mir die Idee, dass es schön wäre, einen separaten Podcast zu erstellen. Ich wandte mich an meine alte Freundin aus den Universitätsjahren, Zhenya Saturov, und sagte: „Wollen Sie die Initiative ergreifen? Ich werde den zweiten Podcast nicht abrufen, aber du bist jünger, vielleicht nimmst du ihn. " Und so wurde Flutter Dev Podcast geboren.
- Wenn dasselbe Google-Unternehmen sowohl die native Android-Entwicklung als auch Flutter entwickelt, ist es für unerfahrene Entwickler möglicherweise nicht klar, "wohin soll ich gehen". Scheint Ihnen das ein Problem zu sein?- Wenn Anfänger sich nicht entscheiden können, lassen Sie sie sofort mit der Entwicklung von Spielen auf Unity beginnen! Aber im Ernst, es gibt einen beschriebenen Effekt, aber Google hat so lange auf zwei Stühlen gesessen: Web und Native. Es gibt Dinge wie Progressive Web Apps, die auch bei Google entwickelt werden. Es scheint, dass es native Plattformen gibt. Warum beschäftigen Sie Ihre PWA? Und es gibt auch Initiativen wie WebAssembly, die sich auf die Ausführung von allem beziehen, was im Browser möglich ist (Google stammte ursprünglich aus der Welt des Webs).
Daher ist Google nicht das erste Mal, dass unterschiedliche Jobs für unterschiedliche Kategorien zur Lösung desselben Problems erstellt werden. Dies ist ein so großer Koloss, in dem verschiedene kleine Unternehmen miteinander kämpfen. Daher ist es nicht verwunderlich, dass innerhalb eines Unternehmens Wettbewerb herrscht.
- Fortsetzung des Themas Podcasts: Die Firma Lyft, in der Sie arbeiten, hat dieses Jahr einen eigenen Podcast zur mobilen Entwicklung. Hast du etwas damit zu tun?- Sie haben damit begonnen, bevor ich gekommen bin: Wenn das Unternehmen einen Podcast erstellt, wird dieser nicht „aufgezeichnet, angelegt“, sondern es wird lange vereinbart, worüber Sie sprechen können, worüber Sie nicht sprechen können. Aber sie versprachen, mich zu einem dieser Themen einzuladen (sie riefen den Gastgeber nicht an).
Es gibt viele Podcasts zur mobilen Entwicklung - kürzlich ist eine
weitere russische Sprache erschienen. Ich denke, je mehr es gibt, desto besser: Die Qualität derer, die an der Spitze sein wollen, ist höher. Aber es ist klar, dass die Zuhörer immer mehr Materialien konsumieren müssen. Ähnlich verhält es sich mit Mitaps, Konferenzen und Plattformen für Berichte.
- Es gibt auch einen The Context- Podcast mit Artyom Zinnatullin , und da Sie jetzt mit ihm in derselben Firma arbeiten, stellt sich die Frage, ob Sie sich irgendwie zusammenschließen möchten.- Soweit ich weiß, hat Artyom aufgrund der hohen Beschäftigung bei der Arbeit bereits einige Ausgaben von The Context verpasst. Aber er kommt auch mit Freude im Android Dev Podcast zu uns, alles hängt von den Themen ab. Artyom bearbeitet keine Editionen, verfügt jedoch über eine Expertenmeinung. Und ich bearbeite oft gerne, und hier machen wir ganz andere Dinge.
- Wenn Sie sich im Ausland mit russischsprachigen Podcasts beschäftigen, fühlen Sie sich dann wie zwei parallele Leben, in denen Ihr Podcast bei der Arbeit nicht angehört wird und Sie im Podcast etwas über Ihre Arbeit nur aus Ihren Worten wissen?- In Singapur war dies nicht zu spüren, aber in den USA ist es wirklich so, dass dies zwei verschiedene Welten sind. In Russland kennen sie mich, mein Name hat schon etwas Gewicht. Niemand kennt mich in den USA und als Antwort auf die Worte "Ich habe einen Podcast" fragen sie, warum sie ihn nicht gehört haben. Weil er auf Russisch ist. Hier verliere ich natürlich.
Daher ist es meine persönliche Initiative, den Podcast in englischer Sprache zu veröffentlichen und mehr Englisch zu sprechen, um das Publikum zu erweitern. Was wir in Russland diskutieren, ist im Westen genauso relevant, es gibt viele unbesetzte Nischen. Es scheint mir, dass die Themen, die wir im Podcast ansprechen, hier gerne öfter behandelt werden.
- Englisch sprechende Hörer haben bereits Podcasts wie Fragmented - was kann Android Dev Podcast Ihrer Meinung nach geben, was sie nicht haben?- Ich wollte immer glauben, dass wir dem Hörer näher sind. Wir versuchen nicht, objektiv zu sein, und oft bleibt unsere persönliche Meinung die in der Öffentlichkeit geäußerte persönliche Meinung. Gleichzeitig hat diese Meinung einige großartige Erfahrungen hinter sich, und wir schämen uns nicht für unsere Aussagen.
Vielleicht geht es im Westen einfach nicht, also ist Fragmented ein verfeinerter Podcast, in dem es nicht genügend Hintergrundinformationen, Details und Schwierigkeiten gibt (die viele einfach nicht verstehen). Einige Podcasts streben komplexe Themen zur Diskussion an, um eine hohe Anzahl von Auditions für ein breites Publikum zu erreichen.
- Wenn Sie nicht über Podcasts, sondern über die Android-Entwicklung sprechen, spüren Sie dabei einen spürbaren Unterschied zwischen den USA und Russland?- Ich denke schon. Ich bin noch nicht bereit, streng zu urteilen, aber das Hauptgefühl (nicht so schwer wie in Singapur) ist, dass jeder sehr schwach an seinem Beruf und seinen Fähigkeiten interessiert ist. Wenn das Unternehmen viele Entwickler auf derselben Plattform hat, sitzen die Leute einfach da und erledigen ihre Aufgaben. Für sie ist Android nicht ihr Leben, nicht ihre Leidenschaft, nicht ihr Hobby, sondern einfach eine Liste von Aufgaben, die sie implementieren müssen.
Großer Umfang in der mobilen Entwicklung
- Sie arbeiten in einem Unternehmen, in dem es mehr als hundert mobile Entwickler gibt. Stellen sie ständig die Frage: "Sie haben eine Anwendung von ungefähr einem Bildschirm, was sollte eine solche Menge dort tun?"- Ich selbst habe zunächst danach gefragt. Die Antwort kommt, wenn Sie in all das hineinkommen.
Erstens können wir nicht sagen, dass wir eine Einzelbildschirmanwendung haben. Zunächst gibt es zwei Anwendungen (Fahrer und Beifahrer). Wenn wir dann über die Passagiererfahrung sprechen, haben wir eine Anwendung mit Autos, Rollern, Fahrrädern, autonomen Autos und mit verschiedenen Chips für verschiedene Regionen (sowohl Zahlung als auch Benutzer). .
Und zweitens sind mit der Skalierung viele Schwierigkeiten verbunden. Es gibt viel Arbeit im Zusammenhang mit dem Durchdenken von Metriken, dem Erstellen von Experimenten und dem Verfolgen des Verlaufs Ihrer vorherigen Arbeit. Die Skalierung in Form von Millionen von Benutzern beeinflusst die Entwicklungszeit, jetzt verstehe ich das besser.
Wir sind in kleine funktionsübergreifende Unterbefehle unterteilt, in denen jeder für einen Abschnitt verantwortlich ist. Jemand ist für die Reise verantwortlich, jemand für Fahrräder und Motorroller, und so werden zwei Dutzend verschiedene Teams gebildet, in denen zwei oder drei Entwickler sind. Ich bin verantwortlich für den Teil im Zusammenhang mit der Benutzeridentifikation. Und ich würde gerne sehen, dass ein anderer Kollege für diesen Teil erscheint und unseren Gesamtzähler erhöht.
Wenn wir über die Entwickler kleiner Anwendungen sprechen, die unter unseren Lesern voll sind, stellt sich heraus, dass wir einfach aus einem Dutzend kleiner Anwendungen in einer großen bestehen.
Bei vielen großen Anwendungen ist die Situation ähnlich. Und die Aufteilung in Feature-Teams und die metrikgesteuerte Entwicklung, bei der Metriken alles steuern, und der Startansatz, wenn wir zuerst MVP erstellen und dann in einen guten Zustand bringen: Für einige ist es die Form des gesamten Produkts und für jemanden in Form eines internen Features. Sogar Google stellt seine kleinen Teams so auf, dass sie wie ein Startup sind, und versucht, Bürokratie und lange Entwicklungszyklen zu minimieren.
- Und wie sieht die Arbeit eines bestimmten Mitarbeiters in einer solchen Situation aus? Können Sie über einige Ihrer umfangreichen Aufgaben sprechen?- Ich habe zwei Monate gebraucht, um ein Benutzerprofil zu erstellen, obwohl es an sich nicht schwierig ist. Der Bildschirm selbst ist neu, zuvor hatte der Benutzer kein Profil, es gab nur Einstellungen. Abgesehen von der Tatsache, dass es notwendig war, das fertige zu machen, stellte sich heraus, dass aus architektonischer Sicht einige Komponenten nicht ausreichten. Ich brauchte, um in die Architektur einzusteigen und den Jungs zu helfen.
Ich habe auch beschlossen, mit Dolch zu experimentieren, es hat auch Zeit gekostet. Es war auch notwendig, über Metriken nachzudenken, ein Dashboard zu erstellen und Analysen über den Erfolg des Experiments zu sammeln. Es dauerte einige Zeit. Dann fing ich an, vorhandene Bildschirme aus den Einstellungen zu den internen Bildschirmen des Profils hinzuzufügen und zu aktualisieren.
Das Aktualisieren gemäß der "Scout-Regel" erforderte eine Umgestaltung der Berührungen. Das Refactoring für die neueste Architektur dauerte ebenfalls einige Zeit. Außerdem haben wir ein Konstruktionssystem, und einige Komponenten werden nicht aus den neuesten genehmigten Elementen implementiert. Was ich auf das Team warten soll, das diese Elemente schreibt, habe ich genommen und ihnen geholfen, ihre Arbeit auf sie zu kopieren, um nicht blockiert zu werden.
Aus all dem entstanden zwei Monate Arbeit, die auf den ersten Blick ein paar Wochen zu sein schienen.
- Wenn Sie während der Aufgabe "mit Dolch experimentieren" möchten, werden solche Experimente empfohlen?- Hängt vom Niveau des Ingenieurs ab. Ich denke, wenn er ein Einsteiger ist, dann haben er und der Manager ein klares Verständnis dafür, dass er nicht von architektonischen Experimenten abgelenkt wird, weil er selbst dafür immer noch grün ist.
Und von erfahrenen Ingenieuren liegt es direkt in ihrer Verantwortung, zu etwas Breitem beizutragen: organisationsweit oder zumindest anwendungsweit. Daher gibt es keinen Ort, an den man gehen kann: Auch wenn es nicht sehr interessant ist, sich mit Architektur zu beschäftigen, sondern sich weiterentwickeln möchte, muss man sein Leben mit etwas mehr als nur Funktionen verbinden.
- Und wenn Sie experimentiert haben und das Ergebnis erfolgreich war, wird es zu einer allgemeinen Richtlinie, oder kann es im Team bleiben?- Sehr selten bleibt es in einem Team. Wenn jemand ein Experiment startet, stimmt dies normalerweise sofort mit dem Kernteam der Architektur überein und wird anschließend als allgemeine bewährte Methode angesehen. Zum Beispiel experimentieren jetzt zwei Teams parallel mit Redux, um zu verstehen, wer von uns gewinnen wird, dessen Lösung universeller sein wird, und wir werden damit beginnen, sie im gesamten Unternehmen einzusetzen.
- Die Zunahme der Anzahl der Personen in einem Team ist auch das Anwachsen von „Papierkram“, wenn Sie nicht codieren, sondern etwas Ähnliches tun. Es ist klar, dass dies notwendig ist, aber wie sehr verlangsamt dies den Entwickler im Vergleich dazu, wie er in einem kleinen Projekt "nur" auftreten würde?- Auch dies hängt vom Niveau des Ingenieurs ab. Wenn der Ingenieur ein mittlerer oder ein Anfänger-Senior ist, muss er nicht viele Dokumente schreiben. Er sitzt und findet Merkmale unter der Aufsicht seines leitenden Ingenieurs heraus. Aber der leitende Ingenieur übernimmt wie in jedem anderen Unternehmen bereits Führungsverantwortung. Er kann nicht damit durchkommen, mit seinem Chef zu sprechen, wenn dies ein Startup ist, oder Dokumente für seinen Manager zu schreiben, wenn dies ein großes Unternehmen ist.
- Wenn Sie eine Android-Anwendung für ein Taxi erstellen, sind die Probleme und aktuellen Probleme mit denen anderer großer Anwendungen identisch, oder haben Sie Ihre eigenen Besonderheiten?- Die Probleme, mit denen wir konfrontiert sind, sind sehr ähnlich. Das Problem der Montage mit mehreren Modulen bereitet Infrastrukturingenieuren beispielsweise jeden Tag die gleichen Sorgen, sodass es nicht verwunderlich ist, dass Uber, Facebook, Airbnb und Lyft dasselbe Buck-Build-System verwenden.
Andere schauen es sich ebenfalls an und erreichen unsere Skala, und dies bestätigt, dass die Probleme dieselben sind. Parallel dazu finden die gleichen Prozesse statt - zum Beispiel werden alle langsam reaktiv. Nun, jemand ist konservativer, jemand hat immer noch Rückrufe, keine Reaktivität und sogar kein Kotlin, weil der Umfang und die Qualifikationen der Entwickler dies nicht zulassen.
Der Unterschied zur Situation in der GUS besteht darin, dass wir oft miteinander gehen und sagen: "Leute von Gradle, helfen mit etwas." Das heißt, während die GUS im Tal geschriebene Werkzeuge verwendet, kommunizieren wir hier auch ständig miteinander.
Ist Google richtig?
- Vor kurzem hatte Jake Wharton eine Reihe von Kritikpunkten an Googles Lösungen für die Android-Entwicklung, und Sie stimmten einigen davon zu. Was genau macht Google Ihrer Meinung nach falsch?- Es gab eine Diskussion, dass es nicht notwendig war, das ViewModel aufzurufen und den Kontext darin zu platzieren. Ich denke, dem werden auch viele zustimmen. Ich bin sehr verärgert darüber, dass viele Bibliotheken von Google als unbestreitbare und korrekteste Quelle wahrnehmen.
Die Kandidaten kommen zu unseren Interviews, und 9 von 10 verwenden Android-Architekturkomponenten, um die Aufgaben zu lösen, die wir ihnen gestellt haben, um das Design der Anwendung zu beschreiben, die sie schreiben würden. Hier kann ich Jake nicht widersprechen, dass das ViewModel kontroverse Probleme hat, obwohl jeder den Lebenszyklus wirklich mag.
In Bezug auf die Datenbindungsbibliothek war Android Summit in diesem Herbst ein Indikator, bei dem in einem Kamingespräch fünf von zehn Fragen zu etwas gestellt wurden, das in der Datenbindung nicht funktioniert. Das Tool war zu leistungsfähig, und meiner persönlichen Meinung nach wurde es nie für eine Multimodul- und Schnellmontage in Betracht gezogen. Gleichzeitig nahmen ihn alle als Wahrheit.
Tatsächlich ist es recht praktisch, aber Google hat meiner Meinung nach nicht genügend Ressourcen zugewiesen, um es weiterhin zu unterstützen. Und dann schnappte die Community: Sie vertrauten Google, aber wir bekommen nicht genug Unterstützung.
"Einige Leute sind unzufrieden mit der Tatsache, dass viele der Google-Lösungen erst in den letzten Jahren auf den Markt gekommen sind:" Ein guter Löffel zum Abendessen, Sie sind seit Jahren hängen geblieben und die Community hat es herausgefunden, und jetzt sind Sie aufgewacht. Was denkst du darüber? Warum verhält sich das Unternehmen so und ist es schlecht?- Ich sehe dies alles unter dem Gesichtspunkt der Mittelzuweisung und unter dem Gesichtspunkt der Strategie einiger separater höherer Manager, die zuvor einen Standpunkt hatten oder nur andere Personen waren, aber jetzt haben sie sich mit einem anderen Ansatz geändert.
Das heißt, dies ist nicht Google, sondern nur ein paar Leute, die Entscheidungen im Android-Ressourcenzuweisungsteam treffen. Also bekamen sie Ressourcen, Entwickler und Bibliotheksentwickler, die genau das wollten - es gab Lösungen von Google. Und es ist auf jeden Fall gut, dass sie aufgetaucht sind! Ich bin mehr verärgert über eine Gemeinschaft, die bedingungslos glaubt, was ihnen gesagt wurde, und keine kritische Bewertung abgibt.
- Google bietet in einem kürzlich veröffentlichten Video-Tutorial zur Android-Entwicklung zu Udacity eine Mischung aus grundlegenden Dingen, die jeder benötigt, und Lösungen wie Datenbindung. Sehen Sie das Problem darin, dass Anfänger, die mit dem Kontext nicht vertraut sind, sie als unbestreitbare Wahrheit und nicht als optionale Option wahrnehmen?- Videokurse über Udacity sind eine separate Geschichte. Ich bin dort seit 2016 mit Android-Kursen vertraut, als wir den ersten Study Jam-Kurs dazu absolvierten. Dort lief im Allgemeinen alles perfekt, die grundlegenden Dinge wurden perfekt erklärt. Von den acht Lektionen des Kurses befinden sich zwei in der Mitte - unverdauliche, unpassierbare, sehr komplexe ContentProvider-Themen. Warum sollte ein Anfänger wissen, wie ContentProvider aufgebaut ist, war bereits 2016 nicht klar.
Ich hatte immer noch Fragen, wie sie Themen zusammenstellen und Akzente setzen. Daher wundern mich die Worte, dass dort jetzt alles durcheinander ist, überhaupt nicht. Aber Videokurse, die es wert sind, gewürdigt zu werden, sind im Allgemeinen immer ein kompliziertes Thema. Sie werden veraltet, sobald Sie sie löschen.
Es ist sehr schwierig, qualitativ hochwertiges Material herzustellen. Es gibt viele Orte in der Community, an denen Sie neue Quellen für Updates und ein Verständnis dafür erhalten, was und wie passiert. Aber wenn Anfänger uns lesen - arbeiten Sie in einem Unternehmen, das sich mit mobiler Entwicklung beschäftigt, werden Sie sofort darin unterrichtet, wie man alles richtig macht. Etwas mehr oder weniger Relevantes, wissen wir, durch Mundpropaganda.
- Hier haben die Anfänger die Frage, "wie man ohne Erfahrung dorthin kommt, wenn man noch kein Jahr über die Kurse verbracht hat."- Das ist eine sehr gute Frage. Ich glaube, dass viele adäquate Unternehmen Informatik für Grundkenntnisse nutzen werden, ohne einen Rahmen zu kennen. , , - -. . . , .
— Android Things, . ? , ?— — . , , , , , , .
Android Things Android, - machine learning (-, , performance-). , Android Things . , , — - , Kickstarter . Google security-.
, : , 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 » .