„Ich war gegenüber Korutin sehr negativ“: Artyom Zinnatullin über Android-Entwicklung



    Bei Android-Entwicklern genießt Artyom Zinnatullin so viel Respekt, dass Sie ein Analogon zu "Fakten über Chuck Norris" über ihn schreiben können - etwa so:

    • Artyom ist so streng, dass, wenn er es sieht, der Githab grün wird (wer von uns kann sich mit einem solchen Beitragsplan rühmen ?)
    • Artyom ist so streng, dass GIT für ihn ein sofortiger Bote ist .
    • Artyom ist so streng, dass es in seinen Anwendungen einen Podcast gibt .

    Als wir ihn auf unserer Mobius-Konferenz interviewten, war dies für den Online-Rundfunk gedacht. Da wir jedoch im Android-Chat darauf hingewiesen haben, haben wir beschlossen, dass es bei Habré viele interessieren könnte, und haben eine Textversion für Sie erstellt (auch ein Video wird erstellt).

    Wie kann man mit einem Projekt auf einer Million Codezeilen leben? Was ist der Nachteil von Kotlin Korutin? Was ist los mit Google? Wie unterscheidet sich die Entwicklung in San Francisco von der russischen? Was war der Bericht über Mobius? Unter dem Schnitt - über all das.


    Evgeni Trifonov : Bei diesem Mobius habe ich Ihren Vortrag über "Android Builds in Lyft" verpasst, aber danach sah ich im Diskussionsbereich eine Menge, die eine Frage stellte. Und ich wollte klarstellen: Aber die Mehrheit der Zuschauer arbeitet nicht in einem riesigen Projekt wie Lyft. War diese Erfahrung für sie immer noch relevant?

    Artyom : Das ist eine interessante Sache. Die anfängliche Gliederung des Berichts in meinem Kopf und die Art und Weise, wie ich ihn umgesetzt habe, sind aufgrund Ihres großen Programmausschusses sehr unterschiedlich.

    Zunächst wollte ich Ihnen erzählen, wie alles in Lyft begann und warum wir bestimmte technische Lösungen gefunden haben. Er erzählte Sergey Boishtyan vom Programmkomitee zwei Stunden. Er hörte zu und sagte: "Es ist natürlich großartig, aber Sie haben es nicht geschafft." Und am Ende wurde mir klar, dass es natürlich interessant ist, einen solchen Bericht anzuhören, aber er ist wirklich für niemanden relevant.

    Und dann habe ich es noch einmal überarbeitet und den Schwerpunkt auf fundamentale Konstruktionsansätze auf die Wahl des Montagesystems und anderer Systeme verlagert. Ich hatte nicht das Ziel zu sagen, welche Tools wir speziell verwenden. Ich möchte nicht, dass jemand sie nimmt und blind benutzt, und schrieb mir dann eindrucksvolle Briefe, dass nicht alles so funktioniert, wie ich es Ihnen gesagt habe. Ich wollte genau die Ingenieurpraxis vermitteln, wie man eine Entscheidung trifft und was meiner (natürlich subjektiven) Meinung nach wichtig ist. Daher hoffe ich, dass die Erfahrung am Ende für mehr Menschen relevant war und nicht nur "der Typ von Lyft kam heraus und sagte etwas".

    Oleg Olegchir Chirukhin : Gibt es ungewöhnliche Entscheidungen für Lyft, die für andere schwer zu treffen sind?

    Artyom: Ja natürlich. Wir haben zwei Build-Systeme gleichzeitig im Projekt, ich empfehle es absolut niemandem (lacht) .

    Es ist sehr schmerzlich zu behaupten: ständig zwei Hasen zu jagen, in beiden funktioniert etwas nicht bis zum Ende. Dies ist jedoch unser aktueller Stand. Historisch gesehen, weil ein Build-System seitens der Aufgaben still stand, mussten wir das zweite starten. Ich habe darüber gesprochen, wie man das vermeiden und richtig zu einem von ihnen migrieren kann.

    Oleg : Und was für ein Buildsystem?

    Artyom : Wir benutzen Gradle und Buck und ich sprach darüber, wie man von Google nach Bazel kommt.

    Oleg : Dies ist eine Art Bewegung in Richtung des Bösen: vom ordentlichen Gradle bis zum Bazel, bei dem selbst Abhängigkeiten nicht normal sind.

    Artyom: Jetzt ist es mehr oder weniger da. Ja, natürlich gibt es Kompromisse, und natürlich hat Gradle seine Vorteile. Es hängt alles von der Art des Projekts ab. Einige Absolventen werden mehr passen als Buck und Bazel, weil sie grundlegende Punkte haben, an denen sie nicht in demselben Modul sammeln werden, aber es wird eine Gradle geben, und für viele ist es sehr wichtig. Und es ist cool, dass Gradle das kann.

    Eine andere Sache ist, dass wenn Sie Module hinzufügen - mehr, mehr Module, achthunderttausend -, Gradle so konzipiert ist, dass es die Baugruppe an einigen Stellen linear verlangsamt. Aber mir scheint, dass Gradle alles regeln kann, wenn die Community Druck auf sie ausübt - was ich vielleicht tue. Wir werden sehen. (Anmerkung: ein paar Tage nach diesem Interview schrieb Artem einen großen Beitrag über die Probleme der Gradle.)

    Oleg:Das heißt, Bazel, nur weil Sie eine große Anzahl von Modulen unterstützen wollen?

    Artyom : Sagen wir einfach, in unserem Fall wollen wir das nicht, aber die Unterteilung des Projekts in Module lässt unser Geschäft schneller voranschreiten. Im Grunde ist das, so wie ich es verstehe, Isolation, so dass keine Spaghetti erhältlich sind, die dann schwer zu pflegen sind. Module geben mehr Kontrolle darüber, mit welchen Teilen des Codes sie interagieren. Wir haben fast eine Million Zeilen Code. Wenn es in einem Modul wäre, müsste es spaghettiert werden. Denn neben der Sprache - Java, Kotlin - ist es notwendig, etwas zu betrügen, um Aufrufe zwischen Paketen zu sperren, zwischen denen niemand sie erwartet hat. Außerdem wird es eine Frage geben, dass Gradle nicht so viel Code in einem Modul exportieren wird. Es ist nicht parallel dazu und wird schrittweise innerhalb des Moduls montiert.

    Jede Entscheidung hat Kompromisse. In unserem Fall scheint mir dies die richtige Lösung zu sein, aber es gibt auch ein Problem - dass wir momentan zwei Montagesysteme unterstützen.

    Oleg : Und was ist besser für Hunderte von Modulen: Monorepo oder viele Repositories?

    Artyom: Dies ist ein sehr heikles Thema. Wahrscheinlich ist ein Repository besser aus der Sicht, dass Sie sich nicht Gedanken über die Versionierung machen müssen und es gibt keine Abhängigkeiten, wenn Sie ein Dutzend Repositorys klonen, um eine Änderung vorzunehmen, und dann eine Pull-Anforderung und danach eine weitere zehn öffnen. „Reibung“ wird aus dem System entfernt und die Benutzer haben keine Angst, den Code zu ändern. Für sie ergibt sich die Atomizität der Änderungen: Alles ist einem Projekt verpflichtet, und Änderungen an einem Modul werden ohne ihre ausdrückliche Zustimmung automatisch auf das andere übertragen. In diesem Fall werden alle Prüfungen, die Sie automatisch in CI geschrieben haben, ausgeführt und überprüft, ob der Code kompiliert, getestet wurde und all dies.

    Oleg : Und wenn Sie nicht zu der Tatsache kommen, dass Sie, wie in einigen Chrome, die Zweige für zwei Minuten wechseln, während Sie Tee trinken?

    Artyom: Ja, natürlich gibt es eine Möglichkeit. Aber hier ist wahrscheinlich schon die Frage nach der Größe des Produkts: Muss Chrome so viel Code in sich behalten? Vielleicht lohnt es sich, einige Teile in separate Instrumente zu unterteilen, die sie bei größeren Veränderungen regelmäßig hochziehen? Dies ist wahrscheinlich eine Frage für die Organisation des Projekts. Cooles Beispiel übrigens. Ich habe eine ähnliche: Korrespondenz mit Dudes von Yandex, Browser, wo sie auch große Gags haben.

    Chrome kann in mehrere Komponenten aufgeteilt werden, und wenn Sie einen V8 nehmen, bin ich kein großer Spezialist, aber soweit ich das verstehe, könnte es ein separates Projekt sein, oder? Und warum dann die GUI über die Engine Bescheid wissen, jedesmal umbauen und darüber nachdenken, dass der Quellcode irgendwo in der Nähe liegen sollte? Bazel unterstützt dies übrigens auch.

    Im Allgemeinen unterstützen nun alle großen Build-Systeme - Gradle, Buck, Bazel - so etwas wie Verbund-Builds, wenn Sie sich beispielsweise auf einen anderen Bazel-Build beziehen. Dies ist eine schwierige Situation, aber es funktioniert trotzdem. Sie können einige Dateien aus dem Repository entfernen, um die Größe zu reduzieren. IDE zum Beispiel wird durch die Indizierung all dieser Dateien verrückt, daher möchte ich sie irgendwie von der Gesamtkomponente des Projekts trennen.

    Aber davon sind wir noch weit entfernt. Es scheint mir, dass wir immer noch ruhig fünf Jahre zurücklegen können. In der zweiminütigen Kasse werden wir wahrscheinlich nicht widerstehen. Wir haben nicht viele Leute.

    Evgeny : Hat Lyft neben den beiden Montagesystemen auch eigene Besonderheiten?

    ArtyomA: Ja, es gibt ein paar atypische Geschichten. Es geschah also, dass Leute, die in das Unternehmen kamen (von Google, Facebook, von überall), Monorepositories hassen. Deshalb haben wir in Lyft drei Mono-Repositories: Android, iOS und L5 (dies sind unsere autonomen Autos ).

    Und alles andere sind mehr als 1500 Git-Repositories: für alle Microservices, für alle Bibliotheken separat. So historisch. Es hat seinen eigenen riesigen Preis, den wir bezahlen: Es ist wirklich schwierig, Änderungen durchzusetzen. Auf der anderen Seite, wenn Sie mit jedem von ihnen arbeiten, haben Sie Instant-Git-Klon, Instant-Git-Push, alles ist sehr schnell, IDE-Indizes in einer Sekunde. Ich kann sagen, dass dies der wirklich interessante Teil ist. Von den Jungs aus San Francisco würde ich ein Mono-Repository erwarten.

    Oleg: Und wenn eines dieser einzelnen Repositorys aktualisiert wird - beispielsweise die API-Änderungen - wie wirkt sich diese Änderung auf den Rest des Unternehmens aus?

    Artyom: Es tut weh. (lacht) Nun, ich bin kein Backend-Entwickler in dem Sinne, dass ich keine Feature-Backends schreibe. Ich schreibe Infrastruktur-Backends - diese sind in der Regel ziemlich autonom.

    In der Regel ist dies nur eine Ansammlung von Rallyes, Cross-Interaktionen und dann Planung.

    Oleg: Also sind Rallyes Teil des Montagesystems? (lacht)

    Artyom : Ja, Sie müssen zuerst eine Kundgebung sammeln und dann ein Repository erstellen. Leider haben wir historisch viele dieser Mikrodienste - das ist Python, das auch seine eigenen Witze hat.

    Oleg: In eine Art Abneigung gegen Python geraten.

    Artyom : Eher keine Abneigung gegen dynamisches Tippen. Python, nicht Python - es macht keinen Unterschied, aber dynamisches Tippen ist eine wundersame Sache.



    Eugene : Und es rutschte "für ein Unternehmen aus San Francisco" aus, und es ist neugierig, diese Frage zu stellen: Was ist der Unterschied aus der Sicht der Entwicklung von Unternehmen aus San Francisco aus Unternehmen aus Russland?

    Artyom : Sehr großer Unterschied. Ich bin kein großer Fan dieser Klassifizierung, aber es scheint mir, dass es hier eine richtigere Ingenieurschule gibt.

    Oleg : Hier, wo ist es?

    Artyom: In Russland in den Ländern der ehemaligen UdSSR. Die Menschen achten mehr auf die technischen Aspekte der Komponenten ihres Systems. In den Vereinigten Staaten kommt es häufig vor, dass eine Bibliothek ein Problem löst und die Menschen nicht einmal sehen, wie sie implementiert wird. Sie sind in der Regel absolut egal, was sie verlangsamt oder falsch verwendet.

    Ich rede dort viele Leute, weil dies Teil der Arbeit ist und der allgemeine Wissensstand vielleicht vorerst niedriger ist. Es gibt etwas zu ändern. Jedes Mal, wenn eine Person aus Osteuropa kommt, wird es bei Interviews interessanter, weil die Menschen keine Angst haben, sich etwas zu widersetzen und irgendwo zu streiten. Während Kandidaten aus den Vereinigten Staaten sehr oft die Fragen überhaupt nicht beantworten können oder die Frage "Ich erinnere mich nicht daran, wann ich sie zuletzt benutzt habe". Für Fragen wie „Wie funktioniert eine HTTP-Anfrage?“ Oder „Welches Datenformat wählen Sie aus?“ Sie können keine normalen technischen Antworten geben, aber sie sagen: „Nun, ich benutze das seit fünf Jahren.“ Cool natürlich, aber der Senor zieht nicht.

    Auf der anderen Seite gibt es Projekte, die seit Jahren im Vergleich zu dem, was wir hier machen, laufen. Die Menschen stellen mehr Massenprodukte her und es gibt einfach mehr Maßstäbe. Zum Beispiel Chrome oder Uber - dort gibt es bereits mehr als tausend Module. Dies ist nur eine Skala von Problemen. Zum Beispiel in Uber unter dreihundert Android-Entwicklern. Die Frage stellt sich: warum? (lacht) Trotzdem ist es ihnen gelungen, diesen Koloss zu arbeiten, der ständig freigelassen wird. Ich würde sagen, dass solche Probleme seltener gelöst werden.

    Hier ist Yandex - ein gutes Beispiel. Ich habe einen Freund in Yandex.Maps: Eine Android-Anwendung wird von zehn Personen erstellt. Bei Google sitzen höchstwahrscheinlich hundert. Gleichzeitig bietet Yandex.Maps mehr Funktionalität. Das ist der Unterschied meiner Meinung nach.

    Eugene: Außerdem ist Dolyna mit Startups verbunden, und sie haben den Ansatz, sich schnell zu bewegen und Dinge zu brechen, und es scheint, dass dies auch Auswirkungen auf die Entwicklung haben sollte: Leben Sie am Puls der Zeit und nutzen Sie das Neueste. Es stimmt?

    Artyom : Ich habe nicht in Startups gearbeitet, Lyft ist schwer zu nennen: Es gibt bereits dreitausend Menschen, irgendwo sind mehr als tausend Ingenieure. Das heißt, es ist bereits eine etablierte Firma.

    Spitzentechnologien werden selten eingesetzt. Wenn die Technologie gefördert wird, dann ja. Wenn die Technik Nische ist, aber cool - sehr oft nicht. Bis sie auf allen Konferenzen darüber sprechen, werden nur sehr wenige Menschen es verwenden.

    Aber zur gleichen Zeit, die ich sehr liebe (in San Francisco und teilweise im Valley) - sehr viele Probleme werden aufgrund der Tatsache gelöst, dass die Unternehmen physisch nah sind. Sehr oft schreibt man jemandem in dem kleinen Kranzchen: "Lass uns zusammen mit uns oder in deinem Büro zu Mittag essen und entscheiden, einige Fragen vortragen" und dann einmal - und ein Open-Source-Projekt oder eine Pull-Anfrage erscheint in einem anderen Projekt, etwas ist fixiert.

    Was interessant ist: Menschen diskutieren sehr oft Dinge, über die die NDA im Allgemeinen nicht sprechen sollte. Aber so bewegt sich das ganze Tal, so dass jeder weiß, wohin sich der Rest bewegt, und die gesamte Branche zusammenarbeitet. Die mobilen Mitarbeiter von Lyft und Uber kommunizieren ständig über technische Dinge, da wir Open-Source-Quellen von Uber verwenden. Und natürlich gibt es direkt Hardcore-Experten für einige Technologien. Das ist auch cool: Sie können einfach mit ihnen kreuzen.

    Ich liebe das, und es fehlte mir in einigen Städten, in denen ich lebte. Hier in St. Petersburg gab es eine sehr coole Java User Group (ich weiß nicht, wie es jetzt ist): Sie kommen nach der Arbeit und Shipilev bringt Ihnen das Gehirn und etwas ist gut!

    Und da taucht es wieder auf: Zum Beispiel gibt es auch eine eigene Java User Group, und von Oracle gibt es oft Typen, die ein paar neue reaktive JDBC aufgeschrieben haben. Und Sie sitzen und streiten, denn im Frühjahr gibt es einige Projekt-Reactor-Blei oder Reactive-Blei, es gibt eine hitzige Diskussion, und das ist großartig.

    Oleg : Ich werde nach etwas anderem fragen: Ich habe mir das Mainframer- Repository angesehen und Rust wird dort verwendet. Warum steht das alles nicht im gesegneten Dzhavka, sondern in irgendeinem Rust?

    ArtyomA: Ich habe mich kürzlich in die Richtung gewehrt, dass das Programm über ein Minimum an Ressourcen verfügen sollte. Das heißt, ich möchte sehr nahe daran sein, wie Eisen Bytes verdaut. Und in Java passiert eine Menge Dinge (ich spreche nicht einmal über die Garbage Collection), also JIT und all das. Ich finde es sehr gut, dass Java sich jetzt der Tatsache zuwendet, dass es mehr Vorausberechnungen geben wird. Es scheint mir, dass es sehr cool sein wird, den Start des Mikroservice über das, was Sie aus dem Cache heruntergeladen haben, seine vorzeitige Kompilierung zu starten, die anfangs auf anderen Computern vorkam, und ihn sehr schnell zu starten, ohne sich aufzuwärmen. Das ist großartig, aber Java hat einen Preis. Ich kann Leute, die ein iOS-Projekt erstellen, nicht einfach nach Java fragen.

    Ursprünglich wurde Mainframer im Bash-Dialekt geschrieben. Aber ich wollte es in die Systemsprache umschreiben, um normales Multithreading zu erhalten, die Möglichkeit, normale Unit-Tests zu schreiben, und nicht nur Integrationstests zusätzlich zum Dienstprogramm ...

    Oleg : Und man könnte zum Beispiel Python nehmen.

    Artyom : Ja. Aber dann würde sich die Frage mit der Tatsache stellen, dass es sich erstens um dynamisches Typisieren und zweitens um ...

    Oleg : Also auch in Bash um dynamische Typisierung handelt.

    Artyom: Also wollte ich umschreiben. Abgesehen davon gibt es ein Problem mit der Tatsache, dass Python jetzt zwei ist: In MacOS ist der Standardwert der zweite und in fast jedem Linux der dritte. Es gibt alle möglichen Witze. Wenn ich irgendeine Abhängigkeit herstellen muss, werde ich die Leute bitten, Pip zu laufen? Oder muss ich es schlagen?

    Ich wollte eine Systemsprache, die keine Abhängigkeiten erfordert, damit ich eine Binärdatei schreiben kann, die bedingt weniger als ein Megabyte wiegt und mit minimalem Aufwand arbeitet.

    Oleg : Es war möglich, Golang mitzunehmen, zumindest gibt es einen Müllsammler.

    Artem : Das ist genau der Grund, warum ich Rust ausprobieren wollte. Und verdient. Außerdem ist Golang mit Generika irgendwie traurig.

    Eugene: Sobald wir angefangen haben, über Sprachen zu sprechen ... Im Zusammenhang mit der Android-Entwicklung war die Frage "Kotlin oder Java" bereits müde, aber wir stellen sie trotzdem, um mit der nächsten Frage fortzufahren.

    Artyom : Na ja, natürlich Kotlin.

    Eugene : Nun, die Frage, die wirklich interessiert. Vor kurzem wurde Kortlin in Kotlin stabil, und die Stimmen "Hurra, lass uns RxJava verlassen" sind zu hören. Wenn ich also eine Person vor mir sehe, die RxJava sehr nahe steht, möchte ich sofort nach seiner Meinung über die Korutinas fragen.

    Artyom : Ich war Korutin gegenüber sehr negativ. Im Prinzip ist es immer noch überwiegend negativ, aber dies hat ein sehr langes Gespräch mit Roma Elizarov , die an ihnen arbeitet, zum Teil geändert .

    Als Benutzer von Programmen möchte ich, dass diese so wenig wie möglich blockieren, um Ressourcen so richtig wie möglich zu nutzen. Damit meine ich Parallelität und die Tatsache, dass sie die richtigen Betriebssystem-APIs für nicht blockierende Aufrufe des Netzwerks oder von Dateien verwenden - es gibt viele Probleme mit Betriebssystemen, aber trotzdem gibt es solche APIs. Was genau ist es gelöst? Als Benutzer ist es mir egal, solange die Entwickler dieses Problem lösen, damit sie sich wohl fühlen. Damit habe ich keine großen Probleme. Und das ist die Vision von Roma Elizarov. Nach diesem Gespräch ließ ich irgendwie los.

    Davor mag ich meinen Freund Arthur DremovNach einigen Jahren der Verwendung von Java in der Produktion schien es ein Rückschritt zu sein: Der Code wird wieder zwingend, unrein, das Verständnis für die Pipeline verloren, er wird wieder zu einem Durcheinander, das der Compiler für Sie in ein asynchrones Durcheinander verwandelt.

    Ich benutze keine Korutine, aber alle Beispiele, die ich mir jetzt anschaue, haben einen strukturierten Ansatz gefunden, wenn Sie überhaupt nicht sehen, welcher Code aus diesem Code Korutin ist. Offen gesagt, es ist sehr beängstigend, es anzusehen. Da ich die Pull-Anforderung auf GitHub öffne, werden einige Methoden zum Laden des Bildes und des Profils aufgerufen. Eine davon geht online, die andere geht an die lokale SQLite. Nun kann sich die lokale SQLite ruhig als blockierend erweisen. Im Code sehe ich es nicht, weil die Corutines so gemacht werden, dass Sie es nicht sehen. Vielleicht ist das gut, aber für mich ist dies bisher ein Minus an Design, denn in den Rx-Ansätzen ist es offensichtlich: Sie verstehen, das ist Teil der synchronen Pipeline oder nicht.

    Vielleicht ist dies mein einziger Anspruch an die Corintines: Ich möchte sehen, wann ich asynchron bin und wann nicht. Im Idealfall möchte ich, dass die Benutzer mehr funktionalen Code schreiben, wenn kleine wiederverwendbare oder zumindest überprüfbare Teile vorhanden sind, die mit anderen kombiniert werden. Und wir kommen zurück auf die Tatsache, dass alles logisch inline ist, und der Compiler pickt es einfach.

    Oleg : Gib mir ein bisschen Poppling. Legacy-Code ist viel mehr als neu. Und wenn wir einige Dinge wie das Arbeiten mit dem Netzwerk, das Arbeiten mit Dateien usw. angehen, wird niemand schnell alles neu schreiben, z. B. mit RxJava. Und wenn wir Autokreise haben, können wir zum Beispiel alle Syscalls verfolgen, automatisch einwickeln und sie zu einem Schloss dort zum Parkplatz schicken.

    Artyom: In jedem Fall müssen Sie jedoch Funktionen aus dem Kontext von Corutin aufrufen. Aber das ist ein interessanter Gedanke, ja.

    Oleg : Vielleicht verbinden sie sich irgendwie? Die Top-Level-API wird auf RxJava und die Low-Level-API auf Corutinas sein.

    Artyom: Ja, es gibt jetzt solche Verschiebungen. Aber dann stellt sich die Frage, denn im Moment kann RxJava alles tun, was die Korutinas tun, und die Korutins können nicht alles, was RxJava tut. Das heißt, die erste Technologie kann die zweite absorbieren und die zweite - nicht. Und höchstwahrscheinlich wird es Fortschritte in Richtung auf die Tatsache geben, dass es auf Kotlin auf der Korutin einige plattformübergreifende Rx gibt. Dies ist jedoch eine andere Denkweise. Auf diese Weise können Sie jede Karte nutzen oder Streams erstellen und darauf schreiben. Und selbst die Java-Community des Unternehmens hat bereits zugestimmt und Streams geschrieben, weil sie ausdrucksvoller ist. Und mit Korutinami gehen wir jetzt in die entgegengesetzte Richtung.

    Und es scheint, dass Korutin für Kotlin eine Ergänzung ist. Soweit ich es verstehe, ist dies für Sprachen wie Go die Basis, ursprünglich ein Teil des Typsystems, und alle APIs, die sie bereitstellen, funktionieren gleich: Die Standardbibliothek verwendet Cortinas sehr häufig. Und in Ihrer Situation, Oleg, stellt sich heraus, dass Sie Code schreiben, der für Sie Erbe sein kann, aber asynchron ist, und das ist cool. Was wir jetzt in Java und in Kotlin bekommen, ist ein Erbe, und Sie verstehen nicht mehr, ob es asynchron oder nicht asynchron ist. Eins ist besser als ein anderes. Es ist besser, etwas zu verstehen, was passiert.

    Aber wie ich zu Beginn sagte, freue ich mich als Benutzer der Programme. Je mehr Tools für mehr Menschen geeignet sind, um ihnen mehr korrekte Programme zu schreiben, desto mehr bin ich zufrieden. Daher habe ich hier absolut keine Beschwerden.



    Eugene : Und die letzte Frage ist ganz allgemein. Nach der Kritik an Korutin, mit der viele sehr zufrieden sind, möchte ich fragen: Was sind die Hauptprobleme der modernen Android-Entwicklung? Ich frage mich, ob dies auch gegen die Meinungen anderer Menschen gehen wird.

    Artyom: Eine interessante Frage ... Es ist schwer zu beantworten. Ich würde sagen, dass es grundsätzlich keine besonderen Probleme bei der Android-Entwicklung gibt. Es gibt eine sehr große Anzahl von Tools, die Sie verwenden können und qualitativ hochwertige Programme erhalten. Das Problem besteht darin, dass die Skalierbarkeit für ein großes Team schwierig ist: Die Mitarbeiter müssen genau verstehen, wie dieses Tool verwendet wird. Und dabei verliert RxJava sehr viel an den Corintines, weil es sehr einfach ist, es absolut falsch zu verwenden: für einige kleine asynchrone Dinge und nicht, um Logik überall in den Streams auszudrücken. In dieser Hinsicht wird die Korruption höchstwahrscheinlich besser gehen.

    Ich finde es interessant, mit iOS zu vergleichen. Ich schäme mich, dies zu sagen, aber in unseren Lyft iOS-Entwicklern werden erst in diesem Jahr Abhängigkeitsinjektion und RxSwift eingeführt. Und jetzt kommt der 2019. Ich weiß mit Sicherheit, dass die iOS-Befehle, bei denen dies nicht der Fall ist, seit langem moderne Ansätze verwenden, sauber, das ist alles. Aber es scheint mir, Android ist in dieser Hinsicht weit von der schlechtesten Plattform entfernt.

    Vielleicht gefällt mir nicht das, was Google gerade tut. Ihre Position war lange Zeit: "Wir sind nicht der Meinung, verwenden Sie, was Sie wollen: Hier ist der Rahmen für Sie, und wie Sie ihn verwenden, ist für uns nicht besonders wichtig". Einen Teil der Community haben sie lange Zeit getreten - und meiner Meinung nach umsonst.

    Es war eine goldene Zeit, als Sie sagen könnten "RxJava ist eine Lösung, weil ..." Und jetzt kommen die Leute und sagen: "Nein, wir werden LiveData verwenden". Sie beginnen zu fragen, warum - sie verliert in jeder Hinsicht sowohl RxJava als auch Korutin und alles andere. Dennoch hielt Google die Community für wichtig.

    Viele in der Community werden jetzt sagen: "Es ist cool, dass Google MVVM fördert." Und für sie ist die dritte Frage, dass diese MVVM absolut schief und falsch ist und meiner Meinung nach gegen alle Prinzipien verstößt, was MVVM sein sollte. Und viele Projekte haben bereits zu den Empfehlungen von Google gewechselt.

    Es scheint mir, dass sie nicht das richtige Gefühl haben, wo der Umfang der Projekte endet. Sehr oft streut die falsche Architektur über mehrere Projekte hinweg.

    Aber gleichzeitig gibt es einige sehr coole Arbeit: Zum Beispiel ist Room sehr gut gemacht und in der Regel eine sehr coole Bibliothek. Jede Architekturkomponente ist eine sehr kontroverse Reihe von Dingen, die bereits vor fünf Jahren in der Community implementiert wurden. Warum kam Google so spät und mit einer krummen Lösung? Dies sind die Momente, die mich anspannen.

    Yevgeny: Ich habe den Verdacht, dass viele das brennende Verlangen haben, diesen Ort zu beanstanden. Nun, das kannst du dann in den Kommentaren machen. Danke für die Antworten!

    Artyom: Sehr interessante Fragen.

    Der nächste Mobius findet vom 22. bis 23. Mai in St. Petersburg statt . Nun ist sein Programm noch nicht angekündigt, aber dies ist der vorteilhafteste Moment für den Kauf eines Tickets: Die Ticketpreise werden bereits am 1. Februar steigen. Und da das Programm noch nicht abgeschlossen ist, eignet sich der Moment auch für den Einstieg: Wir nehmen Bewerbungen für Berichte entgegen. Alle Informationen zur Konferenz und die Tickets finden Sie auf der Website .

    Jetzt auch beliebt: