¿Cuántas aplicaciones rusas en Google Play dicen "50,000,000+ instalaciones"? Obviamente, cada caso es una historia única con sus propios detalles, por lo que sería interesante hablar con los desarrolladores. Y cuando dicha aplicación también tiene una calificación de 4.6, esto fortalece el interés.
Vladimir Tebloev es una de las personas que trabajan en la aplicación de Android
Sberbank Online . En la primavera, cuando Sberbank Technologies participó en nuestra conferencia
Mobius , hizo un informe allí, y ahora decidimos preguntarle a Vladimir sobre las características de su trabajo.
- Primero, dinos qué estás haciendo exactamente.- En la aplicación Sberbank Online, participo en el servicio de Diálogos, que permite a los usuarios transferir dinero con un solo clic y ver todo el historial de transferencias a la vista. El servicio está disponible para todos los usuarios de la aplicación; ahora son 37 millones de personas.
He estado trabajando en SberTech desde el verano de 2016; luego, como parte de la aplicación, todavía no había división en equipos separados. Y más tarde, cuando, como parte de la transición a ágil, comenzaron a asignar diferentes equipos para separar los módulos de aplicación, uno de los primeros fue el equipo de Diálogos, y desde entonces he estado en él.
- Todos tienen las palabras "Sberbank" y "desarrollo móvil" asociadas con Sberbank Online. Pero en una empresa tan grande, ¿hay probablemente también un desarrollo móvil interno? ¿Es diferente del exterior?- Sí, también hay aplicaciones para uso interno. No tengo nada que ver con ellos, pero sé que React Native se usa activamente allí. El desarrollo interno tiene sus propios requisitos: no existe una revisión de diseño estricta y una animación sofisticada; el desarrollo es más rápido utilizando una solución multiplataforma.
Cuando la experiencia crezca, será posible aplicarla en una aplicación de "combate". Aunque el hecho de que Sberbank Online pueda utilizar activamente el desarrollo multiplataforma, lo dudo. Hay muchas dificultades, y cuando tienes decenas de millones de usuarios, incluso un problema raro puede dañar a tantas personas.
- ¿Y cómo afecta este trabajo "incluso un problema poco común a muchos"? ¿Tiene que lidiar con algunos problemas exóticos que las aplicaciones más pequeñas pueden pasar desapercibidas?- A veces hay problemas en algunos dispositivos "especiales". En un firmware personalizado, pero extendido, disparó duro, y tuvimos que resolverlo durante mucho tiempo. Resultó que el problema estaba en el controlador de la placa base del dispositivo en sí: intentó emular bibliotecas en ARMv5, aunque el proyecto era solo para ARMv7.
Cuando hay muchos usuarios y el precio del error es alto, esto lleva al hecho de que todo debe implementarse "un poco", siguiendo cuidadosamente los informes. Si algo surge allí, dejamos de rodar de inmediato y hacemos una revisión. Además de rodar "por un porcentaje dado de usuarios", también implementamos geográficamente todo en partes: Sberbank tiene el concepto de un "banco territorial", y las características pueden desplegarse gradualmente por región.
- Si bien algunas startups hipster pueden poner una alta MinSdkVersion y decir "todos los demás no son nuestra audiencia", usted tiene una situación diferente, no puede saludar a las personas. ¿Cuál es su valor actual de MinSdkVersion?- Ahora es 16, y lo levantamos literalmente el año pasado de 14. Observamos la cantidad de clientes con un SDK específico, y podemos aumentar la versión si llega a ser inferior al 5%. Hasta el momento, tenemos muchos usuarios en Android 4.4 KitKat, alrededor del 16%, necesitamos apoyarlos.
- ¿Hay alguna de las nuevas versiones que está viendo en este momento y piensa: "Tan pronto como aumentamos MinSdkVersion, la usamos de inmediato?"- Por supuesto, me gustaría elevar nuestra API mínima a Android 5.0 para hacer un uso completo de innovaciones como, por ejemplo, la animación de transición, que funcionará adecuadamente y en todas partes. Pero, en principio, esto no se aplica a la funcionalidad de escritura, la lógica empresarial, por lo que esto no es crítico. En general, las animaciones son elaboradas por nuestros diseñadores, es decir, pueden implementarse manualmente. Por lo tanto, este problema no es crítico, se relaciona con la comodidad, "tranquilidad" del desarrollador.
Hay algunos casos en los que verificamos la versión, por ejemplo, anclaje SSL. Funciona de manera diferente en diferentes versiones de Android, por lo que implementamos dos versiones del código, para dispositivos Android "hasta 4.4" y "desde 4.4".
Por supuesto, me gustaría "simplemente desarrollar para Android P y no pensar en nada", pero este es siempre el caso, no se llega a ninguna parte.
- Al mencionado anclaje SSL. Obviamente, los problemas de seguridad son muy importantes para el banco. ¿Y cómo le afecta esto, en qué se diferencia su trabajo de trabajar en una aplicación no bancaria?- Presenta un enfoque muy estricto de los datos personales del usuario. Cualquier fuga es un gran riesgo. Tenemos un departamento de seguridad que prueba nuestra aplicación antes de cada lanzamiento. Si hay comentarios, el trabajo sobre ellos pasa al equipo responsable de la funcionalidad con la vulnerabilidad descubierta.
Creo que en las pequeñas empresas a menudo no hay un departamento de seguridad que se encargue de la aplicación. Si se encuentran cardúmenes, pueden aparecer en w3bsit3-dns.com o en un recurso similar.
También relacionado con la seguridad es que nuestra aplicación utiliza un antivirus. Algunos usuarios no están contentos con su presencia, pero la introducción del antivirus nos ha dado una reducción muy notable en el fraude. Por ejemplo, en nuestro banco de SMS, donde puede escribir SMS "cantidad de transferencia a tarjeta X", con antivirus, el nivel de fraude en esta dirección se redujo al mínimo.
- Por razones de seguridad, los bancos limitan su funcionalidad en el caso de los teléfonos inteligentes rooteados. ¿Qué está prohibido para Sberbank Online para dispositivos rooteados?- En junio, abandonamos la funcionalidad limitada para los propietarios de dispositivos con derechos de root. Ahora todos los usuarios de Sberbank Online en Android tienen una funcionalidad completa. Al mismo tiempo, la protección se mantiene al mismo nivel gracias al sistema de monitoreo de fraude.
- Y en nombre de la seguridad, ¿era necesario restringir en algo no a los usuarios, sino a ellos mismos como desarrolladores, negándose a usarlo de otra manera?- Cuando en 2015 queríamos presentar Retrofit, tuvo problemas con la ofuscación, trabajó torcidamente con un ofuscador estándar. Nuestro departamento de seguridad señaló esta vulnerabilidad, cargada de un ciberataque al banco y los riesgos de romper el código, ya que la API sobresale. Luego abandonamos Retrofit y todavía no lo usamos. Hasta donde sé, ahora los problemas con el ofuscador estándar ya están solucionados allí. Pero desde entonces hemos escrito nuestro propio cliente HTTP, funciona y satisface a todos, ya se han escrito muchos contenedores para diferentes equipos que trabajan con diferentes servidores. No tiene sentido cambiarlo a Retrofit.
- La pregunta inevitable: ¿qué tienes con Kotlin?- Vamos en su dirección, pero sin prisa. La dificultad es que muchos desarrolladores de Android de diferentes niveles están trabajando en la aplicación de inmediato, alguien conoce a Kotlin perfectamente, alguien no. En general, no hay obstáculos insuperables para la implementación, pero ahora tenemos una escasez de revisores para ver el código de Kotlin. Si todos comenzamos a escribir abruptamente mañana en Kotlin, entonces la gente "desgarrará" las solicitudes. Además, en el caso de Kotlin, hay problemas con el analizador de código estático, que se utiliza en nuestra cartera.
Entonces, Kotlin se implementa en pequeños pasos: por ejemplo, escribimos pruebas en Kotlin y usamos clases de datos (por lo que ahorramos tiempo para no escribir pruebas para getters, setters, equals (), hashCode () y así sucesivamente).
Ahora se está ejecutando lentamente, y en el siguiente paso queremos escribir nuestro DSL para probar en Kotlin. Y en paralelo, queremos elevar el nivel de conocimiento de Kotlin en la empresa: por ejemplo, con la ayuda de mitaps.
- En el caso de "Diálogos", participa en mensajes, pero no es un análogo directo de WhatsApp. Entonces, es interesante: ¿qué tan útiles son las soluciones de otras personas para usted? ¿Utiliza mensajeros de código abierto en el código?- Fue útil cuando queríamos agregar emoticones. Teníamos una pregunta sobre cómo hacer un panel con ellos, y en el código abierto vimos una opción donde todo se resuelve fácilmente mediante una ventana emergente sobre el teclado. Entonces todo converge en altura, y resulta perfectamente para el usuario.
Pero en general, mirar las decisiones de otras personas no siempre es bueno, es más eficiente formar las propias, teniendo en cuenta la experiencia de los demás. Por ejemplo, es mejor no mirar Telegram en absoluto, porque debido al gran tamaño de las clases en el
código fuente de su aplicación de Android, no es fácil resolverlo. Estamos tratando de seguir nuestro propio camino, especialmente porque la interacción con el servidor puede ser diferente: en el mismo Telegram es MTProto, tenemos los WebSockets habituales.
- Soy un entrevistador perezoso, así que decidí tomar una lista de las cosas con las que estás conectado en el trabajo y preguntar sobre cada tema "dinos exactamente cómo van las cosas con esto".
El primer punto: usted está en la "arquitectura del módulo de aplicación". Ya dijimos sobre el hecho de que la aplicación está dividida en módulos: ¿qué más se puede decir sobre la arquitectura?- Se está desarrollando de forma iterativa con nosotros, el control de versiones está en marcha, ahora hemos llegado a la 17ª versión.
El 16, se introdujo la arquitectura limpia. Acordamos quién es responsable de qué (presentación, dominio, capa de datos), qué entidades y dónde deberían usarse, dónde deberían estar los convertidores; en general, pintaron todos los problemas arquitectónicos y los implementaron.
Implementado de la siguiente manera: todas las nuevas características tuvieron que escribirse en nuestra nueva arquitectura. Si en la solicitud de extracción algo se desvía de la norma establecida, dicha solicitud de extracción se revisa. Pero al mismo tiempo, no se apresuraron de inmediato a ver todas las funcionalidades antiguas, porque esto puede causar muchos problemas.
Para la capa de presentación, elegimos el estándar MVP, pero algunos de nuestros equipos usan MVVM. En la capa de presentación, no estamos limitados por nada. Por ejemplo, vimos nuestro chat en MVI, más precisamente, en nuestra interesante implementación de MVI, que es fundamentalmente diferente de lo que escribió el desarrollador Mosby.
Luego cambiamos a la versión 17 de la arquitectura e implementamos RxJava, lo que implicó cambios arquitectónicos. Si usamos definiciones estrictas, ahora nuestra arquitectura ha resultado ser hexagonal, desde Clean hemos "bifurcado". Pero son similares en que ambos funcionan según principios SÓLIDOS, por lo que uno fluye hacia el otro sin problemas. Ahora estamos trabajando en eso.
En futuras versiones de la arquitectura, queremos abandonar el marco Moxy utilizado para implementar MVP, porque causa algunas dificultades. El proyecto es grande, utiliza el procesamiento de anotaciones y, al realizar cambios en los módulos del "nivel inferior", el tiempo de construcción es grande. Y nos esforzamos por facilitarles la vida a nuestros desarrolladores.
- El segundo punto es "la optimización del trabajo y el consumo de memoria". ¿Qué tan aguda es esta pregunta? ¿Tengo que pensar constantemente en ella para los usuarios con dispositivos más antiguos?- Este problema está en el foco de los equipos de plataforma, están desarrollando herramientas que los equipos utilizan. La necesidad de hacer esto, más bien, surge como la necesidad de uno de los equipos. Por ejemplo, en el equipo de Diálogos, en las primeras etapas de desarrollo, el chat era muy lento. Luego tuve que arremangarme las mangas, comenzar con el perfilador, ver dónde estaban los cuellos de botella en la aplicación, averiguar las razones de su aparición.
En términos de optimización, por ejemplo, abandonamos PNG y los eliminamos gradualmente del proyecto para usar solo el vector. La optimización del gráfico de dependencia en Dagger está prevista para este año para acelerar el arranque en frío de la aplicación.
- Pasemos a las preguntas de prueba: ¿cómo te está sucediendo?- Solo puedo hablar sobre nuestro equipo, en otros este proceso se puede construir de manera diferente.
Nuestro equipo inicialmente tenía un probador. Posteriormente, se aburrió con solo probar. Y comenzó a pedirnos que lo ayudáramos a lidiar con la redacción de pruebas unitarias. Le mostramos cómo escribir pruebas para la base de datos, en esencia, para analizar, y de esta manera nos descargó, eliminó parte del trabajo de nosotros. Esto es bueno: él está interesado y nosotros.
Con el tiempo, llegamos a la conclusión de que necesitamos automatizar la regresión, necesitamos escribir pruebas de IU. Al principio, mi socio y yo trabajamos en pruebas de IU, y luego el departamento de calidad se unió a nosotros, nuestros evaluadores que probaron el backend en el pasado. Conocen Java, y ahora están conectados a nuestro proyecto para automatizar toda la regresión. Nos sentamos y consideramos las soluciones que son: Appium, Espresso, Selenium.
Nos detuvimos en Espresso y comenzamos a desarrollar enfoques juntos. Para facilitar las pruebas, desarrollamos nuestro propio marco, algo así como Kakao. Comenzamos este trabajo a principios de 2017, y ahora tenemos un gran marco, y la mayoría de las pruebas se ensamblan como un constructor, porque se han escrito muchos emparejamientos y juegos de acción para diversas situaciones.
Ahora, nuestros evaluadores nos piden activamente que les enseñemos cómo escribir pruebas de IU, porque es más fácil escribir una prueba una vez, que "perforar" las mismas acciones en cinco dispositivos. Pero, por supuesto, no automatiza todo, y algunos casos aún deben verificarse manualmente.
En cuanto a los desarrolladores, se realiza una retrospectiva en nuestro equipo cada dos semanas. En uno de ellos, llegamos a la conclusión de que los desarrolladores deberían realizar al menos pruebas alfa después de escribir una función. Para no eliminar ningún error completamente básico de la forma "la aplicación se bloquea al inicio". Por lo tanto, los desarrolladores también se conectaron a las pruebas. Cuando estamos preparando una versión principal y necesitamos probar rápidamente la función, todos se sientan para la regresión y juntos pasan las pruebas de regresión. Cuando se detecta un error, los desarrolladores se desconectan de la regresión, lo reparan rápidamente y de nuevo.
- Siguiente elemento: revisión del código. ¿Tiene algún detalle, o "como todos los demás"?- Hay una especificidad causada por el número de desarrolladores. Cuando hay diez desarrolladores móviles en una empresa, dos o tres personas pueden revisar todo. ¿Y cómo revisar el código de cientos de personas? Desarrollamos una "matriz de revisión". Se seleccionaron de 20 a 30 personas, de quienes sabemos con certeza que pueden publicitar, dejar comentarios y resolver puntos controvertidos en los comentarios. Tomaron a estas personas y dividieron todos los equipos entre ellos.
¿Por qué una matriz? Esto es para garantizar que todos los revisores tengan la misma carga. ¿Cómo va la revisión? Nuestro equipo requiere al menos tres evaluaciones. El primero es de alguien en el equipo. El segundo, de alguien de afuera, de un equipo que no se ocupa de esta funcionalidad. Y la tercera aplicación: de alguien de un equipo adyacente. En nuestro caso, hay varios comandos relacionados, y todos miran nuestro código. Bueno, en consecuencia, todas las compilaciones deben recopilarse: las pruebas unitarias y las pruebas de IU deben pasar sin problemas. Por lo tanto, tenemos una revisión de código.
- El siguiente punto es la refactorización del código heredado. ¿Cómo sucede sistemáticamente: precisamente con las tareas planificadas, o "necesitabas hacer cambios en el código anterior, al mismo tiempo refactorizarlo"?- En general, tenemos un peculiar "principio de exploración": si tocaste algo viejo, ten la amabilidad de hacerlo bien, ahora eres coautor. Pero también hay una refactorización planificada. Por ejemplo, para Diálogos, se necesitaba refactorizar dos direcciones: el libro de contactos que usamos y las traducciones. El libro de contactos se sacó, se limpió, se reescribió la base de datos completa en la sala, se llevó a cabo en un módulo separado. Y nuestros pagos se escribieron hace mucho tiempo usando RoboSpice, si aún recuerda esto, y nos dolió. Debo decir que cortar esto fue una tarea desagradable, porque tenía muchos vínculos. Y tenía que limpiarlo sutilmente para no romper el resto de la funcionalidad.
- Incluso en Sbertekh, estás involucrado en la formación de programadores. ¿Cómo es la capacitación dentro de la empresa?- Desde septiembre, está previsto llevar a cabo un programa como el reciclaje de los empleados internos. Ahora ya hemos definido una variedad de temas en Java y Android. Por ejemplo, tenemos javascriptores, javists y analistas que desean volver a capacitarse en Android. Dicha escuela se organizará para ellos, donde habrá un estudio enfocado, de acuerdo con el horario y con conferencias.
Y ahora hemos tenido regularmente mitaps. La elección de temas para ellos no es la misma que en las conferencias, donde es necesario algo nuevo y exagerado. Por ejemplo, si sabemos que los desarrolladores tienen problemas con algo, es importante hablar de esto. De reciente - uno de nuestros desarrolladores habló sobre gráficos vectoriales. No solo se trata de una biblioteca específica que dibuja vectores maravillosamente en Android, sino que comenzó con el funcionamiento de los gráficos vectoriales en general, y luego pasó a la privada. Hablaron sobre Room y sobre la concurrencia de Java, con la que muchos desarrolladores tienen problemas, y sobre Dagger 2.
El año pasado, tuvimos una escuela de desarrollo de Android y contratamos a quienes la completaron con éxito. Dichas personas no deberían estar conectadas de inmediato a algunos proyectos y dejar que cocinen por su cuenta. Por lo tanto, se asigna un mentor a cada empleado recién llegado y también al junior, que lo guiará, desarrollará y ayudará. Este es un aprendizaje interno.
- Entrevistas: ¿las tiene "como todos los demás", o hay una especificidad?- Solía pensar que "como todos los demás", pero al final resulta que todavía son un poco especiales. En mi experiencia, hay tres enfoques comunes en el mercado. El primero se pregunta sobre tres o cuatro temas y se evalúa únicamente sobre ellos. Por ejemplo, vine a la compañía como desarrollador de Android, y se me considera una persona que debe tener un excelente conocimiento de algoritmos y sincronización en Java, y al mismo tiempo no aprecio lo que hago en las superbibliotecas.
Esto puede deberse al hecho de que la empresa necesita una persona que necesite conocer una parte estrecha del marco o el lenguaje. El segundo: cuando se entrevista a través de las mangas, casi una conversación de por vida durante 30-40 minutos. Aquí, más bien, el asunto radica en las competencias y la experiencia del entrevistador. El tercero: cuando en una entrevista hablan sobre los problemas de la empresa e intentan encontrar algún tipo de solución en el acto. La desventaja de este enfoque es que la solución puede no coincidir con la opinión de la persona que hace esta pregunta. En mi opinión, tales enfoques se encuentran en aproximadamente la mitad de los casos., : , OOD (Object Oriented Design, ), Java Core Android SDK. . , , . : , , - . . , , , Dagger 2, RxJava. , Kotlin. , . - , , , . , .
— « ». - , .— — RxJava, , . , , . .
Retrofit, : , , . , — .
TinyMachine - — , , , . , «» , , . -, , - rocket science, .
— : . , , ?- si. — Java-. « »: Java- — - («» — Android-: , , , ). , , , — Java-. , . , , , , « payment? payment payment ? paymentTest?».
, Confluence. , material design , - , . , , Confluence. , , , , , , . : RxJava Confluence best practices — , , . : , .
, . Confluence 200 . . Confluence, , , .
