Quels problèmes surviennent lors de l'augmentation de 10 fois de l'équipe mobile? Pour quelles raisons, dans la même entreprise, les développeurs Android préfèrent utiliser des bibliothèques bien connues, et dans iOS, ils écrivent souvent leurs propres solutions? Comment est la vie des développeurs mobiles en fintech?
Le Center for Financial Technologies a participé à notre conférence Mobius, et à cet égard, nous avons demandé à deux employés du CFT:
Kirill Zuev était responsable d'iOS et
Mikhail Emelyanov était responsable d'Android.
Le texte s'est avéré tellement développé que nous avons même constitué une table des matières afin qu'il soit facile d'accéder à une partie spécifique:
À propos de la société
Groupe JUG.ru: Question introductive: parlez-nous de l'entreprise et de ce que vous y faites personnellement.Kirill : Il est impossible de le dire brièvement, car les secteurs d'activité CFT sont très diversifiés. Mais essayez les «grandes touches» sur les produits et services les plus populaires.
CFT opère sur le marché russe des fintech depuis la troisième décennie et nous disons que nous avons fait de la fintech alors qu'un tel concept n'existait pas.
Aujourd'hui, CFT traite et produit des logiciels pour un grand nombre d'organisations financières, d'assurances, de sociétés d'État et de vente au détail.
Il s'agit de l'écosystème Golden Crown, qui comprend un ensemble de services aux formats B2C et B2B: échange de devises en ligne, transferts d'argent et d'argent en ligne, remboursements de prêts, programmes de fidélité, transports et cartes sociales.
Le centre de traitement "KartStandart": émission et acquisition de cartes de systèmes de paiement Mastercard, Visa et "Mir".
Le système fédéral «City» regroupe plusieurs dizaines de milliers de services divers: du paiement des jardins d'enfants et des services publics au paiement des taxes et au réapprovisionnement des cartes de transport.
Les services bancaires en ligne de Faktura.ru sont utilisés par plus de 130 banques. Les systèmes bancaires automatisés CFT sont utilisés par encore plus d'organisations différentes.
Le CFT emploie de grandes divisions de R&D, ML et AI, qui sont intégrées dans presque tous les domaines de l'entreprise. Nous avons une puissante équipe de sécurité de l'information. En général, ce sont plus de 3 000 personnes qui ont été occupées à résoudre des tâches liées aux technologies financières au cours des 26 dernières années.
L'un des «jeunes» produits CFT est basé sur le service «Golden Crown - Money Transfers» (qui a déjà 16 ans) - c'est «Money Transfers Online», une direction que nous avons lancée en 2016. Et aujourd'hui c'est une locomotive de développement mobile en CFT: au total, 70 personnes y travaillent sur iOS et Android. Et ce nombre continue de croître, nous prévoyons de passer à des centaines d'ici la fin de l'année.
Il existe également des directions mobiles dans les divisions «Cartes prépayées» (elles développent des solutions pour les cartes «Maïs», «Beeline», «Kari», etc.), à Faktura.ru, le Système «Ville».
Et Misha et moi ne sommes que dans la division «Transferts d'argent en ligne», engagée dans le développement, l'expansion et l'introduction des processus de développement. Dans un premier temps, nous travaillions dans la direction "Cartes prépayées", les équipes étaient petites, plateforme, et nous vivions dans les concepts qui étaient en 2014-2015.
Mikhail : Quand tout le monde est assis dans le même bureau, ils travaillent, communiquent.
Kirill : De si petites équipes chaudes et lumineuses, pour 10 à 15 personnes, en tenant compte de tout - à la fois les tests et le backend. Et maintenant, nous avons de nouveaux défis.
Michael : Oui, organiser le travail de 10 développeurs est une chose, et 50 en est une autre. Cela comprend tous les processus de développement, de mise à l'échelle de l'équipe, son développement professionnel et le projet lui-même: si nos ingénieurs résolvent des problèmes techniques, nous sommes engagés dans le développement de l'architecture du projet. Nous recherchons des problèmes susceptibles d'interférer avec la mise à l'échelle de ce projet et essayons de les résoudre de toutes les manières.
Groupe JUG.ru: Nous reviendrons sur les questions de croissance, mais pour l'instant dites-moi ceci: en quoi le développement mobile dans CFT est-il différent des autres sociétés, et qu'est-ce qui est similaire? Que devez-vous savoir à ce sujet pour ceux qui n'ont jamais travaillé dans la fintech? Avez-vous déjà besoin de connaissances particulières au stade de l'entretien?Kirill : Lorsque nous discutons avec des candidats issus de l'externalisation, ils ont une envie de travailler dans une équipe produit, une envie de stabilité. Mais ils ont toujours des soucis: la fintech est une sorte de marais, strictement réglementé et entouré de sécurité, dans lequel il sera inconfortable de s'engager dans l'auto-développement du point de vue du développeur.
Nous disons toujours que dans notre cas, le développement mobile est exactement le même que tout développement de produits du marché. La Fintech n'est pas un mot pour décrire le mode de vie, mais simplement une ligne de travail, quelque chose auquel nous sommes confrontés tous les jours.
Ce sont les mêmes clients de services bancaires mobiles, divers paiements, services de paiement sans contact, etc. Mais cela ne signifie pas que vous avez besoin de compétences ou de connaissances particulières: tout développeur mobile cool peut commencer à faire de la fintech s'il est intéressé.
Bien sûr, nous avons besoin de connaissances minimales au niveau primaire: à quoi ressemble une carte bancaire, qu'est-ce qu'un compte bancaire. Mais s'il existe une connaissance plus approfondie, cela permet de comprendre plus facilement et plus rapidement les souhaits des analystes. Il y a des développeurs qui veulent comprendre non seulement «comment faire la tâche», mais aussi «pourquoi».
Il y a aussi sa propre spécificité, par exemple, les exigences du régulateur représenté par la Banque centrale. Mais, en règle générale, tout cela est pris en compte dans les exigences commerciales et il suffit de les lire, de poser les questions nécessaires, et tout sera clair.
Il y a certains points du point de vue de la sécurité de l'information, c'est compréhensible: la fintech concerne la sécurité. Mais je ne peux pas dire que les développeurs mobiles sont la première ligne de défense. Pourtant, les produits fintech sont conçus de manière à être sûrs du côté du backend et du stockage de données.
Oui, il arrive qu'un développeur provienne d'une startup et commence à dire que l'API pourrait être mieux conçue: ils disent, ici, vous pouvez faire une demande, et nous en faisons trois. Mais cela est dû au fait que l'API est conçue de manière à ne pas donner l'intégralité des informations. Et lorsque le développeur comprend qu'il s'agit d'une décision d'ingénierie et non d'une décision stupide de la part des développeurs, il accepte immédiatement.
Et du point de vue de la sécurité des applications mobiles, nous avions un rapport sur le passé Mobius. Nous n'avons pas découvert l'Amérique là-bas et n'avons pas montré d'astuces de piratage, mais avons montré une liste de contrôle qu'un développeur d'applications fintech doit parcourir afin de ne pas commettre d'erreurs stupides:
Nous ne les engageons pas, car il y a une révision du code et il y a des recommandations d'agents de sécurité qui nous ont fait une merveilleuse liste de contrôle. Il indique où la vulnérabilité doit être déterminée et par qui (du côté de la Business Intelligence, développeur backend, développeur mobile ou testeur ) Tous ces domaines de responsabilité nous sont connus, nous respectons simplement les règles.
Il est important de comprendre que nous ne scions pas seulement des canettes ennuyeuses, mais essayons de tourner nos visages vers les clients, y compris le côté technologique. Par conséquent, nous sommes toujours pour des innovations comme les paiements sans contact.
Nos «banques» iOS en 2018
occupaient les 4e et 5e places
du classement Markswebb dans la catégorie Banque quotidienne.
Nous essayons d'être une application qui «n'a pas honte de montrer à maman», qui peut être utilisée par des personnes éloignées des smartphones et par ceux qui comprennent beaucoup la technologie. Pourquoi certaines banques mobiles réussissent-elles et d'autres non? Parce qu'ils sont fabriqués technologiquement, avec de l'animation, peut-être même avec une sorte de références culturelles.
Michael : J'ajouterai brièvement que nous nous concentrons vraiment sur les clients - les gens vivants qui marchent dans les rues. Puisque nous effectuons des opérations avec de l'argent, nous nous efforçons de les rendre aussi utilisables que possible, plus faciles pour les personnes.
En même temps, lorsque les employés viennent à nous, ils doivent comprendre ce qu'il faut vraiment «faire pour les gens», c'est de ne pas griffonner «comme je vois» à genoux. Avant de travailler chez CFT, j'ai fait presque tout le design et l'UX moi-même sans designer. Mais l'entreprise ne fonctionne pas pour nous comme ça. Il y a tout un laboratoire UX avec des concepteurs qui mènent des expériences, et il y a des groupes de discussion qui testent les hypothèses.
Et lorsqu'une personne vient à nous, elle doit comprendre que tout sera mis en œuvre pour faciliter l'utilisation du produit par le client, afin de ne pas mourir en remplissant un formulaire de 50 champs. Le travail est axé sur les besoins de l'utilisateur final.
Le second concerne les exigences de qualité du code. Nous avons des exigences très élevées en matière de qualité, de révision, d'architecture propre, d'application des principes SOLIDES sur toutes les couches. Il est inacceptable que nous sacrifions la qualité pour gagner du temps.
Et cela est adjacent à la technologie moderne, il n'y a pas de retard par rapport à l'industrie. Tous les produits Android sont désormais écrits en Kotlin et iOS sur Swift. Dans Android, nous utilisons Rx, Dagger, dans certains projets coroutines. Lorsque de nouveaux développeurs arrivent, nous demandons régulièrement des commentaires pour comprendre ce que les gens aiment et n'aiment pas. Et je ne me souviens pas que les employés se sont plaints que quelque chose était dépassé et ont proposé de changer quelque chose. Nous n'avons que le temps de lancer des idées, «essayons MVI dans tel ou tel module», et tout le monde commence à générer.
Lorsqu'une personne vient dans notre équipe, elle doit être prête à comprendre la pile technologique moderne et à pouvoir la naviguer. Nous nous en félicitons. C'est peut-être même un paradoxe: une personne va à la fintech, au développement bancaire, attend le conservatisme, et il est nécessaire de savoir comment Rx et Kotlin fonctionnent avec tous les goodies. Il me semble que c'est une caractéristique unique.
Croissance de l'équipe mobile
Groupe JUG.ru: Vous avez déjà dit que vous résolvez des problèmes qui surviennent avec la croissance de l'équipe. Y a-t-il un exemple concret?Michael : Par exemple. Lorsque six personnes dans une équipe effectuent un examen des demandes de tirage, 3-4 personnes dans une demande de tirage, elles passent assez rapidement (surtout si les gens sont dans le même bureau). La situation change radicalement lorsque les employés travaillent dans différentes villes et fuseaux horaires et que l'équipe s'agrandit et que des cellules distinctes apparaissent à l'intérieur (équipes de développement réunies par un chef d'équipe).
Nous avons remarqué qu'avec une augmentation organique du nombre d'examinateurs, les demandes d'extraction ont commencé à persister déjà jusqu'à 5-6 jours. C'était un problème: nous ne pouvions pas livrer les fonctionnalités à l'entreprise à temps.
Il y avait aussi un problème avec git flow: si vous êtes assis dans une branche et que vous avez vu pendant longtemps, en même temps, l'autre équipe peut également voir 2 à 4 fonctionnalités dans d'autres branches, puis tout cela est gelé dans les branches par les dates de sortie, nous ressentons de la douleur sous la forme d'un conflit de fusion.
Le deuxième problème a été résolu en modifiant le débit git. Ils ont commencé à appliquer l'approche de développement basée sur les troncs, c'est-à-dire à verser directement dans la branche de développement des branches de fonctionnalités abandonnées. Mais comme il est impossible de verser des fonctionnalités inopérantes, cela interrompra le projet, puis nous avons appliqué l'approche de basculement des fonctionnalités. Et réduit ainsi de plusieurs jours le délai de délivrance des fonctionnalités à la branche de publication. J'en ai parlé davantage sur Twitter
@mobileunderhood .
Il y a eu un problème avec la critique. Auparavant, environ 4 à 5 personnes ont participé en nous, car la qualité du code est importante pour nous, nous avons des principes et des approches de qualité assez stricts. Nous avions peur que si nous réduisions le nombre de critiques, notre qualité se détériorerait. Dans ce cas, pour 50 développeurs, par exemple, 30 réalisent des revues de qualité, et le reste sont des développeurs juniors ou intermédiaires qui n'ont pas encore développé une réelle compétence.
Par conséquent, nous avons pris un chemin différent et nous sommes arrivés avec la formule «1 lead + 1 senior developer + 1 any developer». Dans un premier temps, nous avons utilisé cette formule dans le cadre d'équipes: par exemple, le développeur de l'équipe «A» émet une pull request, soumet une revue au curateur et à un développeur individuel. Une vingtaine de requêtes pull apparaissent en un jour et demi: si le matin, nous procédons à un examen de tout le monde, au milieu du lendemain, il y en aura environ 20 nouvelles.
Mais nous avons rencontré un autre problème. Si un développeur met constamment son lead et un lead voisin d'une autre équipe, alors les leads deviennent surchargés. Ils sont moins impliqués dans le développement et passent plus de temps sur l'examen. Environ 20 demandes de tirage sont un travail sérieux si vous l'abordez qualitativement.
Et nous sommes allés encore plus loin. Ils ont laissé trois emplacements aux examinateurs, ont laissé les mêmes rôles (équipe technique, développeur principal et tout autre), mais n'ont pas pris la peine que ce soit des gens de votre équipe. Et maintenant, nous avons des pull-demandes qui ont lieu en une journée, un maximum d'un an et demi. Plus d'histoires longues.
Et tout cela en combinaison avec la bascule de fonctionnalité: lorsqu'un développeur prend une fonctionnalité, il fait tout d'abord un indicateur de désactivation dans le code pour qu'il démarre à froid. Et puis ça commence le développement. Tout cela est vérifié en une journée, quelle que soit la ville dans laquelle l'équipe se trouve.
Une histoire séparée avec des fuseaux horaires. Si nous faisons une demande de tirage à Saint-Pétersbourg, nous faisons un don le soir, puis à Novossibirsk +4 heures, et pendant que nous avons une autre nuit, ils regardent déjà les demandes de tirage le matin. Ils quittent le travail - nous recevons leurs demandes de pull et regardons. Il en résulte un flux continu constant dans lequel les fuseaux horaires fonctionnent à portée de main.
Kirill : Oui, revenons à la question sur l'entreprise: en plus du fait que nous avons plus de 3000 employés, nos centres de développement sont situés dans trois villes (Tomsk, Novossibirsk et Saint-Pétersbourg), et des équipes mobiles sont réparties entre elles. C'est un peu compliqué qu'il y ait un décalage de quatre heures, mais la durée totale de travail de l'entreprise est étendue à 12 heures.
Michael : Les fuseaux horaires aident plus qu'un simple examen. Nous avons formé un seul développement Android, il n'y a rien de tel que dans différentes villes, tout est séparé. Nos équipes sont interfonctionnelles, mais unies par les caractéristiques de la plateforme, en tant que communautés. Il existe des normes, des principes généraux et des pratiques acceptées, notamment le style de code, etc. Et par conséquent, si tout à coup des problèmes surviennent qui nécessitent une correction à chaud ou une autre action urgente, je peux prendre en charge ceux qui ont maintenant des heures de travail, même s'ils n'étaient pas à l'origine responsables de ce code. Les gens dans d'autres villes peuvent aider pendant que nous dormons, et vice versa.
Groupe JUG.ru: Lorsqu'une équipe se développe, aucun développeur ne peut déjà connaître l'intégralité de la base de code ou il est facile de clarifier quoi que ce soit d'une personne assise à proximité. Dans ce cas, probablement, un autre défi se pose: la tenue des dossiers?Kirill: Ici, cela vaut la peine de dire ceci: lorsque nous avons planifié la croissance de l'équipe 10 fois, nous avons réalisé que nous ne publierions pas 10 fois plus de fonctionnalités (ou même 7 fois). Avec une telle croissance, juste pour maintenir le niveau de qualité précédent, des efforts supplémentaires sont nécessaires. Et l'un des exercices pour les nouveaux développeurs consistait simplement à rédiger la documentation avant de commencer à faire quelque chose.
Ainsi, en peu de temps, nous avons couvert les composants clés de l'application dans la documentation. Et ils ont commencé à laisser les jones dans de tels composants, car avec une telle documentation, il est déjà possible de se permettre des révisions et des tests de code. C'était un zoom «d'échappement retardé».
Maintenant qu'une année s'est écoulée, nous avons préparé la base, et maintenant nous amenons les développeurs qui sont arrivés il y a un an au plein niveau de productivité. Plus nous allons loin, plus cela devient facile. Sur la base de la documentation créée, nous avons construit des listes de contrôle avec la structure et l'interaction des composants, avec notre intégration avec les principaux services, et maintenant tout cela ne provoque pas de panique: "Je suis venu ici pour programmer, et vous avez une entreprise ici."
Michael : Je vais compléter Cyril. Après que l'équipe ait plus de 30 employés, il y a eu une période où les chefs d'équipe et les développeurs seniors ont passé beaucoup de temps sur un ou deux développeurs supervisés, car ils transmettaient constamment des informations. Nous l'avons compris à l'avance et avons commencé à agir. Par conséquent, Android a alloué un espace séparé dans Confluence et y a rassemblé tous les principes, pratiques et conventions pour le développement non seulement dans ce projet, mais aussi dans d'autres.
Lorsqu'un employé rejoint une équipe, il s'assoit d'abord et étudie comment nous menons le développement, quelles sont les règles et pratiques, et quelle architecture du projet. Il ne reprend même pas le code pendant ses études. Répond ensuite aux questions de contrôle. Toute formation sans questions de sécurité n'est pas suffisamment efficace.
Nous sommes maintenant allés encore plus loin et créons le système de formation automatisé Galileo. Son essence est à plusieurs niveaux de gradation de l'enseignement, des principes de développement et des méthodologies, des principes architecturaux aux principes des langues Kotlin.
Après une telle immersion, la moitié des questions sont balayées. Ce que le chef de file faisait auparavant est maintenant automatisé. Lorsque le développeur passe directement à la production, dans une semaine ou deux, il pose des questions pointues, ce qui n'est pas un problème. Et avant cela, il y avait vraiment un problème.
Je crois que même si le projet concerne 10 personnes, il faut quand même déposer la documentation à l'avance. Ne vous heurtez pas à cette question, mais posez quelques principes. Il y aura une mise à l'échelle - ce ne sera pas, et en tout cas, lorsqu'un nouveau développeur arrive, la documentation supprime un tas de questions et fait gagner beaucoup de temps au conservateur.
Nous avons une documentation de plate-forme (pour Android et iOS), et il y a des projets (scénarios commerciaux et similaires).
Kirill : Nous sommes passés à du crowdsourcing. Quand un nouveau venu arrive, ils lui disent: "Regarde, voici ce qu'il faut lire le premier jour, ici le deuxième." Là, configuration, mise à disposition de divers accès, outils, etc. Et si une personne est confrontée à un problème, l'une de ses tâches consiste à écrire le problème sur la même liste de contrôle pour le prochain nouveau venu. De telles choses poursuivent des objectifs différents à la fois: nous préparons également de la documentation pour les prochaines générations et enseignons au débutant la valeur de documenter ce qu'il fait. Et il n'a pas peur de quoi écrire.
Particulièrement zélé commence immédiatement à dessiner des diagrammes UML, ce qui est encouragé. Une fois que quelqu'un donne le bon exemple, tout le monde s'implique. Et nous ne battons personne, car nous comprenons que le temps est nécessaire, et nous donnons ce temps.
Bibliothèques tierces contre le développement interne
Groupe JUG.ru: Je voudrais parler un peu plus de la «cuisine intérieure» dans le contexte d'iOS et d'Android. Pour autant que nous comprenions, vous avez sur iOS une politique de rejet des solutions tierces, mais Android a d'abord essayé également de tout écrire lui-même, mais il l'a ensuite laissé. Pourquoi?Michael : Android a toujours été ainsi. En 2013, lorsque nous faisions une banque mobile pour la carte Kukruza, il n'y avait presque pas de normes pour les architectures et les bibliothèques dans le développement Android. Même Google lui-même ne comprenait pas où il devait développer Android. Nous avons commencé le développement alors qu'il n'y avait pas encore Android 5, nous avions KitKat 4.4 comme version maximale.
Puisqu'il n'y a pas de bibliothèques, nous écrivons nous-mêmes. , , . : , 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
Groupe JUG.ru: Michael dans @mobileunderhood a écrit «nous quittons Java ensemble, nous réécrivons tout sur Kotlin». Habituellement, même lorsque le nouveau code est déjà écrit en Kotlin, l'existant en Java est modifié très lentement, et il peut rester en production pendant encore de nombreuses années. Pourquoi avez-vous décidé de le faire plus activement? Et vous débarrasser du code Objective-C aussi activement dans iOS?Michael : J'ai toujours aimé Java. Je l'ai toujours aimée, j'ai même réussi le certificat Oracle et elle allait bien avec moi. Mais le développement de Java dans Android et le développement de Java dans l'entreprise sont deux choses différentes. Et il y a quelques années, quand Kotlin commençait à peine, l'utilisation de Java sous sa forme nue sans bibliothèques commençait à se fatiguer. De longues constructions, un peu de sucre syntaxique, ici certains collègues avec C # ont également jeté ce qu'ils ont, mais nous ne le faisons pas, cela a généralement démotivé. Je voulais écrire du code qui exécute la logique, et passer moins de temps à écrire ce code lui-même, utiliser plus de goodies, il est plus facile de comprendre et de lire le code.
Puis vinrent des choses comme Lombok. Au début, je l'ai aimé, puis il s'est arrêté, car c'est une sorte de bibliothèque supplémentaire qui vous permet de simplifier le code, de l'envelopper dans du sucre syntaxique, mais ce n'est qu'un plug-in, pas le compilateur Java lui-même. Et la classe de données Kotlin et la classe Java régulière avec toutes les propriétés et les méthodes d'encapsulation get / set sont des choses complètement différentes.
Et nous avons décidé longtemps pour la première fois d'essayer Kotlin au niveau d'un projet. Nous l'avons écrit, certaines choses nous ont déroutés - eh bien, Kotlin et Kotlin, nous l'avons en quelque sorte essayé, d'accord, il y a un projet, nous revenons à Java. Ils sont revenus et après un certain temps, j'ai réalisé que je ne pouvais plus développer en Java. Ça y est, je suis fatiguée d'elle, je ne la vois plus.
Apparemment, je me suis habitué à certaines choses syntaxiques, au minimalisme du code. Et à la fin, il a été décidé que nous devions utiliser Kotlin. Il est mieux perçu et lu. Certains développeurs étaient contre, mais il me semble que c'est une question d'habitude. Pratique introduite: écrire de nouveaux projets sur Kotlin. Et les anciens projets sont restés à Java. Mais quand une refactorisation majeure a eu lieu, nous avons tout copié sur Kotlin. Nous avons acquis de l'expérience pour le faire rapidement. Cela ne signifie pas que nous avons converti les fichiers Java en Kotlin avec des touches de raccourci, puis corrigé ce code - nous l'avons nous-mêmes réécrit immédiatement en style Kotlin.
Il reste littéralement deux projets Java, et la transition se poursuit progressivement là aussi: de nouveaux modules sont écrits en Kotlin, de nouveaux tests en Kotlin et l'ancienne logique en Java. Si la logique change en raison du refactoring, nous écrivons en Kotlin. Et l'un de ces projets fait actuellement l'objet d'une refonte importante. Ainsi, nous avons mis la migration sur le flux, et après deux ans avec Java, il restait littéralement un projet et demi.
Personne n'était particulièrement opposé. Il y avait un certain scepticisme «Kotlin n'est que battage médiatique», bien sûr, mais cela nous a vraiment aidés lorsque Google a officiellement reconnu Kotlin pour le développement Android, pour nous, ce n'était qu'une bombe. Il n'était plus nécessaire de convaincre les ingénieurs: soit vous êtes sur la vague de tous les développeurs modernes, soit en dehors de ce marché.
Kirill : Et avec Swift, la toute première réunion était comme ça: j'avais besoin de faire une petite présentation pour une de nos conférences à Novossibirsk, et quand j'ai apporté un morceau de code à l'écran dans Objective-C, il est devenu clair qu'il ne pouvait pas être lu à n'importe quelle taille d'écran. Et puis j'ai écrit ce morceau de code pour la présentation dans Swift, bien qu'il n'y ait pas une seule ligne «swift» dans le projet.
Ensuite, nous avons essayé Swift sur le projet Golden Crown Transport Card, que nous avons écrit à partir de zéro. Nous y avons couru quelques moments linguistiques. C'était intéressant ce que nous faisions de mal, un peu a commencé à travailler pour créer notre propre guide de style. Du deuxième Swift, nous avons également «déménagé» au troisième, pris une gorgée de chagrin, qui a ensuite hanté tout le monde.
Et si vous regardez les demandes de tirage que nous avons maintenant, 95% du code Swift y est écrit. Nous n'avons pas de super tâche pour transférer à tout prix tout le code disponible d'Objective-C vers Swift. Néanmoins, la part du code Swift dans l'application mobile Money Transfer est de 60 à 65%, nous émettons un «résumé rapide» dans lequel nous dessinons un graphique pour les fichiers Swift / Objective-C, pour les lignes de code, et selon la version et la date tout est visible. Une part de 65% ne signifie pas que nous avons copié 6 fichiers sur 10 - principalement une croissance due à de nouveaux fichiers.
Nous avons essayé différentes techniques de transition, par exemple, dans la banque mobile pour la carte Corn, nous avons effectué une transition unidirectionnelle (c'est-à-dire que notre code Swift est basé sur Objective-C, mais nous ne transférons pas les constructions Swift à Objective-C). Nous ne faisons pas glisser la fonctionnalité Swift pour accélérer le processus de passage à Swift de cette manière. Dans ce cas, quand il devient vraiment accrocheur et que le code Objective-C nécessite toutes les dépendances Swift, nous pouvons dire qu'il est temps pour le composant de basculer complètement vers Swift.
Étant donné que les produits du service Golden Crown - Transfert d'argent sont plus importants que la vitesse de développement que l'augmentation simple de la part de Swift, nous avons des histoires bidirectionnelles. Ils peuvent sembler moins beaux du point de vue des adhérents Swift, mais puisque cette approche donne au produit la capacité de se déplacer plus rapidement.
Les développeurs sont venus sans aucune connaissance de Swift, le langage a été maîtrisé en deux semaines, il a commencé à fonctionner. Parfois, ils ont peur que nous ayons 60% de Swift, mais ça va, il n'y a pas encore eu de cas où un employé n'a pas pu le maîtriser. Il y a des histoires opposées - quand ils découvrent que nous avons 40% d'Objective-C, ils commencent à dire que nous sommes rétrogrades, et vous devez d'abord tout réécrire sur Swift, puis couper les fonctionnalités. Mais ici, tout est individuel et nous travaillons avec chacun individuellement.
Il y a des projets mixtes, des projets mixtes unidirectionnels, il y a des projets propres sur Swift, nous avons tout essayé. Tout fonctionne plutôt bien, il n'y a pas de solution miracle.
Groupe JUG.ru: À propos de Swift et Kotlin, ils disent "parce qu'ils sont similaires, il est devenu pratique pour les développeurs d'Android et d'iOS d'examiner le code de l'autre". Avez-vous des développeurs pour différentes plates-formes qui se regardent ou non?Kirill : Je me souviens d'histoires où des développeurs Android qui ont écrit en Java ont examiné le code des développeurs iOS sur Objective-C et vice versa, lorsque nous avons écrit l'un des composants les plus complexes de l'application mobile pour la carte Corn - le célèbre concepteur de formulaires, Un exemple d'architecture d'interface pilotée par le backend. Il y a une interaction très intense avec le backend à travers un certain protocole, et ne pas le faire de la même manière était simplement criminel. Bien sûr, nous avons regardé.
Et maintenant, nous avons différentes approches architecturales dans les applications, les applications sont basées sur différentes architectures d'interface utilisateur. Le maximum où nous pouvons jeter un œil est la couche métier, et même dans ce cas, nous devrions plutôt creuser dans le sens d'outils de test qui vous permettent d'écrire dans l'un des langages de programmation.
Les applications sont en fait un client du service. Pour la plupart, il répond aux entrées de l'utilisateur et affiche les données du serveur. Il est assez difficile d'écrire quelque chose de complètement faux. Et dans ce sens, peut-être, il y a quelques exemples.
Michael : J'ai des exemples. Étant donné que nous avons maintenant des équipes interfonctionnelles, les développeurs iOS et Android font presque simultanément les mêmes fonctionnalités commerciales sur différentes plates-formes, ils se regardent moins souvent le code parce qu'il n'y a rien à regarder et que le développement se déroule bien.
Mais lorsque quelqu'un va de l'avant, en même temps, la personne se rend compte que la plupart des puces sont implémentées, lorsque l'entreprise suggère «regardez comment Android est fait» et que l'analyse n'est pas encore prête, il y a des moments où les développeurs des deux côtés peut passer et voir comment cela se fait. Et ici, cela aide vraiment que Swift et Kotlin soient très similaires.
Dans le mobileunderhood, j'ai partagé mon expérience que j'ai eue lorsque je travaillais sur un projet dans lequel nous n'avions pas d'équipe interfonctionnelle, mais une startup de remboursement de prêts. Et j'aimais regarder le développement iOS, c'était intéressant de voir comment ils résolvent certains problèmes, peut-être même de leur lancer quelque chose. Et ils ont adoré me jeter. Et nous, constamment, pendant des heures, nous pouvions nous tenir au tableau noir et parler de l'apparence du polymorphisme pur dans iOS et Android, comment le cuisiner.
Il s'agit de discuter de ce qu'est l'abstraction, d'une sorte de concepts formels, et tout se passe plutôt amusant, et commence avec le code habituel. Vous regardez et pensez: pourquoi avez-vous fait cela, y a-t-il beaucoup de frais généraux? Et ils m'expliquent que tout est prévu et y vont consciemment, afin de ne pas passer 2-3 jours à chercher la meilleure solution, si, par exemple, ce code change au cours du sprint. Je pense: les gars intelligents, nous devons parfois le faire, et ne pas penser pendant cinq jours à une sorte d'architecture interne, sur laquelle il s'avère plus tard qu'elle n'est pas nécessaire.
En conséquence, je suis souvent venu et j'ai regardé le code Swift. J'ai aussi regardé Objective-C, mais j'aime plus Swift. Bien que je ne l'ai pas développé, je ne pense pas qu'il y aurait des difficultés à écrire du code. Les développeurs Android ont la même chose.
Kirill : En général, nous n'avons pas seulement une équipe de plate-forme, à l'intérieur de laquelle nous leur disons: "Vous êtes les meilleurs parce qu'Apple a donné un tel outil." Les gars d'iOS et d'Android interagissent, participent à la planification ensemble et travaillent sur les problèmes avec les analystes système.
Et ils agissent également ensemble en relation avec les développeurs backend s'ils essaient de trouver une API pas si appropriée. Et dans cette symbiose, ils peuvent tout espionner dans le référentiel, nous avons un système ouvert et tous les développeurs ont accès au référentiel.
Dans la direction «Cartes prépayées», nous avions des histoires lorsque les backends étaient cousus, puis les développeurs Android ont mis en place un environnement, un environnement et filmé quelques corrections de bugs, juste pour vous aider.
Michael : Je me suis rappelé un cas très récent. Là, pour que le client soit plus subtil pour nous, le back-end devait faire plus de travail, puis nos astuces mobiles se sont réunies et ont commencé à faire avancer leur idée générale. Ils se sont tous réunis, ont discuté de la façon dont ils seraient à l'aise sur les deux plates-formes, sont allés voir les développeurs du backend et ont annoncé comment ils sont plus à l'aise de travailler et ce qui viole le concept de client léger. Les backenders étaient d'accord avec eux.
Maintenant, si une plate-forme disait: "Nous ferons tout", et la seconde refusera, disant que c'est difficile, alors ils forceraient la seconde à s'entendre et à faire. Et donc tout s'est passé ensemble. Par conséquent, la synergie, le développement d'équipe fonctionne. Et les langues y contribuent vraiment. Après tout, si Java et Objective-C sont des hémisphères complètement différents en termes de syntaxe et de principe, alors Kotlin et Swift sont vraiment beaucoup plus proches.
Cyril : Au fait, il y a des exemples où les gars sont devenus des commutateurs, et même des doubles commutateurs, passant d'une plate-forme à l'autre. Il y en a un qui est passé à iOS, a fait connaissance, a «mis la main dessus» et est revenu sur Android. Et puis il est parti du tout dans DevOps. À cet égard, nous sommes également ouverts, ces moments sont simplifiés.
C'est génial que les gars veulent du développement professionnel, même sur différents plans. Nous donnons des opportunités, et ils choisissent eux-mêmes la façon dont ils veulent se développer, et presque tous nos gars sont motivés par le produit, par les tâches sur lesquelles ils travaillent, ce qui est très cool.
Groupe JUG.ru: Dernière question: qu'en est-il du développement multiplateforme?Kirill : Notre entreprise a un produit en développement pour le système de la ville fédérale. C'est là que React Native est choisi pour l'implémentation. Et nous ne ressentons aucune jalousie pour cela, car il est toujours intéressant de mener une expérience et de savoir comment elle se terminera. De plus, nous avons des développeurs front-end qui connaissent bien leur entreprise, et il est intéressant d'essayer quelque chose de nouveau et d'entrer sur de nouvelles plateformes.
Michael : Nous avons des projets sur React Native, mais c'est un peu faux, car il est fait par des développeurs front-end, et les développeurs iOS et Android ne se chevauchent pas beaucoup.
Quant à la multiplateforme, je la vois personnellement pour les petites équipes: quand il y a peu de ressources sur iOS et Android, et que le projet doit être fait pour les deux plates-formes, pourquoi pas. Nous avons suffisamment de ressources, et les produits sont technologiquement sophistiqués, nous pouvons nous permettre un développement séparé pour iOS et Android.
Historiquement, il s'est également produit que lorsque nous avons réalisé la plupart de nos projets, il n'y avait pas encore de plateforme multiplateforme. Maintenant, naturellement, nous penserions à séparer une partie de la logique métier et de la logique abstraite en modules généraux, car personne n'aime faire un travail. Mais historiquement, nous n'en avons pas.
Cependant, cela ne signifie pas qu'il en sera toujours ainsi. Nous avons de nombreuses tâches et projets prometteurs de la part de l'entreprise, il y a des prototypes, et tôt ou tard nous essaierons soit Kotlin Multiplatform de JetBrains, soit Flutter, ce qui est plus intéressant pour nous.
La multiplateforme n'a pas encore été standardisée sous une forme industrielle, dans laquelle vous pouvez la prendre et l'utiliser dans une entreprise. À en juger par la communication avec les développeurs multiplateformes et leurs rapports, il existe désormais un «rake run» et une résolution de problèmes constants. Par conséquent, vous pouvez prendre et déposer un projet, mais le plus souvent, ce sera juste un combat contre un râteau, et je ne pense pas que les fonctionnalités commerciales puissent être sciées efficacement. Récemment, JetBrains a été demandé lors du rapport s'il était possible d'utiliser la version multi-plateforme de Kotlin en production, et ils disent qu'elle est toujours sous une forme expérimentale.
À l'autre bout il y a un Flutter, qui a décollé l'année dernière, ce truc est vraiment intéressant, Google n'est pas faiblement investi dans ce métier. Et je sais que beaucoup font des projets pour animaux de compagnie sur Flutter, qui sont déjà présentés dans les magasins d'applications. Et c'est plus intéressant pour nous. Nous en avons eu assez de Kotlin, avec Kotlin / Native, nous devons collecter beaucoup de râteaux, mais Flutter with Dart est une chose complètement nouvelle.
Nous aimons tout ce qui est nouveau, nous aurons donc certainement un développement multiplateforme. Pas spécifiquement dans l'application de transfert d'argent, mais dans certaines petites applications distinctes, ce sera le cas.
Groupe JUG.ru: Merci pour les réponses détaillées!