¿Qué problemas surgen al aumentar el equipo móvil en 10 veces? ¿Por qué razones, en la misma compañía, los desarrolladores de Android prefieren usar bibliotecas conocidas y, en iOS, suelen escribir sus propias soluciones? ¿Cómo es la vida de los desarrolladores móviles en fintech?
El Centro de Tecnologías Financieras participó en nuestra conferencia de Mobius y, a este respecto, le preguntamos a dos empleados de CFT:
Kirill Zuev era responsable de iOS y
Mikhail Emelyanov era responsable de Android.
El texto resultó tan expandido que incluso creamos una tabla de contenido para que fuera fácil ir a una parte específica:
Acerca de la empresa
Grupo JUG.ru: Pregunta introductoria: cuéntenos sobre la empresa y lo que usted hace personalmente en ella.Kirill : Es imposible decirlo brevemente, ya que las áreas de negocios de CFT están muy diversificadas. Pero pruebe los "grandes detalles" sobre los productos y servicios más populares.
CFT ha estado operando en el mercado fintech ruso durante la tercera década, y decimos que hicimos fintech cuando tal concepto no existía.
Hoy, CFT es tanto el procesamiento como la producción de software para un gran número de diversas organizaciones financieras, compañías de seguros, corporaciones estatales y minoristas.
Este es el ecosistema de Golden Crown, que incluye un conjunto de servicios en formato b2c y b2b: cambio de moneda en línea, efectivo y transferencias de dinero en línea, pagos de préstamos, programas de fidelización, transporte y tarjetas sociales.
El centro de procesamiento "KartStandart": emisión y adquisición de tarjetas de sistemas de pago Mastercard, Visa y "Mir".
La "Ciudad" del Sistema Federal agrega varias decenas de miles de servicios diferentes: desde el pago de jardines de infantes y servicios públicos hasta el pago de impuestos y la reposición de tarjetas de transporte.
Los servicios de banca en línea Faktura.ru son utilizados por más de 130 bancos. Los sistemas bancarios automatizados CFT son utilizados por organizaciones aún más diferentes.
El CFT emplea grandes divisiones de I + D, ML e IA, que están integradas en casi todas las áreas de la empresa. Contamos con un poderoso equipo de seguridad de la información. En general, se trata de más de 3.000 personas que han estado ocupadas resolviendo tareas de fintech durante los últimos 26 años.
Uno de los productos CFT "jóvenes" se basa en el servicio "Golden Crown - Money Transfers" (que ya tiene 16 años): es "Money Transfers Online", una dirección que lanzamos en 2016. Y hoy es una locomotora de desarrollo móvil en CFT: en total, 70 personas trabajan en iOS y Android. Y este número continúa creciendo, planeamos crecer a cientos para fin de año.
También hay direcciones móviles en las divisiones de "Tarjetas prepagas" (están desarrollando soluciones para las tarjetas "Maíz", "Beeline", "Kari", etc.), en Faktura.ru, la "Ciudad" del sistema.
Y Misha y yo solo estamos en la división de "Transferencias de dinero en línea" comprometidas con el desarrollo del equipo, la expansión y la introducción a los procesos de desarrollo. Inicialmente, trabajamos en la Dirección de "Tarjetas prepagas", los equipos eran pequeños, plataforma, y vivimos en los conceptos que estaban en 2014-2015.
Mikhail : Cuando todos están sentados en la misma oficina, trabajan, se comunican.
Kirill : Estos pequeños equipos cálidos y de lámparas, para 10-15 personas, teniendo en cuenta todo, tanto las pruebas como el backend. Y ahora tenemos nuevos desafíos.
Michael : Sí, organizar el trabajo de 10 desarrolladores es una cosa, y 50 es otra. Esto incluye todos los procesos para el desarrollo, la ampliación del equipo, su desarrollo profesional y el proyecto en sí: si nuestros ingenieros resuelven problemas técnicos, estamos involucrados en el desarrollo de la arquitectura del proyecto. Estamos buscando problemas que interfieran con la escala de este proyecto, y tratamos de resolverlos en todos los sentidos.
Grupo JUG.ru: Volveremos a los problemas del crecimiento, pero por ahora dígame esto: ¿en qué se diferencia el desarrollo móvil en CFT de otras compañías y qué es similar? ¿Qué necesita saber al respecto para aquellos que nunca han trabajado en fintech? ¿Necesita algún conocimiento especial en la etapa de entrevista ya?Kirill : Cuando hablamos con candidatos que provienen del outsourcing, tienen el deseo de trabajar en un equipo de producto, un deseo de estabilidad. Pero siempre tienen inquietudes: la tecnología financiera es una especie de pantano, estrictamente regulado y rodeado de seguridad, en el que será incómodo participar en el autodesarrollo desde el punto de vista del desarrollador.
Siempre decimos que en nuestro caso el desarrollo móvil es exactamente el mismo que el de cualquier desarrollo de productos del mercado. Fintech no es una palabra para describir la forma de vida, sino simplemente una línea de trabajo, algo que enfrentamos todos los días.
Estos son los mismos clientes de banca móvil, varios pagos, servicios de pago sin contacto, etc. Pero esto no significa que necesite habilidades o conocimientos especiales: cualquier desarrollador móvil genial puede comenzar a hacer fintech si está interesado.
Por supuesto, necesitamos un conocimiento mínimo en el nivel primario: cómo se ve una tarjeta bancaria, qué es una cuenta bancaria. Pero si hay un conocimiento más profundo, esto hace que sea más fácil y rápido entender los deseos de los analistas. Hay desarrolladores que quieren entender no solo "cómo hacer la tarea", sino también "por qué".
También existe su propia especificidad, por ejemplo, los requisitos del regulador representado por el Banco Central. Pero, como regla, todo esto se tiene en cuenta en los requisitos comerciales y es suficiente para leerlos, hacer las preguntas necesarias y todo estará claro.
Hay ciertos puntos desde el punto de vista de la seguridad de la información, esto es comprensible: fintech se trata de seguridad. Pero no puedo decir que los desarrolladores móviles sean la primera línea de defensa. Aún así, los productos fintech están diseñados de tal manera que sean seguros en el lado del backend y el almacenamiento de datos.
Sí, sucede que un desarrollador proviene de una startup y comienza a decir que la API podría diseñarse mejor: dicen, aquí puede hacer una solicitud, y nosotros hacemos tres. Pero esto se debe al hecho de que la API está diseñada de tal manera que no proporciona la totalidad de la información. Y cuando el desarrollador comprende que esta es una decisión de ingeniería, y no un movimiento estúpido por parte de los desarrolladores, él acepta de inmediato.
Y desde el punto de vista de la seguridad de las aplicaciones móviles, tuvimos un informe sobre el pasado Mobius. No descubrimos América allí y no mostramos trucos de piratería, pero mostramos una lista de verificación que un desarrollador de aplicaciones fintech debe seguir para no cometer errores tontos:
No los comprometemos, porque hay una revisión de código y recomendaciones del equipo de seguridad que nos hizo una excelente lista de verificación. Establece dónde se debe resolver la vulnerabilidad y por quién (del lado de la inteligencia empresarial, desarrollador de backend, desarrollador móvil o probador) ) Conocemos todas estas áreas de responsabilidad, solo seguimos las reglas.
Es importante comprender que no solo estamos aserrando latas aburridas, sino que estamos tratando de dirigir nuestras caras a los clientes, incluido el aspecto tecnológico. Por lo tanto, siempre estamos a favor de innovaciones como pagos sin contacto.
Nuestros "bancos" de iOS en 2018 ocuparon el 4 ° y 5 ° lugar en
el ranking Markswebb en la categoría de banca diaria.
Estamos tratando de ser una aplicación que "no se avergüence de mostrarle a mamá", que puede ser utilizada por personas que no sean teléfonos inteligentes y aquellos que entienden mucho sobre tecnología. ¿Por qué algunos bancos móviles tienen éxito y otros no? Porque están hechos tecnológicamente, con animación, tal vez incluso con algún tipo de referencias culturales.
Michael : Agregaré brevemente que estamos realmente enfocados en los clientes, personas vivas que caminan por las calles. Como llevamos a cabo operaciones con dinero, nos esforzamos por hacer que sean lo más utilizables posible y más fáciles para las personas.
Al mismo tiempo, cuando los empleados se acercan a nosotros, necesitan comprender qué hacer realmente "por las personas" es no garabatear "como veo" de rodillas. Antes de trabajar en CFT, hice casi todo el diseño y UX sin un diseñador. Pero la empresa no nos funciona así. Hay un laboratorio UX completo con diseñadores que realizan experimentos, y hay grupos focales que prueban hipótesis.
Y cuando una persona se acerca a nosotros, debe comprender que todo se centrará en facilitar que el cliente utilice el producto, para no morir al completar un formulario de 50 campos. El trabajo se centra en las necesidades del usuario final.
El segundo es los requisitos de calidad del código. Tenemos requisitos realmente altos de calidad, revisión, arquitectura limpia, aplicación de principios SÓLIDOS en todas las capas. Es inaceptable que sacrifiquemos la calidad por el bien del tiempo.
Y esto es adyacente a la tecnología moderna, no hay retraso detrás de la industria. Todos los productos de Android ahora están escritos en Kotlin e iOS en Swift. En Android usamos Rx, Dagger, en algunos proyectos de corutinas. Cuando llegan nuevos desarrolladores, solicitamos regularmente comentarios para comprender qué le gusta y qué no le gusta a la gente. Y no recuerdo que los empleados se quejaron de que algo estaba desactualizado y se ofrecieron a cambiar algo. Solo tenemos tiempo para lanzar ideas, "intentemos MVI en tal o cual módulo", y todos comienzan a generar.
Cuando una persona viene a nuestro equipo, debe estar listo para comprender la pila de tecnología moderna y poder navegarla. Damos la bienvenida a esto. Esto, quizás, es incluso una paradoja: una persona va a fintech, al desarrollo bancario, esperando el conservadurismo, y se le exige que sepa cómo Rx y Kotlin trabajan con todos los beneficios. Esto, me parece, es una característica única.
Crecimiento del equipo móvil
Grupo JUG.ru: Usted ya dijo que está resolviendo problemas que surgen con el crecimiento del equipo. ¿Hay un ejemplo concreto?Michael : por ejemplo. Cuando seis personas en un equipo realizan una revisión de solicitud de extracción, 3-4 personas en una solicitud de extracción, pasan con la suficiente rapidez (especialmente si las personas están en la misma oficina). La situación cambia dramáticamente cuando los empleados trabajan en diferentes ciudades y zonas horarias, y el equipo crece y aparecen celdas separadas dentro de él (equipos de desarrollo unidos por un líder de equipo).
Notamos que con un aumento orgánico en el número de revisores, las solicitudes de extracción comenzaron a demorarse hasta 5-6 días. Esto fue un problema: no pudimos entregar características a la empresa a tiempo.
También hubo un problema con el flujo de git: si te sientas en una rama y viste durante mucho tiempo, en ese momento el otro equipo también puede ver 2-4 características en otras ramas, y luego todo esto se congela en las ramas por las fechas de lanzamiento, nos da dolor en forma de un conflicto de fusión.
El segundo problema se resolvió cambiando el flujo de git. Comenzaron a aplicar el enfoque de desarrollo basado en troncales, es decir, vertiendo directamente en la rama de desarrollo, ramas de características abandonadas. Pero dado que verter la funcionalidad inoperativa es imposible, esto interrumpirá el proyecto, luego aplicamos el enfoque de alternancia de funciones. Y, por lo tanto, redujo el plazo para emitir funcionalidad a la rama de lanzamiento en varios días. Hablé más sobre esto en Twitter
@mobileunderhood .
Hubo un problema con la revisión. Anteriormente, unas 4-5 personas participaron en nosotros, ya que la calidad del código es importante para nosotros, tenemos principios y enfoques de calidad bastante estrictos. Teníamos miedo de que si reducimos el número de revisores, nuestra calidad se deteriorará. En este caso, para 50 desarrolladores, por ejemplo, 30 realizan revisiones de calidad, y el resto son desarrolladores junior o intermedios que aún no han desarrollado una habilidad real.
Por lo tanto, tomamos un camino diferente y se nos ocurrió la fórmula "1 líder + 1 desarrollador senior + 1 cualquier desarrollador". Al principio, utilizamos esta fórmula en el marco de los equipos: por ejemplo, el desarrollador del equipo "A" emite una solicitud de extracción, realiza una revisión con el curador y algún desarrollador individual. Alrededor de 20 solicitudes de extracción aparecen en un día y medio: si en la mañana realizamos una revisión de todos, a mediados del día siguiente habrá alrededor de 20 nuevas.
Pero nos encontramos con otro problema. Si un desarrollador pone constantemente su ventaja y una ventaja vecina de otro equipo, entonces las oportunidades se sobrecargan. Están menos involucrados en el desarrollo y dedican más tiempo a la revisión. Cerca de 20 solicitudes de extracción son un trabajo serio si lo aborda cualitativamente.
Y fuimos aún más lejos. Dejaron tres espacios para los revisores, dejaron los mismos roles (equipo técnico, desarrollador senior y cualquier otro), pero no se molestaron en que deberían ser personas de su equipo. Y ahora tenemos solicitudes de extracción que tienen lugar en un día, un máximo de uno y medio. No más largas historias.
Y todo esto en combinación con la alternancia de funciones: cuando un desarrollador adquiere una función, primero hace una marca de desactivación en el código para que se inicie en frío. Y luego comienza el desarrollo. Todo esto se verifica en un día, sin importar en qué ciudad se encuentre el equipo.
Una historia separada con zonas horarias. Si hacemos una solicitud de extracción en San Petersburgo, donamos por la noche, luego en Novosibirsk +4 horas, y mientras tenemos otra noche, ya ven las solicitudes de extracción por la mañana. Dejan el trabajo, recibimos sus solicitudes de extracción y observamos. Resulta un flujo continuo constante en el que las zonas horarias trabajan en la mano.
Kirill : Sí, volviendo a la pregunta sobre la empresa: además del hecho de que tenemos más de 3.000 empleados, nuestros centros de desarrollo están ubicados en tres ciudades (Tomsk, Novosibirsk y San Petersburgo), y los equipos móviles se distribuyen entre ellos. Es un poco complicado que haya un retraso de cuatro horas, pero la jornada laboral total de la empresa se extiende a 12 horas.
Michael : Las zonas horarias ayudan más que solo una revisión. Hemos formado un solo desarrollo de Android, no existe tal cosa que en diferentes ciudades todo esté separado. Nuestros equipos son multifuncionales, pero unidos por las características de la plataforma, como comunidades. Existen estándares, principios generales y prácticas aceptadas, incluido el estilo de código y similares. Y, por lo tanto, si surgen problemas repentinos que requieren una solución urgente u otra acción urgente, puedo enfrentar a aquellos que ahora tienen horas de trabajo, incluso si no fueron originalmente responsables de este código. Las personas en otras ciudades pueden ayudar mientras dormimos, y viceversa.
Grupo JUG.ru: cuando un equipo crece, ningún desarrollador puede conocer toda la base del código o es fácil aclarar algo de una persona sentada cerca. En este caso, probablemente, surge otro desafío: ¿mantenimiento de registros?Kirill: Aquí vale la pena decir esto: cuando planificamos el crecimiento del equipo 10 veces, nos dimos cuenta de que no lanzaremos 10 veces más funciones (o incluso 7 veces). Con tal crecimiento, solo para mantener el nivel anterior de calidad, se requieren esfuerzos adicionales. Y uno de los ejercicios para los nuevos desarrolladores fue simplemente escribir la documentación antes de comenzar a hacer algo.
Por lo tanto, en poco tiempo cubrimos los componentes clave de la aplicación en la documentación. Y comenzaron a dejar que Jones ingresara en dichos componentes, porque con dicha documentación ya es posible permitirse revisiones y pruebas de código. Fue un zoom de "escape retrasado".
Ahora que ha pasado un año, hemos preparado la base y ahora llevamos a los desarrolladores que llegaron hace un año al nivel completo de productividad. Cuanto más avanzamos, más fácil se vuelve. Con base en la documentación creada, creamos listas de verificación con la estructura y la interacción de los componentes, con nuestra integración con los servicios principales, y ahora todo esto no causa pánico: "Vine aquí para programar, y usted tiene una empresa aquí".
Michael : Complementaré a Cyril. Después de que el equipo tenía más de 30 empleados, hubo un período en el que los líderes del equipo y los desarrolladores senior dedicaron mucho tiempo a uno o dos desarrolladores supervisados, porque transmitían información constantemente. Entendimos esto de antemano y comenzamos a actuar. Por lo tanto, Android asignó un espacio separado en Confluence y allí reunió todos los principios, prácticas y convenciones para el desarrollo no solo en este proyecto, sino también en otros.
Cuando un empleado llega a un equipo, primero se sienta y estudia cómo llevamos a cabo el desarrollo, cuáles son las reglas y prácticas, y qué arquitectura del proyecto. Ni siquiera toma el código mientras estudia. Luego responde las preguntas de control. Cualquier entrenamiento sin preguntas de seguridad no es lo suficientemente efectivo.
Ahora hemos ido aún más lejos y estamos creando el sistema de entrenamiento automatizado Galileo. Su esencia está en varios niveles de gradación de la educación, desde los principios del desarrollo y las metodologías, desde los principios arquitectónicos hasta los principios de las lenguas Kotlin.
Después de tal inmersión, la mitad de las preguntas son barridas. Lo que el líder hizo antes ahora está automatizado. Cuando el desarrollador va directamente a la producción, en una o dos semanas, hace preguntas puntuales, lo cual no es un problema. Y antes de eso realmente había un problema.
Creo que incluso si el proyecto es para 10 personas, aún debe presentar documentación por adelantado. No te topes con este asunto, pero establece algunos principios. Habrá una escala, no lo hará, y en cualquier caso, cuando llegue un nuevo desarrollador, la documentación eliminará un montón de preguntas y ahorrará mucho tiempo de curador.
Tenemos documentación de la plataforma (para Android e iOS), y hay proyectos (escenarios empresariales y similares).
Kirill : Cambiamos a un poco de crowdsourcing. Cuando llega un recién llegado, le dicen: "Mira, esto es lo que debes leer el primer día, aquí el segundo". Allí, configurando, proporcionando diversos accesos, herramientas, etc. Y si una persona se enfrenta a un problema, una de sus tareas es escribir el problema en la misma lista de verificación para el próximo recién llegado. Tales cosas persiguen objetivos diferentes a la vez: también preparamos documentación para las próximas generaciones y le enseñamos al principiante el valor de documentar lo que hace. Y no tiene miedo de qué escribir.
Particularmente celoso inmediatamente comienza a dibujar diagramas UML, lo que se recomienda. Una vez que alguien da un buen ejemplo, todos se involucran. Y no estamos golpeando a nadie, ya que entendemos que se necesita tiempo, y damos este tiempo.
Bibliotecas de terceros contra el desarrollo interno.
Grupo JUG.ru: Me gustaría hablar un poco más sobre la "cocina interior" en el contexto de iOS y Android. Por lo que entendemos, usted tiene en iOS una política de rechazo de soluciones de terceros, pero Android inicialmente también trató de escribir todo por sí mismo, pero luego lo dejó. Por quéMichael : Android ha sido históricamente de esta manera. En 2013, cuando estábamos creando un banco móvil para la tarjeta Kukruza, casi no había estándares para arquitecturas y bibliotecas en el desarrollo de Android. Incluso Google mismo no entendió dónde debería desarrollar Android. Comenzamos el desarrollo cuando todavía no había Android 5, teníamos KitKat 4.4 como la versión máxima.
Como no hay bibliotecas, nos escribimos nosotros mismos. , , . : , 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
Grupo JUG.ru: Michael en @mobileunderhood escribió "estamos dejando Java por completo, estamos reescribiendo todo en Kotlin". Por lo general, incluso cuando el nuevo código ya está escrito en Kotlin, el existente en Java cambia muy lentamente y puede permanecer en producción por muchos años más. ¿Por qué decidiste hacerlo más activamente? ¿Y te deshaces del código Objective-C tan activamente en iOS?Michael : Siempre me ha gustado Java. Siempre la amé, incluso pasé el certificado de Oracle, y ella estuvo bien conmigo. Pero el desarrollo de Java en Android y el desarrollo de Java en la empresa son dos cosas diferentes. Y hace unos años, cuando Kotlin recién comenzaba, el uso de Java en su forma simple sin bibliotecas comenzó a cansarse. Construcciones largas, un poco de azúcar sintáctica, aquí algunos colegas con C # también arrojaron lo que tienen, pero en general no lo desmotivamos. Quería escribir código que ejecute la lógica, y pasar menos tiempo escribiendo este código en sí mismo, usar más cosas, es más fácil de entender y leer el código.
Luego vinieron cosas como Lombok. Al principio me gustó, y luego se detuvo, porque es una especie de biblioteca adicional que le permite simplificar el código, envolverlo en azúcar sintáctico, pero esto es solo un complemento, no el compilador de Java en sí. Y la clase de datos Kotlin y la clase Java normal con todos los métodos de encapsulación de propiedad y obtención / configuración son cosas completamente diferentes.
Y decidimos por mucho tiempo por primera vez probar Kotlin al nivel de un proyecto. Lo escribimos, algunas cosas nos confundieron, bueno, Kotlin y Kotlin, lo intentamos, está bien, hay un proyecto, volvemos a Java. Regresaron, y después de un tiempo me di cuenta de que ya no podía desarrollarme en Java. Eso es todo, estoy cansado de ella, ya no puedo verla.
Aparentemente, me acostumbré a algunas cosas sintácticas, al minimalismo del código. Y al final, se decidió que necesitamos usar Kotlin. Se percibe y lee mejor. Algunos desarrolladores estaban en contra, pero me parece que esto es una cuestión de costumbre. Práctica introducida: escribe nuevos proyectos en Kotlin. Y los viejos proyectos permanecieron en Java. Pero cuando tuvo lugar una refactorización importante, copiamos todo a Kotlin. Hemos ganado experiencia para hacer esto rápidamente. Esto no significa que hayamos convertido los archivos Java a Kotlin con teclas de acceso rápido, y luego arreglemos este código; nosotros mismos lo reescribimos inmediatamente en el estilo Kotlin.
Literalmente quedan dos proyectos de Java, y la transición también continúa gradualmente: los nuevos módulos se escriben en Kotlin, las nuevas pruebas en Kotlin y la lógica anterior en Java. Si la lógica cambia debido a la refactorización, escribimos en Kotlin. Y uno de estos proyectos está siendo refactorizado en este momento. Por lo tanto, pusimos la migración en la secuencia y, después de dos años con Java, quedaban literalmente proyectos y medio.
Nadie se opuso particularmente. Hubo cierto escepticismo: "Kotlin es solo una exageración", por supuesto, pero realmente nos ayudó cuando Google reconoció oficialmente a Kotlin para el desarrollo de Android, para nosotros fue solo una bomba. Ya no era necesario convencer a los ingenieros: o estás en la onda de todos los desarrolladores modernos o estás fuera de este mercado.
Kirill : Y con Swift, la primera reunión fue así: necesitaba hacer una pequeña presentación para una de nuestras conferencias en Novosibirsk, y cuando llevé un código a la pantalla en Objective-C, quedó claro que no podía leerse en ningún tamaño de pantalla. Y luego escribí ese código para la presentación en Swift, aunque no había una sola línea "rápida" en el proyecto.
Luego probamos Swift en el proyecto Golden Crown Transport Card, que escribimos desde cero. Corrimos algunos momentos de lenguaje allí. Fue interesante lo que estábamos haciendo mal, un poco comenzó a trabajar para crear nuestra propia guía de estilo. Desde el segundo Swift también "nos mudamos" al tercero, tomamos un sorbo de dolor, que luego atormentó a todos.
Y si nos fijamos en las solicitudes de extracción que tenemos ahora, el 95% del código Swift está escrito allí. No tenemos una súper tarea para transferir todo el código disponible de Objective-C a Swift a cualquier costo. Sin embargo, la parte del código Swift en la aplicación móvil de Money Transfer es del 60-65%, emitimos un "resumen rápido" en el que dibujamos un gráfico para los archivos Swift / Objective-C, para las líneas de código, y dependiendo de la fecha de lanzamiento y Todo es visible. Una participación del 65% no significa que copiamos 6 de cada 10 archivos, principalmente el crecimiento debido a los nuevos archivos.
Probamos diferentes técnicas de transición, por ejemplo, en el banco móvil para la tarjeta Corn, realizamos una transición unidireccional (es decir, nuestro código Swift se basa en Objective-C, pero no transferimos las construcciones Swift a Objective-C). No estamos arrastrando la funcionalidad Swift para acelerar el proceso de cambio a Swift de esta manera. En este caso, cuando realmente se vuelve rápido y el código Objective-C requiere todas las dependencias de Swift, podemos decir que es hora de que el componente cambie completamente a Swift.
Dado que los productos para el servicio Golden Crown - Money Transfer son más importantes que la velocidad de desarrollo que simplemente aumentar la participación de Swift, tenemos historias bidireccionales. Pueden parecer menos hermosos desde el punto de vista de los seguidores de Swift, pero dado que este enfoque le da al producto la capacidad de moverse más rápido.
Los desarrolladores llegaron sin ningún conocimiento de Swift, el idioma fue dominado en dos semanas, comenzó a funcionar. A veces temen que tengamos un 60% de Swift, pero está bien, todavía no ha habido un caso en el que un empleado no haya podido dominarlo. Hay historias opuestas: cuando descubren que tenemos un 40% de Objective-C, comienzan a decir que estamos retrógrados, y primero debes reescribir todo en Swift y luego cortar las características. Pero aquí todo es individual, y trabajamos con cada uno individualmente.
Hay proyectos mixtos, proyectos mixtos unidireccionales, hay proyectos limpios en Swift, probamos todo. Todo funciona bastante bien, no hay bala de plata.
Grupo JUG.ru: Sobre Swift y Kotlin dicen "porque son similares, se ha vuelto conveniente para los desarrolladores de Android e iOS buscar el código del otro". ¿Tiene desarrolladores para diferentes plataformas que buscan el código del otro o no?Kirill : Recuerdo historias cuando los desarrolladores de Android que escribieron en Java analizaron el código de los desarrolladores de iOS en Objective-C y viceversa, cuando escribimos uno de los componentes más complejos de la aplicación móvil para el mapa de Corn: el famoso diseñador de formularios, Un ejemplo de arquitectura de interfaz de usuario impulsada por backend. Existe una interacción muy intensa con el backend a través de cierto protocolo, y no hacerlo de la misma manera era simplemente criminal. Por supuesto, nos asomamos.
Y ahora tenemos diferentes enfoques arquitectónicos en las aplicaciones, las aplicaciones se basan en diferentes arquitecturas de interfaz de usuario. El máximo en el que podemos espiar es la capa empresarial, e incluso entonces deberíamos excavar en la dirección de las herramientas de prueba que le permiten escribir en uno de los lenguajes de programación.
Las aplicaciones, de hecho, son un cliente para el servicio. En su mayor parte, responde a la entrada del usuario y muestra datos del servidor. Un lugar para escribir algo completamente incorrecto es bastante difícil. Y en este sentido, tal vez, hay algunos ejemplos.
Michael : tengo ejemplos. Dado que ahora tenemos equipos multifuncionales, los desarrolladores de iOS y Android hacen casi la misma funcionalidad comercial en diferentes plataformas, se miran cada vez menos el código del otro, porque no hay nada que ver y todo el desarrollo transcurre sin problemas.
Pero cuando alguien sigue adelante, al mismo tiempo, la persona se da cuenta de que algunos de los chips están implementados, cuando la empresa insinúa "mira cómo se hace Android", y la analítica aún no está lista, hay momentos en que los desarrolladores de ambos lados puede pasar y ver cómo se hace. Y aquí realmente ayuda que Swift y Kotlin sean muy similares.
En mobileunderhood, compartí mi experiencia que tuve cuando trabajé en un proyecto en el que no teníamos un equipo multifuncional, sino una especie de startup para pagar los préstamos. Y me gustó mirar el desarrollo de iOS, fue interesante cómo resuelven ciertos problemas, tal vez incluso arrojarles algo. Y les encantaba tirarme. Y constantemente, durante horas, podíamos estar en la pizarra y hablar sobre cómo se ve el polimorfismo puro en iOS y Android, cómo cocinarlo.
Se trata de discutir qué es la abstracción, para algún tipo de conceptos formales, y todo sucede bastante divertido, y comienza con el código habitual. Miras y piensas: ¿por qué hiciste esto? ¿Hay muchos gastos generales? Y me explican que todo está planeado y conscientemente lo hacen, para no pasar 2-3 días buscando la mejor solución, si, por ejemplo, este código cambia a través del sprint. Pienso: muchachos inteligentes, tenemos que hacer esto a veces, y no pensar durante cinco días en algún tipo de arquitectura interna, sobre lo cual luego resulta que no es necesario.
Como resultado, a menudo aparecía y miraba el código Swift. También miré en Objective-C, pero me gusta más Swift. Aunque no lo desarrollé, no creo que haya dificultades para escribir código. Los desarrolladores de Android tienen lo mismo.
Kirill : En general, no solo tenemos un equipo de plataforma, dentro del cual les decimos: "Ustedes son los mejores porque Apple les dio esa herramienta". Los chicos de iOS y Android interactúan, participan en la planificación juntos y trabajan en problemas con analistas de sistemas.
Y también actúan juntos en relación con los desarrolladores de back-end si intentan encontrar una API no tan adecuada. Y en esta simbiosis, pueden espiar todo en el repositorio, tenemos un sistema abierto y todos los desarrolladores tienen acceso al repositorio.
En la dirección de "Tarjetas prepagas", teníamos historias sobre el diseño de los backends, y luego los desarrolladores de Android configuraron el entorno, el entorno y filmaron un par de correcciones de errores, solo para ayudar.
Michael : recordé un caso muy reciente. Allí, para que el cliente sea más sutil para nosotros, el backend necesitaba hacer más trabajo, luego nuestros trucos móviles se unieron y comenzaron a impulsar su idea general. Todos se reunieron, discutieron cómo se sentirían cómodos en ambas plataformas, fueron a los desarrolladores de backend y anunciaron cómo se sienten más cómodos trabajando y qué viola el concepto de cliente ligero. Los patrocinadores estuvieron de acuerdo con ellos.
Ahora, si una plataforma dice: "Haremos todo", y la segunda se negó, diciendo que es difícil, entonces obligarían a la segunda a aceptar y hacer algo. Y así sucedió todo junto. Por lo tanto, la sinergia, el desarrollo del equipo está funcionando. Y los idiomas realmente ayudan en esto. Después de todo, si Java y Objective-C son hemisferios completamente diferentes en términos de sintaxis y principio, entonces Kotlin y Swift están realmente mucho más cerca.
Cyril : Por cierto, hay ejemplos de cuando los chicos se convirtieron en conmutadores, e incluso en conmutadores dobles, cambiando entre plataformas. Hubo uno que se cambió a iOS, se familiarizó, "lo puso en sus manos" y volvió a Android. Y luego se fue en absoluto en DevOps. En este sentido, también estamos abiertos, esos momentos se simplifican.
Es genial que los chicos quieran desarrollo profesional, incluso en diferentes planos. Les damos oportunidades, y ellos mismos eligen de qué manera quieren desarrollarse, y casi todos nuestros muchachos están motivados por el producto, por las tareas en las que trabajan, lo cual es muy bueno.
Grupo JUG.ru: Última pregunta: ¿qué pasa con el desarrollo multiplataforma?Kirill : Nuestra compañía tiene un producto en desarrollo para el sistema Federal City. Ahí es donde se elige React Native para la implementación. Y no sentimos celos por esto, porque siempre es interesante realizar un experimento y descubrir cómo terminará. Además, tenemos desarrolladores front-end que conocen bien su negocio, y es interesante probar algo nuevo e ingresar a nuevas plataformas.
Michael : Tenemos proyectos en React Native, pero esto es un poco incorrecto, ya que lo hacen los desarrolladores front-end, y los desarrolladores de iOS y Android no se superponen demasiado.
En cuanto a la multiplataforma, personalmente lo veo para equipos pequeños: cuando hay pocos recursos en iOS y Android, y el proyecto debe hacerse para ambas plataformas, ¿por qué no? Tenemos suficientes recursos, y los productos son tecnológicamente sofisticados, podemos permitirnos un desarrollo separado para iOS y Android.
También sucedió históricamente que cuando realizamos la mayoría de nuestros proyectos, todavía no había una plataforma cruzada. Ahora, naturalmente, pensaríamos en separar una parte de la lógica empresarial y la lógica abstracta en módulos generales, porque a nadie le gusta hacer un solo trabajo. Pero históricamente, no tenemos esto.
Sin embargo, esto no significa que siempre será así. Tenemos muchas tareas y proyectos prometedores de las empresas, hay prototipos y, tarde o temprano, probaremos Kotlin Multiplatform de JetBrains o Flutter, lo cual es más interesante para nosotros.
La plataforma cruzada aún no se ha estandarizado en una forma industrial, en la que puede tomarla y usarla en una empresa. A juzgar por la comunicación con los desarrolladores multiplataforma y sus informes, ahora hay una constante "rake run" y resolución de problemas. Por lo tanto, puede tomar y presentar un proyecto, pero más a menudo será solo una lucha contra un rastrillo, y no creo que las características comerciales se puedan cortar de manera eficiente. Recientemente, se le preguntó a JetBrains en el informe si es posible utilizar la versión multiplataforma de Kotlin en la producción, y dicen que todavía está en forma experimental.
En el otro extremo hay un Flutter, que despegó en el último año, esto es realmente interesante, Google no está débilmente invertido en este negocio. Y sé que muchos hacen proyectos de mascotas en Flutter, que ya se encuentran en las tiendas de aplicaciones. Y esto es más interesante para nosotros. Nos hartamos un poco de Kotlin, con Kotlin / Native tenemos que recolectar muchos rastrillos, pero Flutter with Dart es algo completamente nuevo.
Nos encanta todo lo nuevo, por lo que definitivamente tendremos un desarrollo multiplataforma. No específicamente en la aplicación de Transferencia de dinero, pero lo será en algunas pequeñas aplicaciones separadas.
Grupo JUG.ru: ¡Gracias por las respuestas detalladas!