En 2018, cuando es posible pagar incluso un shawarma con Android Pay, un teléfono inteligente es la principal herramienta financiera para el usuario. Ahora la gente quiere resolver con su ayuda en general todos los problemas relacionados con el dinero. Por lo tanto, las aplicaciones móviles correspondientes se han vuelto especialmente relevantes.
Para las aplicaciones financieras desarrolladas por CFT para varios clientes, el número total de instalaciones es de millones, es decir, pocos pueden presumir de tal experiencia en esta área. Aprovechando el hecho de que la empresa estuvo presente en nuestra conferencia de Mobius, le hicimos varias preguntas al jefe del grupo de desarrollo de aplicaciones de Android
Mikhail Emelyanov sobre cómo se ve el desarrollo de Android en CFT.
- Primero, cuéntenos brevemente sobre "CFT" para aquellos que no han escuchado este nombre antes.- La compañía ha estado operando en el mercado fintech durante más de 25 años: cuando apareció, ni siquiera existía un concepto de fintech, pero incluso entonces produjo productos y servicios que ahora se llaman así. En realidad, el mismo nombre "Centro de Tecnologías Financieras", que apareció a principios de los 90, sigue siendo relevante y habla por sí mismo.
Por supuesto, mucho ha cambiado en el pasado (¿quién podría haber imaginado Android en 1991?), Pero la esencia sigue siendo la misma: CFT desarrolla y desarrolla soluciones de TI y servicios tecnológicos que hacen que las transacciones financieras sean simples y convenientes (incluidas las transferencias de dinero) y pagos).
La compañía apareció en el Novosibirsk Academgorodok, y su principal centro de desarrollo todavía se encuentra allí. Pero ahora, además de él, hay oficinas en muchas otras ciudades de Rusia, así como en Chisinau, Almaty y Dushanbe. El crecimiento continúa: nuevos servicios y unidades aparecen constantemente, la dirección de I + D se está desarrollando activamente.
- ¿Y cuántas personas se dedican específicamente al desarrollo móvil, y puede dar ejemplos de aplicaciones desarrolladas en el CFT?—Tenemos un equipo móvil distribuido en Novosibirsk, Tomsk y San Petersburgo. Ahora son más de 50 personas, pero la compañía tiene planes para el desarrollo móvil que debemos crecer el doble de rápido para igualarlos.
Nuestras aplicaciones más populares para iOS y Android son las
transferencias de dinero (más de 1.3 millones de descargas en Google Play), las oficinas de pago
Beeline y
Corn .
Además, nuestro
proveedor de banca en
línea Faktura.ru tiene más de 100 aplicaciones móviles personalizadas para iOS y Android. En total, el equipo de Faktura.ru ha implementado 340 proyectos de banca en línea para clientes corporativos y privados. En general, alrededor de 130 bancos operan en esta plataforma tecnológica.
- El trabajo con las finanzas tiene sus propios detalles: ¿en qué se diferencia el desarrollo de Android en CFT de la compañía "promedio"?- Dado que trabajamos con datos personales y finanzas de los usuarios, una de las reglas principales son los requisitos estrictos para la protección de la información. Regularmente tratamos temas como asegurar la banca móvil a nivel API y durante la transferencia de datos, autenticación biométrica, llavero, fijación de SSL, etc. Acumulamos mucha experiencia relevante, por eso Mobius acaba de
presentar el informe "Fundamentos de la seguridad de las aplicaciones móviles".
Pero al mismo tiempo, el desarrollo móvil en fintech no se convierte en un cumplimiento continuo de los requisitos de seguridad, divorciados de los deseos de las personas vivas. Los usuarios finales siguen siendo millones de ciudadanos comunes y corrientes. Ahora todos controlan las operaciones de dinero desde un teléfono inteligente: pagan por los servicios, transfieren dinero. Y nuestros productos finales están dirigidos específicamente a esas personas.
Por lo tanto, en fintech es bastante interesante participar solo en el desarrollo móvil: de hecho, los usuarios finales están contigo. Por lo tanto, las aplicaciones no solo deben ser seguras, sino también simples, lo más tecnológicas posibles. No estamos creando algo en el vacío, sino un producto para el consumidor.
- Además de proteger la información, también debe ser especialmente estable: si una startup puede obtener errores en la producción, entonces esperan confiabilidad de las finanzas. Pero al mismo tiempo, convertirse en una "cascada" lenta y coordinar todo durante medio año también es imposible. ¿Cómo resuelves este problema?- En primer lugar, con un enfoque arquitectónico. Tomamos la idea de la arquitectura limpia como estándar, y sus principios se están desarrollando en aplicaciones reales. Creamos nuevas aplicaciones en el marco de la división en capas, responsabilidad única y entidades débilmente conectadas.
Beneficio: el uso de varias tecnologías sin la necesidad de reescribir todo el código, alta calidad a través de pruebas y, lo más importante, escalabilidad simple, que es muy importante para nosotros.
También tenemos la revisión de código más estricta, casi todo el equipo participa en ella, y detectamos la mayoría de los momentos difíciles en la etapa de revisión, para que no lleguen a producción.
Bueno, por supuesto, las pruebas: en casi todas partes cubrimos las pruebas unitarias, algunos desarrolladores escriben código utilizando la metodología TDD. Por supuesto, la interfaz de usuario no está en TDD, pero tampoco nos olvidamos de las pruebas de interfaz de usuario: junto con un equipo de evaluadores, trabajamos para garantizar que utilicen Espresso de la manera más eficiente posible.
- Dado que fintech requiere conservadurismo, en algunos casos esto puede interferir con el uso de nuevas tecnologías. Por lo tanto, es interesante preguntar esto: ¿qué novedades has probado en Android durante el año pasado? ¿Y qué tecnologías, por cierto, utilizas?- Mucho intento. Cuando Google lanzó la versión de Android Architecture Component, decidimos experimentar e implementarla en uno de los nuevos proyectos. Pero nos encontramos con un rastrillo: por ejemplo, no vimos en su ViewModel un medio suficientemente efectivo para resolver el problema del ciclo de vida de nuestro proyecto. Pero LiveData nos pareció útil para la capa de presentación.
Después de que el resultado de AAC no estuvo a la altura de las expectativas, lo eliminamos y lo reemplazamos con un enfoque más eficiente. Gracias a la arquitectura limpia, no tuvimos que rehacer toda la aplicación, fue suficiente para refinar la capa de presentación. Hay otro ejemplo usando la nueva sala ORM.
Ahora estamos desarrollando activamente en Kotlin. En Mobius, muchos se preguntaron "por qué Kotlin está en todas partes", pero esto lo suplica. Proporciona más funciones que Java listas para usar: hay mucho menos código, más funcionalidad. Se puede hacer mucho con una sola línea de código, como declarar clases. Ahora también estamos probando corutinas en uno de los proyectos.
En general, nos gusta la forma en que Kotlin se desarrolla y nos complace que su comunidad esté creciendo. Y dado que se ha extendido tanto, ahora, para no desarrollarlo, uno debe tener creencias y principios muy fuertes.
También usamos RxJava / RxKotlin, el popular Retrofit y Dagger 2, el enlace de datos de Google, planeamos probar RxBinding, durante mucho tiempo todo se puede enumerar. En general, fintech no interfiere con el juego completo con varias tecnologías.
- Los componentes de arquitectura de Android no te convenían, pero ¿puedes recomendarlos a otros? ¿Cuán intensiva fue la migración hacia ellos: los proyectos de larga data deberían pensarlo, o es mejor dejarlo nuevo?“Aunque AAC no estuvo a la altura de nuestras expectativas, lo hacen bien para algunas tareas: por ejemplo, guardar y restaurar datos al cambiar la orientación de la pantalla. Entonces, si en un proyecto con un montón de soporte de código heredado para cambiar la orientación se implementa de manera ineficaz, entonces debe pensar en usar AAC. Pero implementar esto de una manera desafortunada no funciona, primero debe preparar la arquitectura, corregir errores críticos y encontrar puntos de integración para no procesar toda la aplicación.
- La sala mencionada anteriormente es una tecnología bastante reciente que muchos aún no han tenido tiempo de probar. Por lo tanto, es interesante: ¿cuál fue su experiencia con ella?- La habitación nos agradó. Usando anotaciones, puede describir fácilmente la creación de tablas, definir transacciones, etc. Hay soporte incorporado para Kotlin, Rx, LiveData. Una de las desventajas en la versión estable actual (1.1.0) es la falta de comandos para limpiar la base de datos y la necesidad de configurar las comunicaciones manualmente. Todavía había pequeñas cosas incómodas al usar Room en Kotlin, pero gradualmente decidieron con el lanzamiento de nuevas versiones. Por ejemplo, los métodos de transacción predeterminados en las interfaces solo se admitieron en 1.1.0-alpha2.
En general, con Room, trabajar con bases de datos se ha vuelto mucho más conveniente y eficiente.
- Hay un punto de vista "todos sus ORM son astutos, las abstracciones aún fluyen y usted tiene que bajar al nivel SQL". ¿Qué piensa sobre esto?- En cualquier tecnología, para resolver tareas no triviales, debe escribir código, incluso SQL. Lo principal es que esto no se convierte en una sobrecarga. En Room, también puede escribir consultas SQL a mano (por ejemplo, consultas de migración o complejas), pero a través de anotaciones es mucho más conveniente hacerlo. Por ejemplo, puede extraer datos de varias tablas usando Relación.
- Como CFT es más antiguo que Android, la pregunta de Legacy probablemente sea relevante para usted. ¿Sueles refactorizar?- Por supuesto, el código heredado existirá en cualquier proyecto. Y la afirmación popular "cualquier código escrito hoy, mañana se convierte en legado" es bastante cierto.
Así es con nosotros. Hay aplicaciones que se lanzaron hace varios años. Si hay razones objetivas para cambiar todo el código (errores, baja escalabilidad, falta de tecnologías efectivas, etc.), entonces hacemos esto. Realizamos una refactorización paso a paso, en paralelo lanzamos características donde el código es procesado por componentes, capas o simplemente pantallas.
También en el uso de la tecnología. Por ejemplo, en uno de nuestros proyectos, Volley se utilizó como cliente http. La tecnología no es nueva y queríamos cambiar a OkHttp + Retrofit. Para hacer esto, analizamos las conexiones en el proyecto con el resto del cliente, preparamos la arquitectura para la transición y pasamos a ella a la vez, sin perder mucho tiempo.
- CFT tiene cursos, incluido Android, ¿y qué enseñas allí? ¿Y qué, en su experiencia, les falta más a los desarrolladores novatos de Android?- Sí, hay varios proyectos educativos en el CFT. Para estudiantes junior: SHIFT School, en cuyo marco realizamos un curso de desarrollo básico de Android basado en NSU. Y para estudiantes senior y juniors: el proyecto Focus Start, donde hay 6 cursos multidireccionales, incluido el desarrollo móvil (Android e iOS). El programa del curso de Android proporciona un conocimiento profundo de Android, Java, Kotlin, Rx. Ya lanzamos varios sets, algunos de los mejores graduados se han convertido en nuestros empleados.
A menudo, los desarrolladores novatos de Android carecen de la experiencia de usar OOP, el principio SOLID. Algunos no entienden la diferencia entre los patrones MVC - MVP - MVVM y los principios de Arquitectura limpia, debido a esto no entienden la lógica del negocio.
También hay lagunas en el SDK de Android, Java, una comprensión del subprocesamiento múltiple y cómo se implementa en Android. Bueno, los básicos: entender Rx, Dagger, Retrofit. Muchos no intentan leer la documentación de varias tecnologías.
Pero nuestra práctica muestra que los intensivos de capacitación cierran las brechas lo suficientemente rápido y eficiente como para trabajar en TI.
