Welche Probleme treten auf, wenn das mobile Team um das Zehnfache erhöht wird? Aus welchen Gründen bevorzugen Android-Entwickler in derselben Firma die Verwendung bekannter Bibliotheken, und unter iOS schreiben sie häufig ihre eigenen Lösungen? Wie ist das Leben für mobile Entwickler in Fintech?
Das Center for Financial Technologies nahm an unserer Mobius-Konferenz teil. In diesem Zusammenhang haben wir zwei CFT-Mitarbeiter gefragt:
Kirill Zuev war für iOS und
Mikhail Emelyanov für Android verantwortlich.
Der Text wurde so erweitert, dass wir sogar ein Inhaltsverzeichnis erstellt haben, sodass es einfach ist, zu einem bestimmten Teil zu gelangen:
Über die Firma
JUG.ru Group: Einführungsfrage: Erzählen Sie uns von dem Unternehmen und was Sie persönlich darin tun.Kirill : Es ist unmöglich, kurz zu sagen, da die CFT-Geschäftsbereiche sehr diversifiziert sind. Probieren Sie jedoch die „großen Details“ der beliebtesten Produkte und Dienstleistungen aus.
CFT ist seit dem dritten Jahrzehnt auf dem russischen Fintech-Markt tätig, und wir sagen, dass wir Fintech gemacht haben, als es ein solches Konzept nicht gab.
Heute verarbeitet und produziert CFT Software für eine Vielzahl verschiedener Finanzorganisationen, Versicherungsunternehmen, staatlicher Unternehmen und den Einzelhandel.
Dies ist das Golden Crown-Ökosystem, das einen Pool von Diensten im B2C- und B2B-Format umfasst: Online-Geldwechsel, Bargeld- und Online-Geldtransfers, Kreditrückzahlungen, Treueprogramme, Transport und soziale Karten.
Das Bearbeitungszentrum "KartStandart": Ausgabe und Erwerb von Karten der Zahlungssysteme Mastercard, Visa und "Mir".
Das föderale System "Stadt" fasst mehrere Zehntausende verschiedener Dienstleistungen zusammen: von der Bezahlung von Kindergärten und Versorgungsunternehmen über Steuerzahlungen bis hin zum Auffüllen von Transportkarten.
Die Online-Banking-Dienste von Faktura.ru werden von mehr als 130 Banken genutzt. Die automatisierten CFT-Bankensysteme werden von noch mehr verschiedenen Organisationen verwendet.
Die CFT beschäftigt große F & E-, ML- und AI-Abteilungen, die in nahezu alle Bereiche des Unternehmens integriert sind. Wir haben ein starkes Informationssicherheitsteam. Im Allgemeinen sind dies mehr als 3.000 Personen, die seit 26 Jahren mit der Lösung von Fintech-Aufgaben beschäftigt sind.
Eines der „jungen“ CFT-Produkte basiert auf dem Dienst „Golden Crown - Money Transfers“ (der bereits 16 Jahre alt ist) - es ist „Money Transfers Online“, eine Richtung, die wir 2016 eingeführt haben. Und heute ist es eine Lokomotive der mobilen Entwicklung in CFT: Insgesamt arbeiten 70 Menschen in iOS und Android daran. Und diese Zahl wächst weiter, wir planen, bis Ende des Jahres auf Hunderte zu wachsen.
In Faktura.ru, dem System „Stadt“, gibt es auch mobile Anweisungen in den Bereichen „Prepaid-Karten“ (sie entwickeln Lösungen für die Karten „Mais“, „Beeline“, „Kari“ usw.).
Und Misha und ich sind gerade in der Abteilung „Online-Geldtransfers“ tätig und beschäftigen uns mit Teamentwicklung, Erweiterung und Einführung in Entwicklungsprozesse. Anfangs arbeiteten wir in der Direktion "Prepaid-Karten", die Teams waren klein und plattformbezogen, und wir lebten in den Konzepten von 2014 bis 2015.
Mikhail : Wenn alle im selben Büro sitzen, arbeiten sie, kommunizieren.
Kirill : Solche kleinen Warm- und Lampenteams für 10-15 Personen, die alles berücksichtigen - sowohl das Testen als auch das Backend. Und jetzt haben wir neue Herausforderungen.
Michael : Ja, die Arbeit von 10 Entwicklern zu organisieren ist eine Sache und 50 eine andere. Dies umfasst alle Prozesse für die Entwicklung, Skalierung des Teams, seine berufliche Entwicklung und das Projekt selbst: Wenn unsere Ingenieure technische Probleme lösen, sind wir an der Entwicklung der Projektarchitektur beteiligt. Wir suchen nach Problemen, die die Skalierung dieses Projekts beeinträchtigen, und versuchen, sie auf jede Weise zu lösen.
JUG.ru Group: Wir werden auf die Themen Wachstum zurückkommen, aber sagen Sie mir zunächst Folgendes: Wie unterscheidet sich die mobile Entwicklung in CFT von anderen Unternehmen und was ist ähnlich? Was müssen Sie darüber wissen für diejenigen, die noch nie in der Fintech gearbeitet haben? Benötigen Sie bereits im Interview spezielle Kenntnisse?Kirill : Wenn wir mit Kandidaten sprechen, die aus dem Outsourcing stammen, haben sie den Wunsch, in einem Produktteam zu arbeiten, den Wunsch nach Stabilität. Aber sie haben immer Bedenken: Ist Fintech eine Art Sumpf, streng reguliert und von Sicherheit umgeben, in dem es aus Sicht des Entwicklers unangenehm ist, sich selbst zu entwickeln.
Wir sagen immer, dass in unserem Fall die mobile Entwicklung genau die gleiche ist wie jede Marktproduktentwicklung. Fintech ist kein Wort, um die Lebensweise zu beschreiben, sondern einfach eine Arbeitsrichtung, mit der wir jeden Tag konfrontiert sind.
Dies sind die gleichen Mobile-Banking-Kunden, verschiedene Zahlungen, kontaktlose Zahlungsdienste und so weiter. Dies bedeutet jedoch nicht, dass Sie spezielle Fähigkeiten oder Kenntnisse benötigen: Jeder coole mobile Entwickler kann mit Fintech beginnen, wenn er interessiert ist.
Natürlich brauchen wir auf der primären Ebene nur minimale Kenntnisse: Wie sieht eine Bankkarte aus, was ist ein Bankkonto? Wenn es jedoch tieferes Wissen gibt, ist es einfacher und schneller, die Wünsche der Analysten zu verstehen. Es gibt Entwickler, die nicht nur verstehen wollen, wie man die Aufgabe erledigt, sondern auch, warum.
Es gibt auch eine eigene Besonderheit, zum Beispiel die Anforderungen der von der Zentralbank vertretenen Regulierungsbehörde. In der Regel wird dies jedoch bei den Geschäftsanforderungen berücksichtigt, und es reicht aus, diese zu lesen, die erforderlichen Fragen zu stellen, und alles wird klar.
Unter dem Gesichtspunkt der Informationssicherheit gibt es bestimmte Punkte, dies ist verständlich: Bei Fintech geht es um Sicherheit. Ich kann jedoch nicht sagen, dass mobile Entwickler die erste Verteidigungslinie sind. Dennoch sind Fintech-Produkte so konzipiert, dass sie auf der Backend- und Datenspeicherseite sicher sind.
Ja, es kommt vor, dass ein Entwickler von einem Startup stammt und sagt, dass die API besser gestaltet werden könnte: Hier können Sie eine Anfrage stellen, und wir machen drei. Dies liegt jedoch daran, dass die API so konzipiert ist, dass nicht alle Informationen angezeigt werden. Und wenn der Entwickler versteht, dass dies eine technische Entscheidung ist und kein dummer Schachzug der Entwickler, akzeptiert er sofort.
Und aus Sicht der Sicherheit mobiler Anwendungen hatten wir einen Bericht über die Vergangenheit von Mobius. Wir haben Amerika dort nicht entdeckt und keine Hacking-Tricks gezeigt, sondern eine Checkliste, die ein Fintech-Anwendungsentwickler durchlaufen muss, um keine dummen Fehler zu machen:
Wir verpflichten sie nicht, da es eine Codeüberprüfung gibt und es Empfehlungen des Sicherheitsteams gibt, die uns zu einer hervorragenden Checkliste gemacht haben. Dort wird angegeben, wo und von wem die Sicherheitsanfälligkeit behoben werden sollte (auf der Seite von Business Intelligence, Backend-Entwickler, Mobile-Entwickler oder Tester) ) Alle diese Verantwortungsbereiche sind uns bekannt, wir halten uns nur an die Regeln.
Es ist wichtig zu verstehen, dass wir nicht nur langweilige Dosen sägen, sondern versuchen, unsere Gesichter den Kunden zuzuwenden, einschließlich der technologischen Seite. Deshalb sind wir immer für Innovationen wie kontaktloses Bezahlen.
Unsere iOS-Banken belegten 2018 den 4. und 5. Platz im
Markswebb-Ranking in der Kategorie Daily Banking.
Wir versuchen, eine Anwendung zu sein, die sich „nicht schämt, Mutter zu zeigen“, die von Menschen verwendet werden kann, die weit entfernt von Smartphones sind und die viel über Technologie verstehen. Warum sind einige mobile Banken erfolgreich und andere nicht? Weil sie technologisch hergestellt werden, mit Animation, vielleicht sogar mit kulturellen Referenzen.
Michael : Ich möchte kurz hinzufügen, dass wir uns wirklich auf Kunden konzentrieren - lebende Menschen, die auf der Straße gehen. Da wir Operationen mit Geld durchführen, bemühen wir uns, sie für die Menschen so benutzerfreundlich wie möglich zu gestalten.
Gleichzeitig müssen Mitarbeiter, die zu uns kommen, verstehen, was sie wirklich für Menschen tun müssen, indem sie nicht „wie ich sehe“ auf die Knie kritzeln. Bevor ich bei CFT gearbeitet habe, habe ich fast das gesamte Design und UX selbst ohne Designer gemacht. Aber das Unternehmen arbeitet für uns nicht so. Es gibt ein ganzes UX-Labor mit Designern, die Experimente durchführen, und es gibt Fokusgruppen, die Hypothesen testen.
Und wenn eine Person zu uns kommt, muss sie verstehen, dass alles darauf ausgerichtet ist, dem Kunden die Verwendung des Produkts zu erleichtern, damit er beim Ausfüllen eines Formulars mit 50 Feldern nicht stirbt. Die Arbeit konzentriert sich auf die Bedürfnisse des Endbenutzers.
Das zweite sind die Anforderungen an die Codequalität. Wir haben wirklich hohe Anforderungen an Qualität, Überprüfung, saubere Architektur und Anwendung der SOLID-Prinzipien auf allen Ebenen. Es ist für uns inakzeptabel, Qualität aus Zeitgründen zu opfern.
Und dies grenzt an moderne Technologie, es gibt keine Verzögerung hinter der Branche. Alle Android-Produkte sind jetzt in Kotlin und iOS in Swift geschrieben. In Android verwenden wir Rx, Dolch, in einigen Projekten Coroutinen. Wenn neue Entwickler kommen, bitten wir regelmäßig um Feedback, um zu verstehen, was die Leute mögen und was nicht. Und ich erinnere mich nicht, dass sich die Mitarbeiter beschwert haben, dass etwas veraltet ist, und angeboten haben, etwas zu ändern. Wir haben nur Zeit, um Ideen zu werfen: „Probieren wir MVI in so und so einem Modul aus“, und jeder beginnt zu generieren.
Wenn eine Person zu unserem Team kommt, sollte sie bereit sein, den modernen Technologie-Stack zu verstehen und ihn zu navigieren. Wir begrüßen dies. Dies ist vielleicht sogar ein Paradoxon: Eine Person geht zur Fintech, zur Bankenentwicklung, erwartet Konservatismus und muss wissen, wie Rx und Kotlin mit all den Leckereien arbeiten. Dies scheint mir ein einzigartiges Merkmal zu sein.
Mobiles Teamwachstum
JUG.ru Group: Sie haben bereits gesagt, dass Sie Probleme lösen, die beim Wachstum des Teams auftreten. Gibt es ein konkretes Beispiel?Michael : Zum Beispiel. Wenn sechs Personen in einem Team eine Überprüfung der Pull-Anfrage durchführen, 3-4 Personen in einer Pull-Anfrage, bestehen sie schnell genug (insbesondere, wenn sich Personen im selben Büro befinden). Die Situation ändert sich dramatisch, wenn Mitarbeiter in verschiedenen Städten und Zeitzonen arbeiten und das Team wächst und separate Zellen darin angezeigt werden (Entwicklungsteams, die von einem Teamleiter vereint werden).
Wir stellten fest, dass mit einem organischen Anstieg der Anzahl der Prüfer die Pull-Anfragen bereits bis zu 5-6 Tage andauerten. Dies war ein Problem: Wir konnten dem Unternehmen keine Funktionen rechtzeitig zur Verfügung stellen.
Es gab auch ein Problem mit dem Git-Flow: Wenn Sie in einem Zweig sitzen und lange Zeit gesehen haben, kann das andere Team gleichzeitig auch 2-4 Features in anderen Zweigen sehen, und dann wird all dies in den Zweigen bis zu den Veröffentlichungsdaten eingefroren. Wir bekommen Schmerzen in Form eines Zusammenführungskonflikts.
Das zweite Problem wurde durch Ändern des Git-Flusses gelöst. Sie begannen, den Stamm-basierten Entwicklungsansatz anzuwenden, dh direkt in den Entwicklungszweig zu fließen und Feature-Zweige aufzugeben. Da es jedoch unmöglich ist, nicht funktionsfähige Funktionen zu verwenden, wird das Projekt dadurch unterbrochen. Daher haben wir den Feature-Toggle-Ansatz angewendet. Dadurch wurde die Frist für die Ausgabe von Funktionen an den Release-Zweig um mehrere Tage verkürzt. Ich habe auf Twitter
@mobileunderhood mehr darüber
gesprochen .
Es gab ein Problem mit der Überprüfung. Zuvor haben ungefähr 4-5 Personen an uns teilgenommen. Da uns die Qualität des Codes wichtig ist, haben wir ziemlich strenge Grundsätze und Qualitätsansätze. Wir befürchteten, dass sich unsere Qualität verschlechtern wird, wenn wir die Anzahl der Rezensenten verringern. In diesem Fall führen für 50 Entwickler beispielsweise 30 Qualitätsprüfungen durch, und der Rest sind Junior-Entwickler oder mittlere Entwickler, die noch keine echte Fähigkeit entwickelt haben.
Deshalb sind wir einen anderen Weg gegangen und haben die Formel „1 Lead + 1 Senior Developer + 1 Any Developer“ entwickelt. Zuerst haben wir diese Formel im Rahmen von Teams verwendet: Beispielsweise gibt der Entwickler von Team „A“ eine Pull-Anfrage aus, gibt eine Überprüfung mit dem Kurator und einem einzelnen Entwickler ab. In anderthalb Tagen erscheinen ungefähr 20 Pull-Anfragen: Wenn wir am Morgen eine Überprüfung aller durchführen, werden es bis zur Mitte des nächsten Tages ungefähr 20 neue sein.
Aber wir sind auf ein anderes Problem gestoßen. Wenn ein Entwickler ständig seinen Lead und einen benachbarten Lead eines anderen Teams platziert, werden die Leads überlastet. Sie sind weniger an der Entwicklung beteiligt und verbringen mehr Zeit mit der Überprüfung. Ungefähr 20 Pull-Anfragen sind eine ernsthafte Arbeit, wenn Sie sich qualitativ nähern.
Und wir gingen noch weiter. Sie ließen drei Zeitnischen für Prüfer frei, ließen die gleichen Rollen (Tech-Team, leitender Entwickler und andere), machten sich aber nicht die Mühe, dass es Leute aus Ihrem Team sein sollten. Und jetzt haben wir Pull-Anfragen an einem Tag, maximal anderthalb. Keine langen Geschichten mehr.
Und das alles in Kombination mit dem Umschalten von Features: Wenn ein Entwickler ein Feature übernimmt, setzt er zunächst ein Deaktivierungsflag im Code, damit es sich um einen Kaltstart handelt. Und dann beginnt die Entwicklung. All dies wird an einem Tag überprüft, egal in welcher Stadt sich das Team befindet.
Eine separate Geschichte mit Zeitzonen. Wenn wir in St. Petersburg eine Pull-Anfrage stellen, spenden wir bis zum Abend, dann in Nowosibirsk +4 Stunden, und während wir noch eine Nacht haben, sehen sie bereits am Morgen Pull-Anfragen. Sie verlassen die Arbeit - wir bekommen ihre Pull-Anfragen und schauen zu. Es stellt sich ein konstanter kontinuierlicher Strom heraus, in dem Zeitzonen zur Hand sind.
Kirill : Ja, um auf die Frage nach dem Unternehmen zurückzukommen: Zusätzlich zu der Tatsache, dass wir mehr als 3.000 Mitarbeiter haben, befinden sich unsere Entwicklungszentren in drei Städten (Tomsk, Nowosibirsk und St. Petersburg), und mobile Teams sind unter ihnen verteilt. Es ist etwas kompliziert, dass es eine Verzögerung von vier Stunden gibt, aber der gesamte Arbeitstag des Unternehmens wird auf 12 Stunden verlängert.
Michael : Zeitzonen helfen mehr als nur eine Überprüfung. Wir haben eine einzige Android-Entwicklung gegründet, es gibt keine Möglichkeit, dass in verschiedenen Städten alles getrennt ist. Unsere Teams sind funktionsübergreifend, aber durch Plattformmerkmale als Communitys vereint. Es gibt Standards, allgemeine Prinzipien und akzeptierte Praktiken, einschließlich Codestil und dergleichen. Und wenn plötzlich Probleme auftreten, die eine Hotfixierung oder andere dringende Maßnahmen erfordern, kann ich diejenigen übernehmen, die jetzt Arbeitszeiten haben, auch wenn sie ursprünglich nicht für diesen Code verantwortlich waren. Menschen in anderen Städten können helfen, während wir schlafen, und umgekehrt.
JUG.ru-Gruppe: Wenn ein Team wächst, kann kein Entwickler bereits die gesamte Codebasis kennen oder es ist einfach, irgendetwas von einer Person in der Nähe zu klären. In diesem Fall ergibt sich wahrscheinlich eine weitere Herausforderung: Aufzeichnungen?Kirill: Hier ist es wert, Folgendes zu sagen: Als wir das Wachstum des Teams zehnmal planten, stellten wir fest, dass wir nicht zehnmal mehr Funktionen (oder sogar siebenmal) veröffentlichen werden. Bei einem solchen Wachstum sind zusätzliche Anstrengungen erforderlich, um das bisherige Qualitätsniveau aufrechtzuerhalten. Und eine der Übungen für neue Entwickler bestand darin, die Dokumentation zu schreiben, bevor sie anfingen, etwas zu tun.
So haben wir in kurzer Zeit die Schlüsselkomponenten der Anwendung in der Dokumentation behandelt. Und sie fingen an, die Jones in solche Komponenten zu lassen, weil es mit einer solchen Dokumentation bereits möglich ist, sich Codeüberprüfungen und -tests zu leisten. Es war ein "verzögerter Auspuff" -Zoom.
Jetzt, da ein Jahr vergangen ist, haben wir die Basis vorbereitet und jetzt bringen wir Entwickler, die vor einem Jahr gekommen sind, auf das volle Produktivitätsniveau. Je weiter wir gehen, desto einfacher wird es. Basierend auf der erstellten Dokumentation haben wir Checklisten mit der Struktur und Interaktion der Komponenten erstellt, mit unserer Integration in die Hauptdienste, und jetzt verursacht dies keine Panik: „Ich bin hierher gekommen, um zu programmieren, und Sie haben hier ein Unternehmen.“
Michael : Ich werde Cyril ergänzen. Nachdem das Team mehr als 30 Mitarbeiter hatte, verbrachten Teamleiter und leitende Entwickler viel Zeit mit einem oder zwei beaufsichtigten Entwicklern, weil sie ständig Informationen übermittelten. Wir haben das im Voraus verstanden und angefangen zu handeln. Daher hat Android in Confluence einen separaten Bereich zugewiesen und dort alle Prinzipien, Praktiken und Konventionen für die Entwicklung nicht nur in diesem Projekt, sondern auch in anderen gesammelt.
Wenn ein Mitarbeiter zu einem Team kommt, setzt er sich zuerst hin und untersucht, wie wir die Entwicklung durchführen, welche Regeln und Praktiken gelten und welche Architektur das Projekt hat. Er nimmt den Code während des Studiums nicht einmal auf. Beantwortet dann die Kontrollfragen. Eine Schulung ohne Sicherheitsfragen ist nicht effektiv genug.
Jetzt sind wir noch weiter gegangen und entwickeln das automatisierte Galileo-Trainingssystem. Sein Wesen liegt in mehreren Stufen der Bildungsabstufung, von den Prinzipien der Entwicklung und Methoden, von den Architekturprinzipien bis zu den Prinzipien der Kotlin-Sprachen.
Nach einem solchen Eintauchen wird die Hälfte der Fragen weggefegt. Was der Lead zuvor getan hat, ist jetzt automatisiert. Wenn der Entwickler in ein oder zwei Wochen direkt zur Produktion geht, stellt er spitze Fragen, was kein Problem ist. Und davor gab es wirklich ein Problem.
Ich glaube, auch wenn das Projekt für 10 Personen ist, müssen Sie die Dokumentation im Voraus legen. Gehen Sie nicht auf diese Angelegenheit ein, sondern legen Sie einige Grundsätze fest. Es wird eine Skalierung geben - dies wird nicht der Fall sein, und wenn ein neuer Entwickler eintrifft, entfernt die Dokumentation auf jeden Fall eine Reihe von Fragen und spart viel Zeit für den Kurator.
Wir haben Plattformdokumentation (für Android und iOS) und es gibt Projekte (Geschäftsszenarien und dergleichen).
Kirill : Wir sind zu Crowdsourcing gewechselt. Wenn ein Neuankömmling ankommt, sagen sie zu ihm: "Schau, das ist am ersten Tag zu lesen, hier am zweiten." Dort einrichten, verschiedene Zugriffe, Tools usw. bereitstellen. Und wenn eine Person mit einem Problem konfrontiert ist, besteht eine ihrer Aufgaben darin, das Problem für den nächsten Neuankömmling auf dieselbe Checkliste zu schreiben. Solche Dinge verfolgen gleichzeitig unterschiedliche Ziele: Wir bereiten auch die Dokumentation für die nächsten Generationen vor und lehren den Anfänger, wie wichtig es ist, zu dokumentieren, was er tut. Und er hat keine Angst davor, was er schreiben soll.
Besonders eifrig beginnen Sie sofort, UML-Diagramme zu zeichnen, was empfohlen wird. Sobald jemand ein gutes Beispiel gibt, werden alle involviert. Und wir schlagen niemanden, da wir verstehen, dass Zeit benötigt wird, und wir geben diese Zeit.
Bibliotheken von Drittanbietern gegen interne Entwicklung
JUG.ru Group: Ich möchte etwas mehr über die „innere Küche“ im Kontext von iOS und Android sprechen. Soweit wir wissen, haben Sie unter iOS die Richtlinie, Lösungen von Drittanbietern abzulehnen, aber Android hat zunächst auch versucht, alles selbst zu schreiben, hat es dann aber verlassen. Warum?Michael : Android war historisch gesehen so. Als wir 2013 eine mobile Bank für die Kukruza-Karte erstellten, gab es in der Android-Entwicklung fast keine Standards für Architekturen und Bibliotheken. Selbst Google selbst verstand nicht, wo es Android entwickeln sollte. Wir haben mit der Entwicklung begonnen, als es noch kein Android 5 gab. Wir hatten KitKat 4.4 als maximale Version.
Da es keine Bibliotheken gibt, schreiben wir uns. , , . : , HTTP-
Volley , API- Retrofit ( ). , . , . Dagger , , Retrofit, «», .
- , , , - . Volley . , , - .
, - . , , Rx , . , . . . , - .
, : «, , », : «- - , », .
, , , -. Kotlin, - 1.0 . , best practices . .
« » « », . , -. .
, : , - , , . , , , , , - . , . , -, .
: iOS, , . . - — , . - AFNetworking, — 40-50 ( ). .
Mobius (
): third-party . , , , , . , , .
— , SSL- , - , .
, , . , ReactiveCocoa, 4-5 . -, , -, , ? , Swift, .
, , , . Android Dagger , , Google. Apple - , . , Swift, , , Swift.
6 , 2011 . 6-8 : , ? , , — SnapKit ( ) , , — , -, . , , .
— . , , , , , , .
: iOS Swift. — , , , . UI-, , -.
Swift — , Objective-C , . , , , , , , …
3 « » VIPER -, : «, MVP, VIPER». MVP- - . , , .
Swift Kotlin
JUG.ru Group: Michael in @mobileunderhood schrieb: "Wir verlassen Java insgesamt, wir schreiben alles auf Kotlin neu." Selbst wenn neuer Code bereits in Kotlin geschrieben wurde, wird der in Java vorhandene Code normalerweise nur sehr langsam geändert und kann noch viele Jahre in der Produktion bleiben. Warum hast du dich entschieden, es aktiver zu machen? Und werden Sie Objective-C-Code in iOS genauso aktiv los?Michael : Ich mochte Java immer. Ich habe sie immer geliebt, sogar das Oracle-Zertifikat bestanden, und ihr ging es gut mit mir. Die Entwicklung von Java in Android und die Entwicklung von Java in Unternehmen sind jedoch zwei verschiedene Dinge. Und vor ein paar Jahren, als Kotlin gerade anfing, wurde die Verwendung von Java in seiner bloßen Form ohne Bibliotheken langsam müde. Lange Konstruktionen, ein wenig syntaktischer Zucker, hier haben einige Kollegen mit C # auch das geworfen, was sie haben, aber wir tun es nicht, es hat im Allgemeinen demotiviert. Ich wollte Code schreiben, der Logik ausführt, und weniger Zeit damit verbringen, diesen Code selbst zu schreiben, mehr Goodies zu verwenden. Es ist einfacher, den Code zu verstehen und zu lesen.
Dann kamen Dinge wie Lombok. Zuerst hat es mir gefallen und dann hat es aufgehört, weil es eine Art zusätzliche Bibliothek ist, mit der Sie den Code vereinfachen und in syntaktischen Zucker einwickeln können, aber dies ist nur ein Plug-In, nicht der Java-Compiler selbst. Und die Kotlin-Datenklasse und die reguläre Java-Klasse mit allen Eigenschafts- und get / set-Kapselungsmethoden sind völlig verschiedene Dinge.
Und wir haben uns lange Zeit zum ersten Mal entschlossen, Kotlin auf der Ebene eines Projekts auszuprobieren. Wir haben es geschrieben, einige Dinge haben uns verwirrt - nun, Kotlin und Kotlin, wir haben es irgendwie versucht, okay, es gibt ein Projekt, wir kehren zu Java zurück. Sie kehrten zurück und nach einiger Zeit wurde mir klar, dass ich mich nicht mehr in Java entwickeln konnte. Das war's, ich habe sie satt, ich kann sie nicht mehr sehen.
Anscheinend habe ich mich an einige syntaktische Dinge gewöhnt, an den Minimalismus des Codes. Und am Ende wurde entschieden, dass wir Kotlin verwenden müssen. Es wird besser wahrgenommen und gelesen. Einige Entwickler waren dagegen, aber es scheint mir, dass dies eine Gewohnheitssache ist. Eingeführte Praxis: Schreiben Sie neue Projekte auf Kotlin. Und die alten Projekte blieben in Java. Aber als einige größere Umgestaltungen stattfanden, haben wir alles nach Kotlin kopiert. Wir haben Erfahrung gesammelt, um dies schnell zu tun. Dies bedeutet nicht, dass wir die Java-Dateien mit Hotkeys in Kotlin konvertiert und diesen Code dann korrigiert haben - wir haben ihn selbst sofort im Kotlin-Stil umgeschrieben.
Es sind buchstäblich zwei Java-Projekte übrig, und der Übergang schreitet auch dort allmählich voran: Neue Module werden in Kotlin geschrieben, neue Tests in Kotlin und die alte Logik in Java. Wenn sich die Logik aufgrund von Refactoring ändert, schreiben wir in Kotlin. Und eines dieser Projekte wird derzeit viel umgestaltet. So haben wir die Migration in den Stream gestellt, und nach zwei Jahren mit Java blieben buchstäblich anderthalb Projekte übrig.
Niemand war besonders dagegen. Es gab einige Skepsis „Kotlin ist nur ein Hype“, aber es hat uns sehr geholfen, als Google Kotlin offiziell für die Android-Entwicklung anerkannte. Für uns war es nur eine Bombe. Es war nicht mehr nötig, Ingenieure zu überzeugen: Entweder sind Sie auf der Welle aller modernen Entwickler oder außerhalb dieses Marktes.
Kirill : Und mit Swift war das allererste Treffen wie folgt: Ich musste eine kleine Präsentation für eine unserer Konferenzen in Nowosibirsk halten, und als ich in Objective-C einen Code auf den Bildschirm brachte, wurde klar, dass er bei keiner Bildschirmgröße gelesen werden konnte. Und dann habe ich diesen Code für die Präsentation in Swift geschrieben, obwohl es im Projekt keine einzige „schnelle“ Zeile gab.
Dann haben wir Swift für das Golden Crown Transport Card-Projekt ausprobiert, das wir von Grund auf neu geschrieben haben. Wir haben dort einige Sprachmomente verbracht. Es war interessant, was wir falsch gemacht haben, ein bisschen begann daran zu arbeiten, unseren eigenen Styleguide zu erstellen. Vom zweiten Swift „zogen“ wir auch zum dritten, tranken einen Schluck Trauer, der dann alle verfolgte.
Und wenn Sie sich die Pull-Anfragen ansehen, die wir jetzt haben, werden 95% des Swift-Codes dort geschrieben. Wir haben keine große Aufgabe, um jeden Preis den gesamten verfügbaren Code von Objective-C nach Swift zu übertragen. Trotzdem beträgt der Anteil des Swift-Codes in der mobilen Money Transfer-Anwendung 60-65%. Wir geben einen „Swift Digest“ aus, in dem wir ein Diagramm für Swift / Objective-C-Dateien, für Codezeilen und abhängig von Veröffentlichung und Datum zeichnen alles ist sichtbar. Ein Anteil von 65% bedeutet nicht, dass wir 6 von 10 Dateien kopiert haben - hauptsächlich Wachstum aufgrund neuer Dateien.
Wir haben verschiedene Übergangstechniken ausprobiert, zum Beispiel in der mobilen Bank für die Corn-Karte einen unidirektionalen Übergang durchgeführt (dh unser Swift-Code basiert auf Objective-C, aber wir übertragen Swift-Konstrukte nicht zurück auf Objective-C). Wir ziehen die Swift-Funktionalität nicht in die Länge, um den Wechsel zu Swift auf diese Weise zu beschleunigen. In diesem Fall können wir sagen, dass es an der Zeit ist, dass die Komponente vollständig auf Swift umschaltet, wenn es wirklich bissig wird und Objective-C-Code alle Swift-Abhängigkeiten erfordert.
Da Produkte für den Golden Crown - Geldtransfer-Service wichtiger sind als die Entwicklungsgeschwindigkeit, als nur den Anteil von Swift zu erhöhen, haben wir bidirektionale Geschichten. Sie mögen aus der Sicht von Swift-Anhängern weniger schön aussehen, aber da dieser Ansatz dem Produkt die Möglichkeit gibt, sich schneller zu bewegen.
Entwickler kamen ohne Kenntnisse von Swift, die Sprache wurde in zwei Wochen beherrscht, es begann zu funktionieren. Manchmal haben sie Angst, dass wir 60% Swift haben, aber es ist okay, es gab noch keinen Fall, in dem ein Mitarbeiter es nicht beherrschen konnte. Es gibt entgegengesetzte Geschichten - wenn sie herausfinden, dass wir 40% Objective-C haben, beginnen sie zu sagen, dass wir rückläufig sind, und Sie müssen zuerst alles auf Swift neu schreiben und dann Features ausschneiden. Aber hier ist alles individuell und wir arbeiten mit jedem individuell.
Es gibt gemischte Projekte, unidirektionale gemischte Projekte, es gibt saubere Projekte auf Swift, wir haben alles versucht. Alles funktioniert ganz gut, es gibt keine Silberkugel.
JUG.ru Group: Über Swift und Kotlin sagen sie: "Weil sie ähnlich sind, ist es für Entwickler für Android und iOS bequemer geworden, sich gegenseitig in den Code zu schauen." Haben Sie Entwickler für verschiedene Plattformen, die sich gegenseitig den Code ansehen oder nicht?Kirill : Ich erinnere mich an Geschichten, als Android-Entwickler, die in Java geschrieben haben, den Code von iOS-Entwicklern auf Objective-C untersuchten und umgekehrt, als wir eine der komplexesten Komponenten der mobilen Anwendung für die Corn Map geschrieben haben - den berühmten Formulardesigner. Ein Beispiel für eine Backend-gesteuerte UI-Architektur. Es gibt eine sehr intensive Interaktion mit dem Backend über ein bestimmtes Protokoll, und nicht dasselbe zu tun war einfach kriminell. Natürlich guckten wir.
Und jetzt haben wir unterschiedliche Architekturansätze in Anwendungen. Anwendungen basieren auf unterschiedlichen UI-Architekturen. Das Maximum, wo wir gucken können, ist die Business-Schicht, und selbst dann sollten wir lieber in Richtung Test-Tools graben, mit denen Sie in einer der Programmiersprachen schreiben können.
Anwendungen sind in der Tat ein Client für den Dienst. Zum größten Teil reagiert es auf Benutzereingaben und zeigt Daten vom Server an. Irgendwo etwas völlig Falsches zu schreiben ist ziemlich schwierig. Und in diesem Sinne gibt es vielleicht einige Beispiele.
Michael : Ich habe Beispiele. Da wir jetzt funktionsübergreifende Teams haben, führen iOS- und Android-Entwickler fast gleichzeitig dieselbe Geschäftsfunktionalität auf verschiedenen Plattformen aus. Sie prüfen den Code des anderen immer weniger, da nichts zu sehen ist und die gesamte Entwicklung reibungslos verläuft.
Wenn jedoch jemand zur gleichen Zeit vorgeht, stellt er fest, dass einige der meisten Chips implementiert sind, wenn das Unternehmen angibt, wie Android funktioniert, und die Analyse noch nicht fertig ist, gibt es Zeiten, in denen Entwickler von beiden Seiten kann vorbeischauen und sehen, wie es gemacht wird. Und hier hilft es wirklich, dass Swift und Kotlin sich sehr ähnlich sind.
In Mobileunderhood teilte ich meine Erfahrungen mit, die ich bei der Arbeit an einem Projekt gemacht hatte, bei dem wir kein funktionsübergreifendes Team hatten, sondern eine Art Startup zur Rückzahlung von Krediten. Und ich habe mich gerne mit der iOS-Entwicklung befasst. Es war interessant, wie sie bestimmte Probleme lösen, vielleicht sogar etwas zu ihnen werfen. Und sie liebten es, mich zu werfen. Und wir konnten stundenlang an der Tafel stehen und darüber sprechen, wie reiner Polymorphismus in iOS und Android aussieht und wie man ihn kocht.
Es geht darum zu diskutieren, was Abstraktion ist, um irgendeine Form von formalen Konzepten, und alles geschieht ziemlich lustig und beginnt mit dem üblichen Code. Sie schauen und denken: Warum haben Sie das getan, gibt es viel Aufwand? Und sie erklären mir, dass alles geplant ist und gehen bewusst darauf ein, um nicht 2-3 Tage nach der besten Lösung zu suchen, wenn sich beispielsweise dieser Code während des Sprints ändert. Ich denke: Kluge Leute, wir müssen das manchmal tun und fünf Tage lang nicht über eine Art interne Architektur nachdenken, über die sich später herausstellt, dass sie nicht benötigt wird.
Infolgedessen bin ich oft aufgetaucht und habe mir den Swift-Code angesehen. Sah auch Objective-C an, aber ich mag Swift mehr. Obwohl ich es nicht entwickelt habe, glaube ich nicht, dass es Schwierigkeiten beim Schreiben von Code geben würde. Android-Entwickler haben das gleiche.
Kirill : Im Allgemeinen haben wir nicht nur ein Plattformteam, in dem wir ihnen sagen: "Sie sind die Besten, weil Apple ein solches Tool zur Verfügung gestellt hat." Die Jungs von iOS und Android interagieren, beteiligen sich gemeinsam an der Planung und arbeiten an Problemen mit Systemanalysten.
Und sie agieren auch in Bezug auf Backend-Entwickler zusammen, wenn sie versuchen, eine nicht so geeignete API zu entwickeln. Und in dieser Symbiose können sie alles im Repository ausspionieren, wir haben ein offenes System und alle Entwickler haben Zugriff auf das Repository.
In der Direktion „Prepaid-Karten“ hatten wir Geschichten, als Backends vernäht wurden, und dann richteten Android-Entwickler die Umgebung und die Umgebung ein und filmten ein paar Fehlerkorrekturen, um zu helfen.
Michael : Ich habe mich an einen sehr aktuellen Fall erinnert. Damit der Kunde für uns subtiler sein konnte, musste das Backend mehr Arbeit leisten. Dann wurden unsere mobilen Tricks zusammengeführt und begannen, ihre allgemeine Idee durchzusetzen. Sie alle kamen zusammen, diskutierten, wie sie sich auf beiden Plattformen wohlfühlen würden, gingen zu den Backend-Entwicklern und kündigten an, wie sie sich wohler fühlen und was gegen das Konzept des Thin Clients verstößt. Die Backender stimmten ihnen zu.
Wenn nun eine Plattform sagte: "Wir werden alles tun" und die zweite ablehnte und sagte, dass es schwierig ist, würden sie die zweite dazu zwingen, irgendwie zuzustimmen und zu tun. Und so passierte alles zusammen. Daher funktioniert Synergie, Teamentwicklung. Und Sprachen helfen dabei wirklich. Wenn Java und Objective-C in Bezug auf Syntax und Prinzip völlig unterschiedliche Hemisphären sind, dann sind Kotlin und Swift wirklich viel näher.
Cyril : Übrigens gibt es Beispiele, als die Jungs zu Switchern und sogar zu Double Switchern wurden, die zwischen Plattformen wechselten. Es gab jemanden, der zu iOS wechselte, sich kennenlernte, „es in die Hände bekam“ und zu Android zurückkehrte. Und dann ist er überhaupt in DevOps gegangen. In dieser Hinsicht sind wir auch offen, solche Momente werden vereinfacht.
Es ist großartig, dass die Jungs sich beruflich weiterentwickeln wollen, auch in verschiedenen Flugzeugen. Wir geben Möglichkeiten, und sie selbst entscheiden, wie sie sich entwickeln möchten, und fast alle unsere Mitarbeiter sind vom Produkt motiviert, von den Aufgaben, an denen sie arbeiten, was sehr cool ist.
JUG.ru Group: Letzte Frage: Was ist mit der plattformübergreifenden Entwicklung?Kirill : Unser Unternehmen hat ein Produkt für das Federal City System in der Entwicklung. Hier wird React Native für die Implementierung ausgewählt. Und wir sind nicht eifersüchtig, weil es immer interessant ist, ein Experiment durchzuführen und herauszufinden, wie es enden wird. Darüber hinaus haben wir Front-End-Entwickler, die sich ihres Geschäfts bewusst sind, und es ist interessant, etwas Neues auszuprobieren und neue Plattformen zu betreten.
Michael : Wir haben Projekte zu React Native, aber das ist ein bisschen falsch, weil es von Front-End-Entwicklern gemacht wird und iOS- und Android-Entwickler sich nicht viel überschneiden.
Die plattformübergreifende Lösung sehe ich persönlich für kleine Teams: Wenn es unter iOS und Android nur wenige Ressourcen gibt und das Projekt für beide Plattformen durchgeführt werden muss, warum nicht? Wir haben genügend Ressourcen und die Produkte sind technologisch anspruchsvoll. Wir können uns eine separate Entwicklung für iOS und Android leisten.
Historisch gesehen war es auch noch nicht plattformübergreifend, als wir die meisten unserer Projekte durchführten. Jetzt würden wir natürlich darüber nachdenken, einen Teil der Geschäftslogik und der abstrakten Logik in allgemeine Module zu unterteilen, weil niemand gerne einen Job macht. Aber historisch gesehen haben wir das nicht.
Dies bedeutet jedoch nicht, dass dies immer so sein wird. Wir haben viele vielversprechende Aufgaben und Projekte aus der Wirtschaft, es gibt Prototypen, und früher oder später werden wir entweder Kotlin Multiplatform von JetBrains oder Flutter ausprobieren, was für uns interessanter ist.
Plattformübergreifend wurde noch nicht in industrieller Form standardisiert, in der Sie es in einem Unternehmen verwenden können. Gemessen an der Kommunikation mit plattformübergreifenden Entwicklern und ihren Berichten gibt es jetzt einen ständigen „Rake Run“ und eine Problemlösung. Daher können Sie ein Projekt aufnehmen und einreichen, aber in den meisten Fällen handelt es sich nur um einen Kampf gegen einen Rechen, und ich glaube nicht, dass Geschäftsfunktionen effizient gesägt werden können. Kürzlich wurde JetBrains in dem Bericht gefragt, ob es möglich ist, die Multi-Plattform-Version von Kotlin überhaupt in der Produktion zu verwenden, und sie sagen, dass es sich noch um eine experimentelle Form handelt.
Am anderen Ende gibt es ein Flattern, das im letzten Jahr gestartet ist, diese Sache ist wirklich interessant, Google ist nicht schwach in dieses Geschäft investiert. Und ich weiß, dass viele Haustierprojekte auf Flutter durchführen, die bereits in Anwendungsgeschäften eingerichtet sind. Und das ist für uns interessanter. Wir haben Kotlin ein bisschen satt, mit Kotlin / Native müssen wir viele Rechen sammeln, aber Flutter with Dart ist eine völlig neue Sache.
Wir lieben alles Neue, also werden wir definitiv eine plattformübergreifende Entwicklung haben. Nicht speziell in der Geldtransferanwendung, sondern in einigen kleinen separaten Anwendungen.
JUG.ru Group: Danke für die detaillierten Antworten!