Combien d'applications russes sur Google Play disent «50 000 000+ installations»? De toute évidence, chacun de ces cas est une histoire unique avec ses propres spécificités, il serait donc intéressant de discuter avec les développeurs. Et quand une telle application a également une note de 4,6, cela renforce l'intérêt.
Vladimir Tebloev est l'une des personnes travaillant sur l'application Android
Sberbank Online . Au printemps, lorsque Sberbank Technologies a participé à notre conférence
Mobius , il y a fait un reportage, et maintenant nous avons décidé de demander à Vladimir les caractéristiques de son travail.
- D'abord, dites-nous ce que vous faites exactement?- Dans l'application Sberbank Online, je suis engagé dans le service Dialogs, qui permet aux utilisateurs de transférer de l'argent en un clic et de voir l'intégralité de l'historique des transferts en plein écran. Le service est accessible à tous les utilisateurs de l'application - il compte désormais 37 millions de personnes.
Je travaille chez SberTech depuis l'été 2016 - puis, dans le cadre de la candidature, il n'y avait toujours pas de division en équipes distinctes. Et plus tard, lorsque, dans le cadre de la transition vers l'agile, ils ont commencé à affecter différentes équipes à des modules d'application distincts, l'une des premières était l'équipe Dialogs, et depuis lors, j'y suis.
- Tout le monde a les mots «Sberbank» et «développement mobile» associés à Sberbank Online. Mais dans une si grande entreprise, existe-t-il probablement aussi un développement mobile interne? Est-ce différent de l'extérieur?- Oui, il existe également des applications à usage interne. Je n'ai rien à voir avec eux, mais je sais que React Native y est activement utilisé. Le développement interne a ses propres exigences: il n'y a pas de revue de conception stricte et d'animation sophistiquée; le développement est plus rapide en utilisant une solution multiplateforme.
Lorsque l'expertise se développera, il sera possible de l'appliquer sur une application «combat». Bien que Sberbank Online puisse utiliser activement le développement multiplateforme, j'en doute. Les difficultés sont nombreuses et lorsque vous avez des dizaines de millions d'utilisateurs, même un problème rare peut blesser tant de personnes.
- Et comment ce «même un problème rare fait du mal à beaucoup» affecte le travail? Devez-vous faire face à des problèmes exotiques que de petites applications peuvent passer sous le radar?- Parfois, il y a des problèmes sur certains appareils «spéciaux». Sur un firmware personnalisé mais répandu, il a tiré fort, et nous avons dû le comprendre pendant longtemps. Il s'est avéré que le problème était dans le pilote de la carte mère du périphérique lui-même - il a essayé d'émuler des bibliothèques sous ARMv5, bien que le projet ne soit que pour ARMv7.
Lorsqu'il y a beaucoup d'utilisateurs et que le prix de l'erreur est élevé, cela conduit au fait que tout doit être déployé «un peu», en suivant attentivement les rapports. Si quelque chose se lève là-bas, nous arrêtons immédiatement de rouler et faisons un correctif. En plus de rouler «par un pourcentage donné d'utilisateurs», nous déployons également géographiquement tout en plusieurs parties: Sberbank a le concept de «banque territoriale», et les fonctionnalités peuvent progressivement se déployer par région.
- Alors qu'une startup hipster peut mettre une version MinSdkVersion élevée et dire «tout le monde n'est pas notre public», vous avez une situation différente, vous ne pouvez pas saluer les gens. Quelle est votre valeur MinSdkVersion actuelle?- Maintenant, c'est 16, et nous l'avons littéralement levé l'année dernière à partir de 14. Nous regardons le nombre de clients avec un SDK spécifique, et nous pouvons augmenter la version si elle devient inférieure à 5%. Jusqu'à présent, nous avons de nombreux utilisateurs d'Android 4.4 KitKat, environ 16% - nous devons les prendre en charge.
- Y a-t-il des nouvelles versions que vous regardez en ce moment et pensez: "Dès que nous augmentons MinSdkVersion, utilisons-nous immédiatement?"- Bien sûr, je voudrais augmenter notre API minimale à Android 5.0 afin de tirer pleinement parti d'innovations telles que, par exemple, l'animation de transition, qui fonctionnera correctement et partout. Mais, en principe, cela ne s'applique pas à la fonctionnalité d'écriture, à la logique métier, ce n'est donc pas critique. En général, les animations sont élaborées par nos concepteurs, c'est-à-dire qu'elles peuvent être implémentées manuellement. Ce problème n'est donc pas critique, il concerne le confort, la «tranquillité d'esprit» du développeur.
Dans certains cas, nous vérifions la version, par exemple, l'épinglage SSL. Il fonctionne différemment dans différentes versions d'Android, nous implémentons donc deux versions du code, pour les appareils Android «jusqu'à 4.4» et «à partir de 4.4».
Bien sûr, je voudrais "simplement développer pour Android P et ne penser à rien" - mais c'est toujours le cas, il n'y a rien.
- À l'épinglage SSL mentionné. De toute évidence, les questions de sécurité sont très importantes pour la banque. Et en quoi cela vous affecte-t-il, en quoi votre travail est-il différent de travailler sur une application non bancaire?- Il présente une approche très stricte des données personnelles de l'utilisateur. Toute fuite est un risque énorme. Nous avons un service de sécurité qui teste notre application avant chaque version. S'il y a des commentaires, leur travail passe à l'équipe qui est responsable de la fonctionnalité avec la vulnérabilité découverte.
Dans les petites entreprises, je pense, souvent il n'y a pas de service de sécurité qui teste l'application. Si des hauts-fonds sont trouvés, ils peuvent apparaître sur w3bsit3-dns.com ou une ressource similaire.
La sécurité est également liée au fait que notre application utilise un antivirus. Certains utilisateurs sont mécontents de sa présence, mais l'introduction de l'antivirus nous a permis de réduire très sensiblement la fraude. Par exemple, dans notre banque de SMS, où vous pouvez écrire des SMS «montant de transfert vers la carte X», avec un antivirus, le niveau de fraude dans cette direction a été réduit au minimum.
- Pour des raisons de sécurité, les banques limitent leurs fonctionnalités dans le cas de smartphones rootés. Qu'est-ce qui est interdit pour Sberbank Online pour les appareils rootés?- En juin, nous avons abandonné la fonctionnalité limitée pour les propriétaires d'appareils disposant de droits root. Tous les utilisateurs de Sberbank Online sur Android disposent désormais de toutes les fonctionnalités. Dans le même temps, la protection reste au même niveau grâce au système de surveillance des fraudes.
- Et au nom de la sécurité, il fallait restreindre en quelque chose non pas les utilisateurs, mais eux-mêmes en tant que développeurs, refusant de les utiliser autrement?- Quand en 2015 nous avons voulu introduire Retrofit, il a eu des problèmes d'obscurcissement, il a travaillé de façon tordue avec un obfuscateur standard. Notre service de sécurité a souligné cette vulnérabilité, lourde d'une cyberattaque contre la banque et les risques de rupture du code, au fur et à mesure de la sortie de l'API. Ensuite, nous avons abandonné Retrofit et ne l'utilisons toujours pas. Autant que je sache, maintenant les problèmes avec l'obfuscateur standard y sont déjà résolus. Mais nous avons depuis écrit notre propre client HTTP, cela fonctionne et satisfait tout le monde, de nombreux wrappers ont déjà été écrits pour cela pour différentes équipes travaillant avec différents serveurs. Il est inutile de le remplacer par Retrofit.
- La question inévitable: qu'avez-vous avec Kotlin?- Nous allons dans sa direction, mais tranquillement. La difficulté est que de nombreux développeurs Android de différents niveaux travaillent immédiatement sur l'application, quelqu'un connaît parfaitement Kotlin, quelqu'un ne le sait pas. En général, il n'y a pas d'obstacles insurmontables à la mise en œuvre, mais nous avons maintenant une pénurie de réviseurs pour regarder le code Kotlin. Si nous commençons tous à écrire brusquement demain à Kotlin, alors les gens «déchireront» les demandes. De plus, dans le cas de Kotlin, il y a des problèmes avec l'analyseur de code statique, qui est utilisé dans notre pipeline.
Ainsi, Kotlin est implémenté en petites étapes: par exemple, nous écrivons des tests sur Kotlin et utilisons des classes de données (nous gagnons donc du temps afin de ne pas écrire de tests pour les getters, setters, equals (), hashCode () et ainsi de suite).
Maintenant, il fonctionne lentement, et à l'étape suivante, nous voulons écrire notre DSL pour le tester sur Kotlin. Et en parallèle, nous voulons élever le niveau de connaissances Kotlin dans l'entreprise: par exemple, à l'aide de mitaps.
- Dans le cas de "Dialogues", vous êtes engagé dans la messagerie, mais pas un analogue direct de WhatsApp. Et c'est donc intéressant: dans quelle mesure les solutions des autres sont-elles utiles? Utilisez-vous des messagers open source dans le code?- C'était utile lorsque nous voulions ajouter des émoticônes. Nous avions une question sur la façon de créer un panneau avec eux, et dans l'open source, nous avons vu une option où tout est facilement résolu par une fenêtre contextuelle au-dessus du clavier. Ensuite, tout converge en hauteur, et cela se révèle parfaitement pour l'utilisateur.
Mais en général, regarder les décisions des autres n'est pas toujours bon, il est plus efficace de se former soi-même, en tenant compte de l'expérience des autres. Par exemple, il vaut mieux ne pas regarder du tout Telegram, car en raison de la taille énorme des classes dans le
code source de leur application Android, il n'est pas facile de le comprendre. Nous essayons de suivre notre propre chemin, d'autant plus que l'interaction avec le serveur peut être différente: dans le même Telegram c'est MTProto, nous avons les WebSockets habituels.
- Je suis un intervieweur paresseux, j'ai donc décidé de prendre une liste de choses avec lesquelles vous êtes connecté au travail et de poser des questions sur chaque élément «dites-nous exactement comment les choses se passent avec ça»
Premier point: vous êtes dans «l'architecture du module d'application». Nous avons déjà dit que l'application est divisée en modules - que pouvez-vous dire d'autre sur l'architecture?- Il évolue de manière itérative avec nous, le versioning est en cours, nous avons maintenant atteint la 17e version.
Le 16, l'architecture propre a été introduite. Nous nous sommes mis d'accord sur qui est responsable de quoi (présentation, domaine, couche de données), quelles entités et où devraient être utilisés, où devraient être les convertisseurs - en général, ils ont peint tous les problèmes architecturaux et les ont mis en œuvre.
Implémenté comme suit: toutes les nouvelles fonctionnalités devaient être écrites sur notre nouvelle architecture. Si, dans la demande de tirage, quelque chose s'écarte de la norme définie, une telle demande de tirage est révisée. Mais en même temps, ils ne se sont pas immédiatement précipités pour voir toutes les anciennes fonctionnalités, car cela peut causer de nombreux problèmes.
Pour la couche présentation, nous avons choisi la norme MVP, mais certaines de nos équipes utilisent MVVM. Dans la couche présentation, nous ne sommes limités par rien. Par exemple, nous avons vu notre discussion sur MVI - plus précisément, sur notre implémentation intéressante de MVI, qui est fondamentalement différente de ce que le développeur Mosby a écrit.
Nous sommes ensuite passés à la version 17 de l'architecture et avons implémenté RxJava, ce qui a entraîné des modifications architecturales. Si nous utilisons des définitions strictes, maintenant notre architecture s'est avérée être hexagonale, de Clean nous avons «fourchu». Mais ils sont similaires en ce que les deux fonctionnent selon les principes SOLIDES, donc l'un se fond dans l'autre assez facilement. Maintenant, nous y travaillons.
Dans les futures versions de l'architecture, nous voulons abandonner le framework Moxy utilisé pour implémenter MVP, car cela pose quelques difficultés. Le projet est volumineux, il utilise le traitement des annotations et lorsque vous apportez des modifications aux modules du "niveau inférieur", le temps de construction est long. Et nous nous efforçons de faciliter la vie de nos développeurs.
- Le deuxième point est «l'optimisation de la consommation de travail et de mémoire». Quelle est la gravité de cette question, dois-je y penser constamment pour les utilisateurs d'appareils plus anciens?- Ce problème est au centre des équipes de la plateforme, elles développent des outils qui utilisent les équipes. La nécessité de le faire se présente plutôt comme le besoin d'une des équipes. Par exemple, dans l'équipe Dialogues, aux premiers stades de développement, le chat était très lent. Ensuite, j'ai dû retrousser mes manches, commencer par le profileur, voir où étaient les goulots d'étranglement dans l'application, comprendre les raisons de leur apparition.
En termes d'optimisation, par exemple, nous avons abandonné le PNG et l'avons progressivement éliminé du projet afin de n'utiliser que le vecteur. L'optimisation du graphe de dépendances dans Dagger est prévue cette année pour accélérer le démarrage à froid de l'application.
- Passons aux questions de test: comment ça se passe avec toi?- Je ne peux parler que de notre équipe, dans d'autres ce processus peut être construit différemment.
Notre équipe avait initialement un testeur. Par la suite, il s'est ennuyé avec juste des tests. Et il a commencé à nous demander de participer à la rédaction des tests unitaires. Nous lui avons montré comment écrire des tests pour la base de données, essentiellement pour l'analyse - et de cette façon, il nous a déchargés, nous a enlevé une partie du travail. C'est bien: il est intéressé, et nous.
Au fil du temps, nous sommes arrivés à la conclusion que nous devons automatiser la régression, nous devons écrire des tests d'interface utilisateur. Au début, mon partenaire et moi avons travaillé sur des tests d'interface utilisateur, puis le département qualité nous a rejoint - nos testeurs qui ont testé le backend dans le passé. Ils connaissent Java, et maintenant ils sont connectés à notre projet pour automatiser toute la régression. Nous nous sommes assis et avons examiné les solutions qui sont: Appium, Espresso, Selenium.
Nous nous sommes arrêtés à Espresso et avons commencé à développer des approches ensemble. Pour faciliter les tests, nous avons développé notre propre framework, quelque chose comme Kakao. Nous avons commencé ce travail au début de 2017, et nous avons maintenant un grand cadre, et la plupart des tests sont assemblés en tant que constructeur, car de nombreux matchs et jeux d'action ont été écrits pour diverses situations.
Maintenant, nos testeurs nous demandent activement de leur apprendre à écrire des tests d’interface utilisateur, car il est plus facile d’écrire un test une fois que de «percer» les mêmes actions sur cinq appareils. Mais, bien sûr, vous n'automatisez pas tout et certains cas doivent encore être vérifiés manuellement.
Quant aux développeurs, une rétrospective se tient dans notre équipe toutes les deux semaines. Dans l'un d'eux, nous sommes arrivés à la conclusion que les développeurs devraient effectuer au moins des tests alpha après avoir écrit une fonctionnalité. Afin de ne pas sortir de bugs complètement basiques de la forme «l'application plante au démarrage». Ainsi, les développeurs se sont également connectés aux tests. Lorsque nous préparons une version majeure et que nous devons tester rapidement la fonctionnalité, tout le monde s'assoit pour la régression et passe ensemble les tests de régression. Lorsqu'un bogue est détecté, les développeurs se déconnectent de la régression, corrigent rapidement et à nouveau.
- Article suivant: révision du code. Avez-vous des détails ou "comme tout le monde"?- Il existe une spécificité due au nombre de développeurs. Lorsqu'il y a dix développeurs mobiles dans une entreprise, deux ou trois personnes peuvent tout revoir. Et comment réviser le code de centaines de personnes? Nous avons développé une «matrice d'examen». 20-30 personnes ont été sélectionnées, dont nous savons avec certitude qu'elles peuvent bien faire de la publicité, laisser des commentaires et résoudre des points controversés dans les commentaires. Ils ont pris ces gens et ont divisé toutes les équipes entre eux.
Pourquoi une matrice? Il s'agit de s'assurer que tous les réviseurs ont la même charge. Comment se passe l'examen? Notre équipe nécessite au moins trois évaluations. Le premier vient d'un membre de l'équipe. Le second - de quelqu'un de l'extérieur, d'une équipe qui ne s'occupe pas de cette fonctionnalité. Et la troisième approbation - de quelqu'un d'une équipe adjacente. Dans notre cas, il existe plusieurs commandes associées, et elles regardent toutes notre code. Eh bien, en conséquence, toutes les versions doivent être collectées: les tests unitaires et les tests d'interface utilisateur doivent passer sans problème. Nous avons donc une révision du code.
- Le point suivant est la refactorisation du code hérité. Comment cela se passe-t-il systématiquement: précisément avec les tâches planifiées, ou "avez-vous eu besoin de modifier l'ancien code - en même temps de le refactoriser"?- En général, nous avons un «principe scout» particulier: si vous touchez quelque chose de vieux - soyez assez gentil pour le faire correctement, vous êtes maintenant co-auteur. Mais une refactorisation est également prévue. Par exemple, pour Dialogs, une refactorisation de deux directions était nécessaire: le carnet de contacts que nous utilisons et les traductions. Le carnet de contacts a été retiré, nettoyé, réécrit toute la base de données sur Room, réalisé dans un module séparé. Et nos paiements ont été écrits il y a longtemps avec RoboSpice, si vous vous en souvenez encore, et cela nous a fait mal. Je dois dire que couper cela était une tâche désagréable, car il y avait beaucoup de liens avec elle. Et vous deviez le nettoyer subtilement, afin de ne pas casser le reste de la fonctionnalité.
- Même à Sbertekh, vous êtes impliqué dans la formation de programmeurs. À quoi ressemble la formation au sein de l'entreprise?- Depuis septembre, il est prévu de réaliser un tel programme de reconversion des salariés internes. Maintenant, nous avons déjà défini une gamme de sujets sur Java et Android. Par exemple, nous avons des javascript, des javistes et des analystes qui souhaitent se recycler sur Android. Une telle école sera organisée pour eux, où il y aura une étude ciblée, selon le calendrier et des conférences.
Et maintenant, nous organisons régulièrement des mitaps. Le choix des sujets pour eux n'est pas le même que lors des conférences, où quelque chose de nouveau et de battage médiatique est nécessaire. Par exemple, si nous savons que les développeurs ont des problèmes avec quelque chose, il est important d'en parler. De récente - l'un de nos développeurs a parlé de graphiques vectoriels. Pas seulement une bibliothèque spécifique qui dessine magnifiquement des vecteurs sur Android, mais a commencé avec le fonctionnement des graphiques vectoriels en général, puis est passée à la bibliothèque privée. Ils ont parlé de Room et de la concurrence Java, avec laquelle de nombreux développeurs ont des problèmes, et de Dagger 2.
L'année dernière, nous avions une école de développement Android et nous avons embauché ceux qui l'ont terminée avec succès. Ces personnes ne devraient pas être immédiatement connectées à certains projets et laissées à cuisiner seules. Par conséquent, un mentor est assigné à chaque employé nouveau venu ainsi qu'au junior, qui le guidera, le développera et l'aidera. Il s'agit d'un apprentissage interne.
- Entretiens: les avez-vous «comme tout le monde», ou y a-t-il une spécificité?- J'avais l'habitude de penser que "comme tout le monde", mais au final il s'avère qu'ils sont encore un peu spéciaux. D'après mon expérience, il existe trois approches courantes sur le marché. Le premier est posé sur trois ou quatre sujets et évalué uniquement sur eux. Par exemple, je suis arrivé dans l'entreprise en tant que développeur Android, et je suis considéré comme une personne qui doit avoir une excellente connaissance des algorithmes et de la synchronisation en Java, et en même temps ne pas apprécier ce que je fais dans les super bibliothèques. , , - . — , 30-40 . , , . — - . , , . , .
, : , OOD (Object Oriented Design, ), Java Core Android SDK. . , , . : , , - . . , , , Dagger 2, RxJava. , Kotlin. , . - , , , . , .
— « ». - , .— — RxJava, , . , , . .
Retrofit, : , , . , — .
TinyMachine - — , , , . , «» , , . -, , - rocket science, .
— : . , , ?- Oui. — Java-. « »: Java- — - («» — Android-: , , , ). , , , — Java-. , . , , , , « payment? payment payment ? paymentTest?».
, Confluence. , material design , - , . , , Confluence. , , , , , , . : RxJava Confluence best practices — , , . : , .
, . Confluence 200 . . Confluence, , , .
