En la vida de casi cualquier equipo de desarrollo, llega un momento en que la creación de nuestro propio marco pasa del estado de "¿Qué demonios deberíamos perder el tiempo?" al estado "¡Buena idea!". Tuvimos ese momento hace unos dos meses, cuando comenzamos a atornillar el control de voz de las transferencias usando Siri a la aplicación móvil cliente de PSB Mobile, PSB Mobile. Analizamos nuestra experiencia y sobre esta base le diremos cómo entender que, sin embargo, ha llegado el momento de los marcos.
"¿De qué marco, de qué estás hablando?"
Anteriormente, el cliente iOS del banco para individuos se desarrollaba en outsourcing. Luego se decidió reescribir todo por su cuenta desde cero. Construimos un proceso SCRUM con sprints de dos semanas, el trabajo comenzó a hervir: estábamos buscando activamente y agregando nuevas características, chips. En esta etapa de búsquedas activas, era difícil predecir qué se enraizaría, qué no. Planear todo 40 pasos por delante no tiene sentido. Nadie pensó en los detalles como la universalidad: cree su propio marco, asigne partes del código en bibliotecas separadas para su reutilización. La probabilidad de que esto no tuviera sentido era demasiado alta.
WWDC nos conectó
Por qué SCRUM es bueno: a menudo contactamos a la empresa como cliente. Al mismo tiempo, comenzaron a ocurrir cambios importantes. Comenzamos a comprender mejor el producto, las tareas comerciales, los procesos comerciales del banco en el que participa la aplicación. Y lo más importante, el negocio, por su parte, comenzó a considerar el desarrollo de la aplicación como un proceso, comenzó a comprender mejor cómo trabajamos, comenzó a estar de acuerdo con nosotros en que hay tareas importantes, cuya solución no produce un efecto momentáneo notable.
Nos ayudó a llevarnos bien con los negocios ... Conferencia de la WWDC. Nuestros clientes comerciales de alguna manera vieron los anuncios de nuevas oportunidades de Apple y se subieron a Apple Developer con curiosidad. Sorprendentemente, todo resultó mucho más claro de lo esperado. Desde entonces, no solo estamos involucrados en tareas comerciales, sino que las empresas ya no le temen a la tecnología: intentan leer las especificaciones ellos mismos, obtener información sobre los problemas, ayudar con el análisis y entrar en los problemas del desarrollo. Comenzaron a darse cuenta de que era inútil esperar un claro aumento del producto cada dos semanas; después de todo, hay sprints de servicio, de los cuales no hay un crecimiento concreto. El entendimiento mutuo llegó al punto en que acordamos dar una refactorización del 20% del tiempo de sprint.
La evolución de las bicicletas.
Con el crecimiento del departamento de desarrollo, el llenado de la aplicación con nuevas características, la aparición de varios equipos trabajando simultáneamente en diferentes tareas, comenzaron a aparecer nuevos matices. Algunas de las subtareas para los equipos podrían ser similares, e inmediatamente hubo un deseo de no reinventar la rueda, sino primero de aclarar si alguien tenía un código listo.
Por lo general, no hay quejas sobre el código de nuestros desarrolladores, por lo que puede usarse repetidamente, y no solo dentro del marco de la metodología habitual de reutilización de código. Probablemente, ya en esta etapa en nuestras cabezas surgió la idea de separar algunas cosas en bibliotecas separadas para el bien común. Pero dentro del marco de las tareas existentes, no fue posible encontrar tiempo para estos procesos. Necesitaba alguna razón, y pronto el negocio nos lo arrojó.
Extensión del disparador
Hubo una tarea para brindar soporte a la interfaz de voz, para que pueda realizar pagos a otros clientes del banco a través de Siri a través del número de teléfono. Él dice: "Transfiere tanto dinero a esa persona". Y si esta persona es cliente de Promsvyazbank, entonces la tarjeta de la persona aparece en la pantalla, el monto de la transferencia, la pregunta "¿enviar dinero?" y enviar botón. Ya existe una función similar en algunas aplicaciones bancarias, pero queríamos hacerlo para que, por un lado, fuera seguro y, por otro, el cliente no necesitara ingresar a la aplicación bancaria.
Trabajar con Siri implica escribir una extensión separada, y cuando comenzamos a planificarlo, nos dimos cuenta de que era hora de desarrollar nuestros propios marcos. En nuestro proyecto de aplicación, se implementó una capa de red y surgió una opción (de hecho, no): volver a escribir esta capa o ponerla en un contenedor separado, disponible tanto en la aplicación principal como en una extensión separada.
En el proceso, surgió una subtarea arquitectónica para eliminar parte del código en marcos separados. Había cuatro en total:
- Capa de red (media): aquí está todo el trabajo con la red, clases de modelo, servicios API. Esta capa se genera de forma totalmente automática.
- Iniciar sesión
- Utilidades - Utilidades y ayudantes
- Almacenamiento: almacenamiento seguro
Está claro que este no es nuestro know-how. Por lo tanto, es habitual hacerlo en tales situaciones, esta es la mejor práctica de todos los desarrolladores que se respetan a sí mismos. Pero es importante cómo llegamos a esto. Fue en este momento que
tres signos clave se unieron para crear el marco:
- Hemos desarrollado una base de código suficiente
- Las empresas comenzaron a comprender nuestras (es decir, sus) necesidades arquitectónicas.
- Ha surgido una tarea adecuada
Nuevos horizontes
Después de darse cuenta de que todo resultó ser simple. En la próxima reunión de desarrolladores, discutimos los detalles, elegimos a la
víctima de la persona responsable que participará en la refactorización principal, le asignamos tiempo, un tiempo completo para esta tarea. El resto de los desarrolladores casi no afectó. Pero cuando comenzamos a poner la capa de red en el marco, aparecieron ideas de inmediato sobre qué otras partes del código que se usan con frecuencia deberían colocarse en la biblioteca. Nuestras posibilidades arquitectónicas se han expandido repentinamente. Comenzamos la vida con un grado adicional de libertad.
Pero lo usamos sin fanatismo. Para decidir si codifica el código en un módulo separado o no, observamos los retrasos y determinamos si este módulo se reutilizará en varios lugares. Si no, entonces no te molestes.
¿Vemos los beneficios de usar nuestros marcos? Definitivamente si. Ahora vemos qué partes del código requeridas como parte de la nueva tarea ya están en el repositorio. El desarrollo de nuevos servicios es más rápido, menos errores de programación, la calidad de los servicios finales es mayor.
Si necesita nuevas extensiones para iOS, ya tenemos los marcos necesarios, puede experimentar de inmediato. En cuanto al servicio ya implementado con Siri, ha estado disponible para los usuarios bancarios durante más de un mes; ahora estamos recopilando opiniones, incluso para comprender cómo y para qué más usar la interfaz de voz.
Un poco de futurología
La historia con Siri nos hizo pensar no solo en frameworks, sino también en interfaces en general. La humanidad aún no ha aprendido a medir la concentración de la atención, solo de manera indirecta. Por ejemplo, cuanto peor es el UX y la UI, mayor es el desperdicio de atención, más se estrecha el embudo de conversión con cada paso. Una transferencia de dinero regular a través de una aplicación bancaria requiere un montón de acciones del usuario: abra la aplicación, inicie sesión, busque en una lista, en la segunda, ingrese el destinatario. Con Siri, este es un desbloqueo más un comando de voz. La autorización se produce en primer plano a través de Face ID. Y en algunos escenarios, ni siquiera necesita traer el teléfono. Por ejemplo, cuando conduce y el teléfono está montado cerca, la cámara puede reconocerlo fácilmente.
Mire a su alrededor: los asistentes de voz están comenzando a conquistar activamente el espacio circundante. La exageración en torno al altavoz inteligente Yandex, las lavadoras que hablan y entienden las órdenes, los controles remotos de TV que reconocen la voz. Cuantos más usuarios estén rodeados de interfaces de voz, más estarán listos para comunicarse con las aplicaciones bancarias.
Las interfaces gráficas en esta situación perderán su monopolio, desde los principales medios de comunicación simplemente se convertirán en una confirmación visual de la acción, en una forma de indicar que la computadora lo entendió correctamente.
Para el desarrollador, tal cambio, en principio, no da miedo. Con la arquitectura correcta, la aplicación puede tener cualquier cantidad de interfaces: visual, de voz, neuro. Lo principal es utilizar enfoques que correspondan al nivel actual de madurez del equipo.