Dans la vie de presque toutes les équipes de développement, il arrive un moment où la création de notre propre cadre passe du statut de "Que diable devrions-nous perdre du temps?" au statut "Idée cool!". Nous avons eu un tel moment il y a environ deux mois, lorsque nous avons commencé à visser la commande vocale des transferts en utilisant Siri à l'application mobile cliente de PSB Mobile, PSB Mobile. Nous avons analysé notre expérience et sur cette base, nous vous dirons comment comprendre que le moment des frameworks est néanmoins venu.
"De quel cadre, de quoi parlez-vous?"
Auparavant, le client iOS de la banque pour les particuliers était développé en sous-traitance. Ensuite, il a été décidé de tout réécrire à partir de zéro. Nous avons construit un processus SCRUM avec des sprints de deux semaines, le travail a commencé à bouillir - nous recherchions activement et ajoutions de nouvelles fonctionnalités, des puces. À ce stade des recherches actives, il était difficile de prédire ce qui prendrait racine, ce qui ne le serait pas. Planifier tout 40 étapes à l'avance n'a aucun sens. Personne n'a pensé aux fioritures comme l'universalité - créez votre propre cadre, allouez des parties du code dans des bibliothèques distinctes pour les réutiliser. La probabilité que cela ne soit pas logique était trop élevée.
La WWDC nous a connectés
Pourquoi SCRUM est bon - nous contactons souvent l'entreprise en tant que client. Parallèlement, d'importants changements ont commencé à se produire. Nous avons commencé à mieux comprendre le produit, les tâches commerciales, les processus commerciaux de la banque dans laquelle l'application est impliquée. Et surtout, l'entreprise, pour sa part, a commencé à considérer le développement de l'application comme un processus, a commencé à mieux comprendre comment nous travaillons, a commencé à convenir avec nous qu'il y a des tâches importantes, dont la solution ne produit pas d'effet momentané notable.
Cela nous a aidés à nous entendre avec les affaires ... Conférence de la WWDC. Nos clients commerciaux ont en quelque sorte regardé les annonces de nouvelles opportunités Apple et sont montés sur Apple Developer avec curiosité. Étonnamment, tout s'est avéré beaucoup plus clair que prévu. Depuis lors, non seulement nous sommes impliqués dans des tâches commerciales, mais les entreprises n'ont plus peur de la technologie: elles essaient de lire les spécifications elles-mêmes, de mieux comprendre les problèmes, d'aider à l'analyse et d'entrer dans les problèmes de développement. Ils ont commencé à réaliser qu'il était inutile d'attendre une nette augmentation du produit toutes les deux semaines - après tout, il y a des sprints de service, à partir desquels il n'y a pas de croissance concrète. La compréhension mutuelle a atteint le point où nous avons accepté de donner au refactoring 20% ​​du temps de sprint.
L'évolution des vélos
Avec la croissance du département de développement, le remplissage de l'application avec de nouvelles fonctionnalités, l'apparition de plusieurs équipes travaillant simultanément sur différentes tâches, de nouvelles nuances ont commencé à apparaître. Certaines sous-tâches pour les équipes pourraient être similaires, et immédiatement il y avait un désir de ne pas réinventer la roue, mais d'abord de clarifier si quelqu'un avait un code prêt à l'emploi.
Il n'y a généralement pas de plaintes concernant le code de nos développeurs, il peut donc être utilisé à plusieurs reprises - et pas seulement dans le cadre de la méthodologie de réutilisation de code habituelle. Probablement, déjà à ce stade dans nos têtes, l'idée est venue de séparer certaines choses dans des bibliothèques distinctes pour le bien commun. Mais dans le cadre des tâches existantes, il n'a pas été possible de trouver du temps pour ces processus. Il avait besoin d'une raison, et bientôt l'entreprise nous l'a jetée.
Extension de déclenchement
Il y avait une tâche pour prendre en charge l'interface vocale - afin que vous puissiez effectuer des paiements à d'autres clients de la banque via Siri via un numéro de téléphone. Il dit: "Transférez tellement d'argent à une telle personne." Et si cette personne est un client de Promsvyazbank, alors la carte de la personne apparaît sur l'écran, le montant du transfert, la question "envoyer de l'argent?" et soumettre le bouton. Une fonction similaire existe déjà dans certaines applications bancaires, mais nous voulions la faire en sorte que, d'une part, elle soit sûre, et d'autre part, le client n'ait pas besoin d'accéder à l'application bancaire.
Travailler avec Siri implique d'écrire une extension séparée, et quand nous avons commencé à la planifier, nous avons réalisé qu'il était temps de développer nos propres frameworks. Dans notre projet d'application, une couche réseau a été implémentée, et un choix s'est fait (en fait, non): réécrire cette couche ou la placer dans un conteneur séparé, disponible à la fois dans l'application principale et dans une extension distincte.
Dans le processus, une sous-tâche architecturale a surgi pour retirer une partie du code dans des cadres distincts. Il y en avait quatre au total:
- Couche réseau (intermédiaire) - voici tout le travail avec le réseau, les classes de modèle, les services API. Cette couche est entièrement générée automatiquement.
- Se connecter
- Utilitaires - Utilitaires et aides
- Stockage - Stockage sécurisé
Il est clair que ce n'est pas notre savoir-faire. Il est donc habituel de le faire dans de telles situations, c'est la meilleure pratique de tous les développeurs qui se respectent. Mais il est important de savoir comment nous en sommes arrivés là . C'est à ce moment que
trois signes clés se sont réunis pour créer le cadre:
- Nous avons développé une base de code suffisante
- L'entreprise a commencé à comprendre nos (c'est-à -dire ses) besoins architecturaux.
- Une tâche appropriée est apparue
De nouveaux horizons
Après avoir réalisé que tout s'est avéré simple. Lors de la prochaine réunion des développeurs, nous avons discuté des détails, choisi la
victime de la personne responsable qui sera impliquée dans la refactorisation principale, lui avons alloué du temps - un temps plein pour cette tâche. Le reste des développeurs n'a presque pas affecté. Mais quand nous avons commencé à mettre la couche réseau dans le framework, des idées sont immédiatement apparues sur les autres parties du code fréquemment utilisées qui devraient être mises dans la bibliothèque. Nos possibilités architecturales se sont soudain élargies. Nous avons commencé la vie avec un degré de liberté supplémentaire.
Mais nous l'utilisons sans fanatisme. Pour décider de coder le code dans un module séparé ou non, nous examinons les backlogs et déterminons si ce module sera réutilisé à plusieurs endroits. Sinon, ne vous embêtez pas.
Voyons-nous les avantages de l'utilisation de nos cadres? Certainement oui. Nous voyons maintenant quelles parties du code requises dans le cadre de la nouvelle tâche sont déjà dans le référentiel. Le développement de nouveaux services est plus rapide, moins d'erreurs de programmation, la qualité des services finaux est plus élevée.
Si vous avez besoin de nouvelles extensions pour iOS, nous avons déjà les frameworks nécessaires, vous pouvez immédiatement expérimenter. Quant au service déjà implémenté avec Siri, il est à la disposition des utilisateurs bancaires depuis plus d'un mois - nous collectons maintenant des avis, notamment pour comprendre comment et pour quoi d'autre utiliser l'interface vocale.
Un peu de futurologie
L'histoire avec Siri nous a fait penser non seulement aux frameworks, mais aux interfaces en général. L'humanité n'a pas encore appris à mesurer la concentration de l'attention, seulement indirectement. Par exemple, plus l'UX et l'interface utilisateur sont pires, plus le gaspillage d'attention est important, plus l'entonnoir de conversion se rétrécit à chaque étape. Un transfert d'argent régulier via une application bancaire nécessite un tas d'actions de la part de l'utilisateur: ouvrez l'application, connectez-vous, recherchez dans une liste, dans la seconde, entrez le destinataire. Avec Siri, il s'agit d'un déverrouillage et d'une commande vocale. L'autorisation se produit au premier plan via Face ID. Et dans certains scénarios, vous n'avez même pas besoin de vous apporter le téléphone. Par exemple, lorsque vous conduisez et que le téléphone est installé à proximité, l'appareil photo peut facilement vous reconnaître.
Regardez autour de vous: les assistants vocaux commencent à conquérir activement l'espace environnant. Le battage médiatique autour de l'enceinte intelligente Yandex, les machines à laver qui parlent et comprennent les commandes, les télécommandes TV qui reconnaissent la voix. Plus les utilisateurs seront entourés d'interfaces vocales, plus ils seront prêts à communiquer avec les applications bancaires.
Les interfaces graphiques dans cette situation perdront leur monopole, des principaux moyens de communication elles se transformeront simplement en une confirmation visuelle de l'action, en un moyen de signaler que l'ordinateur vous a bien compris.
Pour le développeur, un tel changement, en principe, n'est pas effrayant. Avec la bonne architecture, l'application peut avoir un nombre illimité d'interfaces: visuelle, vocale, neuro. L'essentiel est d'utiliser des approches qui correspondent au niveau actuel de maturité de l'équipe.