Im Vorfeld der AppsConf 2018 haben wir Spezialisten großer Unternehmen zu den Besonderheiten und Prozessen großer Teams befragt, die an der Entwicklung mobiler Anwendungen beteiligt sind. Welche Arbeitsansätze werden verwendet, welche Fallstricke erwarten Ruderer, die in einer riesigen Galeere ankommen. Ob die ausländische Herkunft des Unternehmens die Arbeitsprozesse prägt - lesen Sie alles unter dem Strich.
Philip Uvarov, Android-Entwickler bei Spotify. Das Unternehmen arbeitet seit sechs Monaten in einem der Plattformteams, die andere Entwickler bei Spotify unterstützen. Lebt in Schweden. Vor Spotify arbeitete er bei einem schwedischen Startup und noch früher bei Avito.
Artyom Olkov, leitender IOS-Entwickler bei Odnoklassniki. Derzeit leitet er die iOS-Entwicklung eines der Produkte. Neben der Entwicklung selbst ist er für Architektur, Design, Aufgabenverteilung, Koordination mit Design, Backend-APIs usw. verantwortlich. Insgesamt hat Odnoklassniki jetzt etwa 60 mobile Ingenieure, die in kleinere Teams aufgeteilt sind. Das Team von Artem - 11 Personen.
Maxim Efimov, Senior Software Engineer bei Uber. Er arbeitet seit zwei Jahren in der Firma und beschäftigt sich mit der Android-Entwicklung. Es ist Teil des Fahrerzahlungsteams, das in der Uber-Passagieranwendung alles verarbeitet, was mit Zahlungen zu tun hat. Zuvor entwickelte er für Android in anderen Unternehmen - hauptsächlich auf Bestellung und noch früher - und schrieb in C ++ (Serverlösungen für SCADA-Systeme). In Uber gibt es als Teil der Zahlungsabteilung mehrere ähnliche Teams für andere Anwendungen sowie Infrastrukturteams - insgesamt mehrere Dutzend Teams.
Evgeny Suworow, Leiter Entwicklung mobiler Einheiten bei Avito: Das Unternehmen entwickelt seit etwa acht Jahren mobile Anwendungen. Ich habe Spiele ausprobiert, war freiberuflich tätig, arbeitete in Outsourcing-Unternehmen in einem großen Unternehmen und wechselte danach zur Produktentwicklung.
Beginnen wir mit den Funktionen. Was ist der Unterschied zwischen der Arbeit von Teams mit einer großen Anzahl von Entwicklern im Unternehmen?Artem Olkov (Odnoklassniki): Meiner Meinung nach hängen die Besonderheiten nicht mit der Größe des Unternehmens zusammen, sondern damit, wie die Prozesse darin angeordnet sind und welche Rolle das Team in diesen Prozessen spielt. Grob gesagt, wenn Ihr Team die mobile Plattform herstellt, auf der andere Anwendungen oder Dienste des Unternehmens basieren, werden 1000 Anfragen aus verschiedenen Ecken dorthin fliegen und ohne einen guten Produktmanager wird die Entwicklung ertrinken. Wenn das Team einen eigenständigen Service ohne komplexe Integrationen bereitstellt, sieht der Prozess viel einfacher aus.
Maxim Efimov (Uber): Meiner Meinung nach ist die Arbeitsgeschwindigkeit das charakteristischste Merkmal.
Kleine Teams arbeiten im Prinzip viel schneller. Gleichzeitig haben große Teams natürlich ein Endbruttoprodukt des Entwicklers, da eine ganze Gruppe von Menschen ungefähr das Gleiche tut. Daraus folgt eine andere Sichtweise, wie Projekte im Allgemeinen umgesetzt werden.
In kleinen Unternehmen passen wir oft bedingt bis zu einem Tag oder bis zu einer Woche. Wir können alles im Voraus berechnen und planen. In großen Teams ist dies schwierig, da alles an eine große Anzahl von Personen gebunden ist. Daher ist der Planungsansatz etwas anders. Projekte werden mit bestimmten zeitlichen Toleranzen durchgeführt, und die Qualität und die von uns erstellten Funktionen sind von größter Bedeutung. Und erst danach muss die Frist eingehalten werden.
Ein weiterer interessanter Punkt: wie die Teams miteinander übereinstimmen. Wenn fünf bis zehn Personen an dem Projekt arbeiten, können sie problemlos im Besprechungsraum zusammengestellt werden und nach zwei bis drei Stunden alle Probleme lösen. Und Sie können noch weiter gehen, um das Projekt durchzuführen. Aber wenn Hunderte von Menschen an dem Projekt beteiligt sind, wird dies nicht funktionieren. Bei Uber gibt es bestimmte Kommunikationsmechanismen, die es Teams ermöglichen, sich nicht gegenseitig zu stören, sich effektiv zu integrieren usw. In kleinen Unternehmen ist dies im Prinzip nicht der Fall.
Philip Uvarov (Spotify) : Ich denke, das Hauptmerkmal ist, dass ich nicht alle Android-Entwickler persönlich kenne. Und wir haben auch sehr geteilte Verantwortlichkeiten. Auf diese Weise können Sie immer im Kontext Ihrer Aktivitäten stehen und schnell genug Produkte in Ihre Richtung liefern.
Wie synchronisiert sich Ihr Team mit anderen im Unternehmen?Evgeny Suworow (Avito): Unsere Teams sind durch eine mobile Anwendung verbunden - Avito. Alle von ihnen tragen zu diesem Produkt bei, dh dem Synchronisationspunkt in unserer Codebasis und Funktionalität.
Philip Uvarov (Spotify) : Wir haben funktionsübergreifende Teams, die sich mit bestimmten Themen befassen (z. B. wie wir Analysen für mobile Kunden entwickeln), die in einer großen Abteilung zusammengefasst sind - wir nennen sie „Stamm“ (Stamm). In der Regel sind die Teams innerhalb eines Stammes sehr eng miteinander verbunden, sie haben einen aktiven Erfahrungsaustausch. Außerdem haben wir natürlich Kunden - dies sind andere Entwickler, daher unterstützen wir die Lösungen, die wir für sie erstellen.
Maxim Efimov (Uber) : Wir haben kleine Teams mit jeweils nicht mehr als 20 Personen. Sie sind in Struktureinheiten zusammengefasst, die für große Bereiche verantwortlich sind, beispielsweise eine mobile Anwendung. Gleichzeitig sind die Teams selbst ziemlich autonom, denn wenn wir alles auf ein einziges Kontrollsystem mit direkter Unterordnung reduzieren, erhalten wir ein sehr ineffizientes System.
Die allgemeine Produktidee wird über Produktmanager oder Eigentümer an einzelne Teams weitergegeben. Es gibt eine separate Struktur, die diese Menschen zusammenbringt und hilft, ein Verständnis dafür aufzubauen, wie und wo wir uns bewegen. Auf einer höheren Ebene können strategische Ziele wie die Sorge um die Sicherheit der Fahrgäste definiert werden. Nun, die Details werden ein bis zwei Ebenen weiter unten gelöst. Zum Beispiel haben wir bestimmte Sicherheitsmechanismen in Ländern, in denen die Leute meistens Bargeld verwenden, um zu bezahlen.
Artem Olkov (Odnoklassniki): Wir haben einen separaten Dienst. Nehmen wir also an, wir sind ein Startup in einem großen Unternehmen. Natürlich leben wir in derselben Infrastruktur. Und in allem anderen sind wir sehr getrennt. Selbst im Rahmen der Integration verwenden wir häufig die öffentliche API unserer eigenen Tools.
Gibt es typische Probleme für große Teams? Womit musst du umgehen?Evgeny Suworow (Avito) : Meiner Meinung nach sind vor allem Prozesse in einem großen Team betroffen.
Alle Jungs sind in der Regel erfahren, auch Junioren können technische Probleme lösen. Probleme mit Prozessen können jedoch leicht alle verlangsamen. Daher ist es besser, Prozesse zu automatisieren.
Und das bedeutet hochwertige kontinuierliche Integration, kontinuierliche Lieferung und Testautomatisierung.
Philip Uvarov (Spotify) : Ich denke, das größte Problem ist die Verbreitung von Wissen innerhalb des Unternehmens. Ich habe möglicherweise keine Ahnung, was in einigen entfernten Teams passiert. Und das Gleiche gilt in die entgegengesetzte Richtung: Viele Teams haben keine Ahnung, dass wir ein Analyseteam bei Spotify haben. Hier ist die Skala zu spüren.
Der zweite Punkt ist die Geschwindigkeit, mit der innovative Entscheidungen getroffen werden: Anpassung des gleichen Kotlin und anderer neuer Technologien. Es ist eine Sache, fünf Entwicklern zu sagen: "Ab heute schreiben wir über Kotlin", aber es ist eine ganz andere, es 100 Entwicklern zu sagen. Es gibt eine riesige Infrastruktur, die übersetzt werden muss, um diese Innovationen (CI usw.) irgendwie zu unterstützen.
Artem Olkov (Odnoklassniki): Ja, es gibt wirklich zwei Probleme: den Wissenstransfer und die Koordinierung von Maßnahmen, einschließlich der Modernisierung.
Haben große Unternehmen bewährte Möglichkeiten, um diese Probleme zu lösen?Philip Uvarov (Spotify) : Um das erste Problem zu lösen - Wissen zu teilen - haben wir so etwas wie Gilden. Dies ist eine Gruppe von Entwicklern nach Funktionen, zum Beispiel die Android-Gilde, die alle zwei Wochen einige Veranstaltungen veranstaltet: Präsentationen, Mittagessen, bei denen Sie drängende Probleme besprechen oder etwas teilen können usw. Wir haben auch wieder Gilden finden interne Konferenzen statt. Außerdem gibt es Mailinglisten usw. Ein einfaches menschliches Problem bleibt bestehen: Es ist schwierig, mit all dem Schritt zu halten.
Ich möchte das interne Training (Fortbildung) als separate Zeile hervorheben. Wir haben eine eigene Datenuniversität, an der Sie lernen können, wie man Dateningenieur wird. Jetzt denken Kollegen darüber nach, dasselbe Schema für mobiles Lernen zu entwickeln.
Artem Olkov (Klassenkameraden): Wir haben keine ausgesprochenen Gilden.
Auf die eine oder andere Weise kreuzen sich die Jungs, die durch eine Aufgabe vereint sind, bei verschiedenen Treffen - sie kennen sich, kommunizieren in einem Raucherzimmer oder beim Mittagessen. Es gibt separate Chatrooms, zum Beispiel nur für iOS-Spitznamen. Innerhalb des Teams ist das Problem natürlich einfacher zu lösen - wir sitzen alle am selben "Gänseblümchen".
Wenn Sie Fragen haben, heben Sie die Hand, winken Sie der gewünschten zu - und er antwortet Ihnen. Um Wissen zu übertragen, nutzen wir auch 15-minütige Morgenrallyes, bei denen jeder erzählt, was, wie, warum und warum. Es gibt noch eine bestimmte Dokumentationsebene, in der die wichtigsten Punkte behandelt werden.
Das zweite Problem - die Koordinierung der Maßnahmen - wird durch ein kompetentes Management gelöst.
Maxim Efimov (Uber): Eigentlich sehe ich das Problem beim gleichen Wissensaustausch nicht. Ich sehe, dass der Freigabemechanismus selbst anders ist. In kleinen Teams wird dies sowieso einfach gemacht. Versammelt - geredet. Und wir haben bequeme Prozesse, mit denen wir alles so organisieren können, dass es funktioniert. Ich werde übrigens in meiner
Rede auf der AppsConf 2018 darüber sprechen. Die Idee ist, dass in unserem Unternehmen fast die gesamte Entwicklung ziemlich transparent ist. Leute aus jedem Team können sich ansehen, was andere Entwickler tun, und einige davon zu Hause verwenden.
Evgeny Suworow (Avito): Wir organisieren auch zweimal pro Woche Treffen. Wir lieben Automatisierung, und diese Aufgabe ist auch automatisiert. Es gibt einen Prozess, bei dem die Leute während der Woche Themen ansprechen, über die sie auf einer Hauptversammlung von iOS- oder Android-Entwicklern sprechen möchten. Und wenn es eine Vorladung gibt, werden wir. Während der Besprechungen sprechen Produktteams über die Funktionen, die sie im Produkt implementiert haben, da es sonst schwierig ist, den Überblick über alles zu behalten, was passiert.
Wir haben uns von Anfang an getroffen, aber mit dem Wachstum des Unternehmens wurden diese Treffen am relevantesten.
Außerdem gibt es Chatrooms, in denen Sie bestimmte Themen besprechen können.
Nach welchem Prinzip ist es sinnvoll, viele Entwickler in einem Unternehmen zu unterteilen - nach Plattform, Funktionalität oder auf andere Weise?Artem Olkov (Odnoklassniki): Es kommt immer noch darauf an, was Sie tun und wie Sie Geld verdienen.
Theoretisch kann ich mir die Struktur eines Outsourcing-Unternehmens vorstellen, in dem beispielsweise ein Geschäftsbereich auf Plattformbasis arbeiten wird. Aber für ein Lebensmittelunternehmen kann ich mir kaum eine andere Form der Aufteilung vorstellen, außer für funktionale Teams.
Denn wenn Sie alle iOS-Spitznamen auf einen Haufen legen und Aufgaben in sie werfen, ohne eine sehr kurze Kommunikationsbrücke mit Design, Backend oder Test zu haben, müssen Sie zu viel Zeit für die Koordination aufwenden.
Philip Uvarov (Spotify) : Wir alle teilen das Produkt. Unser Team beschäftigt sich beispielsweise mit Analysen und umfasst iOS, Backend-Entwickler und viele andere. Meiner Meinung nach ist dies eine sehr vernünftige Aufteilung der Teams, was ebenfalls zu bestimmten Problemen führt, aber gleichzeitig in einem solchen Maßstab gut funktioniert.
Maxim Efimov (Uber): Es scheint mir, dass die Idee, Teams nach Plattformen - iOS, Android, Backend - in großem Maßstab aufzuteilen, nicht sehr gut funktionieren wird. Es trennt Entwickler ziemlich stark voneinander und infolgedessen kostet die Synchronisation beispielsweise von zwei mobilen Anwendungen für verschiedene Plattformen viel mehr. Und der Gewinn aus der Tatsache, dass die Leute im Team nur Leute von ihrer Plattform sehen, wie es mir scheint, ist nicht so groß. Ja, Wissen zu teilen ist einfacher, aber lohnt es sich? Ich denke nicht.
Außerdem scheint mir die Idee interessant zu sein, dass einige Teams grundlegende Dinge tun, die alle anderen verwenden, z. B. einige Schaltflächen, Listen, Texteingabefelder.
Evgeny Suworow (Avito): Ich stimme zu
. Eine solche Struktur ist ziemlich erfolgreich und wir haben sie erst kürzlich in unserem Avito implementiert, zumindest im Lebensmittelbereich des Geschäfts.
Unser Team wurde wahrscheinlich groß, als wir fünf Entwickler hatten - da selbst mit einer solchen Menge die Selbstorganisation schwierig war. Es wurde für die Jungs schwieriger, ein Merkmal zu sehen, sie mussten sie irgendwie trennen, sie in verschiedenen Winkeln züchten, in verschiedenen Merkmalen. Meinungsverschiedenheiten begannen in architektonischen und anderen Angelegenheiten, und die Kommunikation wurde komplizierter.
Irgendwann hatte Avito zwei große Teams - iOS- und Android-Entwicklung mit jeweils 15 Mitarbeitern. Und zu diesem Zeitpunkt begannen wir, in Produktteams aufzubrechen: Die Gruppen „Käufererfahrung“, „Verkäufererfahrung“, Instant Messenger, Lieferung usw. stachen heraus. Dies löste das Problem mit Prioritäten. Zuvor kamen viele Projektmanager mit Feature-Anfragen zu Teams, und für sie hatte jedes dieser Features Priorität Nummer eins. Infolgedessen haben wir 20 Projekte, deren übergreifende Prioritäten nicht klar sind. Die Eltern mussten dies manuell verwalten. Nachdem multifunktionale Teams hervorgehoben wurden, von denen jedes seine eigene Entwicklungspipeline, seine Prioritäten und Ressourcen hat, wurde alles einfacher.
Gleichzeitig haben wir immer noch kleine Plattformteams, die, wie wir es nennen, „horizontale“ Entscheidungen treffen, die für alle Produktteams gelten.
Finden häufig Teamumstrukturierungen statt?Philip Uvarov (Spotify) : Jede Woche findet eine Bewegung statt. In unserem Unternehmen sind die Teams klein und autonom. Auf Wunsch können Sie ganz einfach von einem zum anderen wechseln. Wie oft dies passiert, hängt vom Team und der Richtung ab, in der Sie arbeiten. Wo ich arbeite, ist das nicht ausgesprochen. Aber Spotify ist berühmt für die Tatsache, dass wir an Agilität arbeiten und in vielerlei Hinsicht Dinge wie OKR usw. von uns gingen. Daher hat das Management des Unternehmens keine Angst davor, Prioritäten zu ändern, wenn es plötzlich merkt, dass etwas nicht funktioniert. Wir wechseln einfach zu etwas anderem.
Maxim Efimov (Uber): Wir hatten umfassende Reformen, die hauptsächlich auf das sehr schnelle Wachstum des Amsterdamer Büros zurückzuführen waren. Im Laufe des Jahres hat sich die Zahl der Mitarbeiter fast verdoppelt. Die Teams, in denen Mitarbeiter eingestellt wurden, wurden sehr groß, und es war für einen Manager schwierig, eine solche Struktur zu verwalten. In dieser Hinsicht wurden die Teams einfach in mehrere "Unterbefehle" unterteilt, von denen jeder in einem engeren Bereich tätig war. Es scheint mir, dass dies ein natürlicher Prozess ist.
Stimmen Sie der Idee zu, dass es sich in einem großen Team lohnt, die Einstellung überqualifizierter Junioren und Senioren zu vermeiden, damit die Qualität des Codes nicht beeinträchtigt wird?Philip Uvarov (Spotify) : Ich denke weder der eine noch der andere. Jedes Jahr rekrutiert Spotify im Sommer eine ganze Reihe von Hochschulabsolventen (einige der Personen nach der Praxis erhalten eine Einladung zur Arbeit). Ebenso nehmen wir leicht Menschen mit mehreren Doktortiteln.
Technische Fähigkeiten sind cool, aber Sie können sie unterrichten. Wenn eine Person nicht weiß, wie man in einem Team arbeitet, ist dies äußerst schwierig. Daher widmen solche Unternehmen Soft Skills fast mehr Aufmerksamkeit.
Und damit die Qualität nicht darunter leidet, brauchen wir gute Interviews, mit denen wir Entwickler auswählen können, die nicht unter einem bestimmten Grundniveau liegen.
Maxim Efimov (Uber): Wir gehen von einem etwas anderen Prinzip aus. Wir haben ein wünschenswertes Verhältnis von erfahrenen Entwicklern und Juni. Nur damit es keine Situation gibt, in der es eine Menge Dzhuns gibt, und es niemanden gibt, der ihnen hilft und erklärt, wie man arbeitet. Deshalb versuchen wir, ein Gleichgewicht zu halten.
Sich an das Prinzip zu halten, "nicht zu viele Lords zu rekrutieren", sieht keinen Sinn. Einen Lord zu finden ist eine ziemlich schwierige Aufgabe. Es gibt viele Unternehmen auf dem Markt, und der Wettbewerb um Entwickler ist hart. Menschen mit Erfahrung lassen sich an fast jedem Ort erfolgreich nieder, daher ist es etwas unrealistisch, heute qualifiziertes Personal aufzugeben und es dann morgen einzustellen. Diese Leute werden nicht sitzen und warten, bis wir sie einladen wollen. Und in meiner Praxis ist es kein Problem, einen Platz im Unternehmen zu finden, wenn jemand über gute Kompetenzen verfügt. Aber wir müssen von einer bestimmten Situation ausgehen. Wir müssen eine Entscheidung treffen, abhängig von den Ambitionen, die jede Person im Team hat, auf bevorstehende Projekte schauen, ob wir sie selbst herausholen können, wen wir brauchen. Das heißt, es ist notwendig, zur Planung auf niedriger Ebene überzugehen.
Evgeny Suworow (Avito): Meiner Meinung nach sollten Sie bei der Rekrutierung von Senioren keine Angst haben, dass sie einen eigenen König im Kopf haben oder nicht gehorchen.
In unserem Unternehmen bieten die Entwickler selbst Möglichkeiten zur Lösung bestimmter Probleme. Und Senioren haben oft hochwertige Lösungen. Sie haben Erfahrung, daher können Probleme mit ihrer Teilnahme schneller gelöst werden. Es gibt noch ein anderes Problem: Ihre Aufgaben scheinen Senioren möglicherweise nicht interessant oder ehrgeizig zu sein.
Junioren müssen auch individuell angesprochen werden. Als wir noch ein Team waren, gab es von Zeit zu Zeit das intuitive Gefühl, dass das Team einen weiteren Juni ausschalten könnte. Und in diesem Moment war es möglich, einen wunderbaren, ehrgeizigen Mann zu nehmen, der schnell zum Qualitätsingenieur heranwuchs. In einem Team mit gut etablierten Prozessen ist das Training sehr schnell. Ja, und die Jones sind anders - einige kommen mit brennenden Augen nach der Universität, aber sie können nichts tun, während andere über sieben Jahre Backend-Erfahrung verfügen. Sie haben einfach auf mobile Anwendungen umgestellt.
Das heißt, wir haben keine Angst vor Junioren, aber wir konzentrieren uns auf die Gefühle des Teams - ob es es braucht oder nicht.
Planung, Synchronisation, Aufgabenverteilung
Benötigt die Planung und Synchronisierung von Entwicklern in einem großen Unternehmen (auch in kleinen Teams) viel Energie?Philip Uvarov (Spotify) : Dies ist nur die Aufteilung der Teams nach Produkt und nicht nach Funktion: Wir planen unser kleines Produkt nur innerhalb des Unternehmens und es ist uns oft egal, was der Rest der Millionen Entwickler tut.
Artem Olkov (Odnoklassniki): Hier kann ich nur über unser spezielles Team sprechen. Wir haben mit der Entwicklung begonnen, und dies gibt gewisse Ablässe - ermöglicht es Ihnen, freier zu sein. Momentan haben wir nur einmal pro Woche tägliche 15-minütige Rallyes zum aktuellen Status und zum stündlichen Schließen des vorherigen / der Planung des nächsten Sprints. Alles andere wird auf persönlicher Basis entschieden.
Maxim Efimov (Uber): In unserem Fall - nicht sehr groß. Vielleicht ist es 1,5 bis 2 Mal mehr, als es mich beschäftigt hat, als ich am Outsourcing gearbeitet habe.
Es stimmt, es gibt einige Prozesse im Unternehmen, wie z. B. die Codeüberprüfung, die die Entwicklung behindern. Grob gesagt kann es nur einige Zeit dauern, bis ein Team, das für den Code verantwortlich ist, Ihr Commit überprüft. Ich glaube aber nicht, dass sich dies auf die Synchronisationsgebühr bezieht. Es geht mehr darum, wie dieses ganze Schema auf einer niedrigen Ebene eingerichtet ist - wer wen überarbeitet, wie das Warten angeordnet ist usw.
Evgeny Suworow (Avito): Wir haben das Synchronisationsproblem zunächst mit häufigen Releases gelöst. Infolgedessen dauert die Synchronisation selbst jetzt ein wenig. Alles ist fast automatisiert.
Muss ich Aufgaben auf besondere Weise verteilen, damit die Qualität des Codes nicht beeinträchtigt wird?Philip Uvarov (Spotify) : In großen Teams ist es sinnvoll, das Produkt nach Verantwortungsbereichen zu vertreiben. Es wird also immer Menschen geben, die sich ihnen verantwortungsbewusst nähern, weil sie später damit leben werden. Ihr Kontext ändert sich nicht, d.h. , ( 10 , 5 , ).
« », - , backend- .
(Avito): , code review. , backend- — Python, PHP, Go — Avito. , .. , — .
- , ?(): , . , , , — : , , , , .
(Avito): , , — , , .
, . , - , . . .
backend- , — — . , .
- / ? ?(Spotify) : . , , Gradle Bazel Teamcity , . , .
(Uber): Uber- , . , , Kotlin. , , . . . , « » : « Kotlin-». Kotlin , .
, . , - , . , .
(Avito): , . . , , ().
Technology Radar. : « , 5 , .. ». , Technology Radar, , , , - , , - , - , - . , , . , Technology Radar .
?(Uber): , . , 10 - - . . 100 , , 99. , , , .
( )?(Avito): , — , , , . — .
- , , .
. Android- — IDE early adopted preview . , .
(Spotify) : , Kotlin — - . , Java Android, Kotlin . , — Facebook — Kotlin- , , , Kotlin .
Flutter.
(): , iOS — , Apple. . , . .
, , — . Unidirectional Data Flow.
Swift?(): . Swift, 150 Objective-C, .. Swift , .
Objective-C , Swift? , , Swift — HR-PR-, , Objective-C .
(Avito): . Swift . , , , . . Swift , Objective-C, , , .
( )?(): . Apple , , Swift , open source. , . Objective-C .
( ) — — - , , . , . , — . iOS — , , .
? TDD ?(Spotify) : , Android , . , .
(): , . Unit- .
Unit- , ( ). (API, UI ..) — .
(Uber): , TDD, . , , — .
(Avito): . , , -. UI- unit- . , — , UI-.
. — . TDD.
TDD . Android- , .
AppsConf 2018 TDD.
, .
- ?(Spotify) : , . 100% - unit- .
(Uber): , . , . .
- «» ?(Spotify) : — .
, - (proof of concept ), , . , , , .
(Avito): , , QA-, , backend, frontend . . , , QA.
?(Spotify) : , code review — . CI: , code style —
AppsConf 2018.
: pull request, code style, ; , . , git-. — , : , .
(Uber): Code review — , . , . .
(Avito): code review- -. , , -, , , . -.
, . . , . , , (« ?»). , , .
. , . , , . . , - code review. , .
?(Spotify) : , .
(): , , . , «» «». — , . — — . . - .
. , Android- .
(Uber): , , — . .
build train, . - — . .
. , : . , .
(Avito): — 12 . , . , - ( , -).
-, . . . — . . , — , . , - . .
. , , . . . , , , . .
. AppsConf 2018ApplsConf 2018 . , .