En 2018, lorsqu'il est possible de payer même un shawarma à l'aide d'Android Pay, un smartphone est le principal outil financier de l'utilisateur. Maintenant, les gens veulent résoudre avec son aide en général tous les problèmes liés à l'argent. Ainsi, les applications mobiles correspondantes sont devenues particulièrement pertinentes.
Pour les applications financières développées par CFT pour différents clients, le nombre total d'installations est de plusieurs millions, c'est-à-dire que peu peuvent se prévaloir d'une telle expérience dans ce domaine. Profitant du fait que la société était présente à notre conférence Mobius, nous avons posé au chef du groupe de développement d'applications Android
Mikhail Emelyanov plusieurs questions sur l'aspect du développement Android dans CFT.
- Tout d'abord, parlez-nous brièvement de «CFT» pour ceux qui n'ont pas entendu ce nom auparavant.- L'entreprise opère sur le marché des fintech depuis plus de 25 ans: à son apparition, il n'existait même pas de concept de fintech, mais même à l'époque, elle produisait des produits et services qui s'appellent désormais ainsi. En fait, le nom même de «Center for Financial Technologies», apparu au début des années 90, reste d'actualité et parle de lui-même.
Bien sûr, beaucoup de choses ont changé au cours du temps passé (qui aurait pu imaginer Android en 1991?), Mais l'essence est restée la même: CFT développe et développe des solutions informatiques et des services technologiques qui rendent les transactions financières simples et pratiques (y compris les transferts d'argent) et paiements).
L'entreprise est apparue à Novossibirsk Academgorodok, et son principal centre de développement y est toujours situé. Mais maintenant, outre lui, il existe des bureaux dans de nombreuses autres villes de Russie, ainsi qu'à Chisinau, Almaty et Douchanbé. La croissance se poursuit: de nouveaux services et unités apparaissent constamment, la direction R&D se développe activement.
- Et combien de personnes sont spécifiquement engagées dans le développement mobile, et pouvez-vous donner des exemples d'applications développées dans le CFT?—Nous avons une équipe mobile distribuée à Novossibirsk, Tomsk et Saint-Pétersbourg. Maintenant, c'est plus de 50 personnes, mais l'entreprise a des plans pour le développement mobile que nous devons croître deux fois plus vite pour les égaler.
Nos applications les plus populaires pour iOS et Android sont les
transferts d'argent (plus de 1,3 million de téléchargements sur Google Play), les bureaux de paiement
Beeline et
Corn .
De plus, notre
fournisseur de services bancaires en ligne
Faktura.ru propose plus de 100 applications mobiles personnalisées pour iOS et Android. Au total, l'équipe Faktura.ru a mis en œuvre 340 projets de banque en ligne pour les entreprises et les particuliers. En général, environ 130 banques opèrent sur cette plateforme technologique.
- Le travail avec les finances a ses spécificités - en quoi le développement d'Android dans CFT diffère-t-il de l'entreprise «moyenne»?- Puisque nous travaillons avec les données personnelles et les finances des utilisateurs, l'une des principales règles est des exigences strictes pour la protection des informations. Nous traitons régulièrement des sujets tels que la sécurisation des services bancaires mobiles au niveau de l'API et lors du transfert de données, l'authentification biométrique, le trousseau, l'épinglage SSL, etc. Nous avons accumulé beaucoup d'expérience pertinente, c'est pourquoi Mobius vient de
présenter le rapport «Fondamentaux de la sécurité des applications mobiles».
Mais en même temps, le développement mobile en fintech ne se transforme pas en une conformité continue aux exigences de sécurité, dissociée des désirs des vivants. Les utilisateurs finaux sont toujours des millions de citoyens ordinaires. Désormais, tout le monde contrôle les opérations monétaires à partir d'un smartphone - il paie les services, transfère de l'argent. Et nos produits finaux ciblent spécifiquement ces personnes.
Par conséquent, dans la fintech, il est assez intéressant de s'engager uniquement dans le développement mobile: les utilisateurs finaux sont, en fait, nous sommes avec vous. Les applications doivent donc non seulement être sûres, mais aussi simples, aussi technologiques que possible. Nous ne créons pas quelque chose dans le vide, mais un produit pour le consommateur.
- En plus de protéger les informations, vous devez également être particulièrement stable: si une startup peut obtenir des erreurs de production, elle attend la fiabilité des finances. Mais en même temps, se transformer en une lente «cascade» et tout coordonner pendant six mois est également impossible. Comment résolvez-vous ce problème?- Tout d'abord, avec une approche architecturale. Nous avons pris l'idée d'une architecture propre comme standard, et ses principes sont développés sur des applications réelles. Nous faisons de nouvelles applications dans le cadre de la division en couches, responsabilité unique et entités faiblement connectées.
Bénéfice: l'utilisation de diverses technologies sans avoir à réécrire tout le code, de haute qualité grâce à des tests et, surtout, une évolutivité simple, ce qui est très important pour nous.
Nous avons également la révision de code la plus stricte, presque toute l'équipe y participe, et nous détectons la plupart des moments difficiles au stade de la révision, afin qu'ils n'atteignent pas la production.
Bien sûr, les tests - presque partout où nous couvrons les tests unitaires, certains développeurs écrivent du code en utilisant la méthodologie TDD. Bien sûr, l'interface utilisateur n'est pas en TDD, mais nous n'oublions pas non plus les tests d'interface: avec une équipe de testeurs, nous avons travaillé pour s'assurer qu'ils utilisent Espresso aussi efficacement que possible.
- La fintech nécessitant du conservatisme, cela peut dans certains cas interférer avec l'utilisation des nouvelles technologies. Par conséquent, il est intéressant de se demander: quelles nouveautés avez-vous essayé dans Android au cours de la dernière année? Et quelles technologies, au fait, utilisez-vous du tout?- Beaucoup d'essais. Lorsque Google a publié la version d'Android Architecture Component, nous avons décidé de l'expérimenter et de l'implémenter dans l'un des nouveaux projets. Mais nous sommes tombés sur un râteau: par exemple, nous ne voyions pas dans son ViewModel un moyen suffisamment efficace pour résoudre le problème du cycle de vie de notre projet. Mais LiveData nous a semblé utile pour la couche présentation.
Après que le résultat de l'AAC n'ait pas été à la hauteur des attentes, nous l'avons supprimé, en le remplaçant par une approche plus efficace. Grâce à l'architecture épurée, nous n'avons pas eu besoin de refaire toute l'application, il suffisait d'affiner la couche de présentation. Il existe un autre exemple d'utilisation de la nouvelle salle ORM.
Nous développons actuellement activement chez Kotlin. Chez Mobius, beaucoup se demandaient «pourquoi Kotlin est partout», mais cela le prie. Il offre plus de fonctionnalités que Java hors de la boîte: il y a beaucoup moins de code, plus de fonctionnalités. Beaucoup peut être fait avec une seule ligne de code, comme déclarer des classes. Maintenant, nous essayons également des coroutines dans l'un des projets.
En général, nous aimons la façon dont Kotlin se développe et nous sommes heureux que sa communauté se développe. Et comme il est devenu si répandu, maintenant, pour ne pas le développer, il faut avoir des croyances et des principes très forts.
Nous utilisons également RxJava / RxKotlin, Retrofit et Dagger 2, la liaison de données de Google, nous prévoyons d'essayer RxBinding, pendant longtemps tout peut être répertorié. En général, la fintech n'interfère pas avec le jeu complet avec diverses technologies.
- Les composants d'architecture Android ne vous convenaient pas - mais pouvez-vous les recommander à d'autres? Dans quelle mesure la migration vers ces ressources a-t-elle été intensive: les projets de longue date devraient y penser ou vaut-il mieux la laisser nouvelle?«Bien que l'AAC n'ait pas été à la hauteur de nos attentes, ils réussissent bien pour certaines tâches: par exemple, enregistrer et restaurer des données lors du changement d'orientation de l'écran. Donc, si dans un projet avec un tas de support de code hérité pour changer d'orientation est inefficacement implémenté, alors vous devriez penser à utiliser AAC. Mais pour implémenter cela de manière malheureuse, cela ne fonctionne pas, vous devez d'abord préparer l'architecture, corriger les erreurs critiques et trouver des points d'intégration afin de ne pas traiter l'ensemble de l'application.
- La salle susmentionnée est une technologie assez récente que beaucoup n'ont pas encore eu le temps d'essayer. C'est donc intéressant: quelle a été votre expérience avec elle?- La chambre nous a plu. À l'aide d'annotations, vous pouvez facilement décrire la création de tables, définir des transactions, etc. Il existe un support intégré pour Kotlin, Rx, LiveData. Parmi les inconvénients de la version stable actuelle (1.1.0), il y a le manque de commandes pour nettoyer la base de données et la nécessité de configurer les communications manuellement. Il y avait encore de petites choses inconfortables lors de l'utilisation de Room dans Kotlin, mais ils ont progressivement décidé avec la sortie de nouvelles versions. Par exemple, les méthodes de transaction par défaut dans les interfaces ne sont prises en charge que dans 1.1.0-alpha2.
En général, avec Room, travailler avec des bases de données est devenu beaucoup plus pratique et efficace.
- Il y a un point de vue «tous vos ORM sont sournois, les abstractions continuent de couler et vous devez descendre au niveau SQL» - qu'en pensez-vous?- Dans toute technologie, pour résoudre des tâches non triviales, vous devez écrire du code, même SQL. L'essentiel est que cela ne se transforme pas en frais généraux. Dans Room, vous pouvez également écrire des requêtes SQL à la main (par exemple, des migrations ou des requêtes complexes), mais grâce aux annotations, il est beaucoup plus pratique de le faire. Par exemple, vous pouvez extraire des données de plusieurs tables à l'aide de Relation.
- Puisque CFT est plus ancien qu'Android lui-même, la question de Legacy est probablement pertinente pour vous. Refactorisez-vous souvent?- Bien sûr, le code hérité existera dans n'importe quel projet. Et la déclaration populaire «tout code écrit aujourd'hui, demain devient hérité» est tout à fait vrai.
Il en est de même pour nous. Il y a des applications qui ont été lancées il y a plusieurs années. S'il y a des raisons objectives de changer le code entier (bogues, faible évolutivité, manque de technologies efficaces, etc.), alors nous le faisons. Nous effectuons une refactorisation étape par étape, en parallèle, nous publions des fonctionnalités où le code est traité par des composants, des couches ou simplement des écrans.
Aussi dans l'utilisation de la technologie. Par exemple, dans l'un de nos projets, Volley a été utilisé comme client http. La technologie n'est pas nouvelle et nous voulions passer à OkHttp + Retrofit. Pour ce faire, nous avons analysé les connexions du projet avec le reste du client, préparé l'architecture pour la transition et nous y sommes déplacés à la fois, sans y consacrer beaucoup de temps.
- CFT a des cours, y compris Android - et qu'y enseignez-vous? Et selon votre expérience, qu'est-ce qui manque le plus aux développeurs Android novices?- Oui, il existe plusieurs projets pédagogiques dans le CFT. Pour les étudiants juniors - SHIFT School, dans le cadre duquel nous avons conduit un cours de développement de base Android basé sur NSU. Et pour les étudiants seniors et juniors - le projet Focus Start, où il y a 6 cours multidirectionnels, y compris le développement mobile (Android et iOS). Le programme de cours Android fournit une connaissance approfondie d'Android, Java, Kotlin, Rx. Déjà sorti plusieurs sets, certains des meilleurs diplômés sont devenus nos employés.
Souvent, les développeurs Android novices n'ont pas l'expérience de l'utilisation de la POO, le principe SOLIDE. Certains ne comprennent pas la différence entre les modèles MVC - MVP - MVVM et les principes de l'architecture propre, car ils méconnaissent la logique métier.
Il existe également des lacunes dans le SDK Android, Java, une compréhension du multithreading et comment il est implémenté dans Android. Eh bien, les principes de base: comprendre Rx, Dagger, Retrofit. Beaucoup n'essaient pas de lire la documentation des différentes technologies.
Mais notre pratique montre que les formations intensives comblent les lacunes assez rapidement et efficacement pour travailler en informatique.
