Seguramente todos ustedes en diferentes etapas de su carrera se han enfrentado a tal problema: vieron una tarea, parece que es simple y los requisitos son claros, y luego resulta que necesitaban implementarla de manera diferente. Se ha gastado tiempo para la implementación, la fecha límite ya se acerca sigilosamente y la tarea no está lista. Tenemos que reescribir sobre la marcha, probablemente en violación de la fecha límite. Se pierden horas de trabajo y cuestan dinero, y si este problema no es para un desarrollador, sino para toda la empresa, entonces aumentará un montón de tareas atrasadas, aumentará el costo de desarrollo, la empresa no podrá implementar la estrategia y la empresa sufrirá pérdidas.
¿Cuál es el problema?
Tal problema surge debido a una inmersión insuficiente en la tarea. Puede haber muchas razones, estas son algunas de ellas:
- falta de documentación actualizada;
- malentendido del proceso empresarial;
- la elaboración de requisitos no es completa;
- el factor humano (la fuente del conocimiento y el intérprete hablan de lo mismo, pero lo entienden de manera diferente);
- descuido personal de artistas y clientes;
- y otros (cada uno pisó el rastrillo a su manera).
Como resultado de una inmersión insuficiente en la tarea, los desarrolladores hacen lo incorrecto o no del todo, los probadores hacen lo incorrecto, los devops hacen lo incorrecto y el SRE monitorea los parámetros incorrectos.
¿Cómo se puede arreglar esto?
En trabajos anteriores, he visto el siguiente algoritmo de trabajo:
- recopilación de información y formación de requisitos;
- el equipo se está preparando y pensando en una solución común;
- se nombra un albacea que ejecuta la tarea;
- revisión de código;
- arreglos
- pruebas;
- más arreglos;
...
- más arreglos;
- finalización de la tarea tan esperada.
, , ?
, , , , . 
La descripción de la solución técnica se realiza incluso antes del inicio del desarrollo y luego es revisada por todo el equipo. Por claridad y mejora de la percepción, decidimos diluir el texto con esquemas gráficos. El propósito de esta acción es identificar los escollos, elegir las herramientas adecuadas, interactuar correctamente con otros nodos del sistema y poder sumergirse en la solución con todo el equipo. El resultado que esperábamos fue una disminución de los costos laborales y errores en los procesos de negocio (de cara al futuro, diré que los errores en la lógica empresarial prácticamente han desaparecido, se han evitado muchos errores técnicos, se han reducido las correcciones y el tiempo medio para completar la tarea ha disminuido bastante bien). También resultó que es mucho más fácil y rápido realizar ediciones en una descripción textual o diagrama que en un código ya escrito.
Entonces el algoritmo de trabajo será el siguiente:
- recopilación de información y formación de un requisito;
- el equipo se está preparando y pensando en una solución;
- se designa un desarrollador responsable;
- el desarrollador describe la solución técnica ;
- luego esta solución técnica es revisada por el equipo y otros inmersos en el área temática ;
- y solo después de que se haya acordado la decisión, el desarrollador escribe el código ;
- revisión de código;
- pruebas.
Por qué es tan importante describir la solución técnica antes de la implementación real:
- se revisa la lógica de la solución, los errores se corrigen en la etapa de diseño;
- el desarrollador profundiza en el dominio antes de la implementación, lo que permite pensar en la arquitectura de antemano;
- los departamentos adyacentes pueden comprender de inmediato qué será la API y están listos para comenzar el desarrollo paralelo;
- aclara las necesidades de los colegas en función de su implementación;
- ( , , ).
Exness?
Habiendo llegado a Exness, quería acostumbrarme rápidamente al equipo, estudiar la infraestructura y empezar a resolver misiones de combate. En la primera tarea amplia, decidí usar la experiencia acumulada y minimizar el riesgo de resolver incorrectamente el problema. Para describir la interacción de los servicios, decidí usar diagramas de secuencia, un diagrama de bloques para describir el funcionamiento de los algoritmos y diagramas ER para describir el esquema de la base de datos.
En el proceso de dibujar un diagrama, aprendí de mis colegas qué servicios podrían ser necesarios para resolver mi problema, verifiqué las solicitudes y los datos en la base de datos, así que ya entendí qué y cómo funciona. No me tomó mucho tiempo desarrollar el diagrama y, mientras lo revisaba, obtuve comentarios útiles:
- el desarrollador de front-end quería saber en qué casos, qué datos y estados recibiría del back-end;
- El control de calidad debe comprender de dónde provienen los datos del servicio para cubrir tantos casos como sea posible.
En el diagrama, he detallado las excepciones y cómo surgen, y las fuentes de datos utilizadas. Esto hizo posible mostrar visualmente a los colegas cómo funciona la funcionalidad y qué esperar de ella, respectivamente, los colegas pudieron comenzar a implementar sus partes sin esperar mi implementación. El desarrollador de front-end sabía cómo respondería el servicio y podía comenzar a escribir integraciones; QA tenía información sobre cómo el servicio responde a diferentes situaciones y cómo reproducir estas situaciones. Como resultado, el desarrollo y la inmersión en la tarea resultó bastante rápido, y el diagrama dibujado complementó la documentación del servicio que se estaba desarrollando.
Ejemplo
El ejemplo que se describe a continuación es una combinación de varias situaciones.
El nuevo desarrollador recibió una tarea con la frase " Escriba un nuevo microservicio para rechazar las solicitudes vencidas. Notifique a los clientes sobre el cambio de estado " .
Después de aclarar los detalles técnicos, puede comprender el problema de esta manera:
- construya un microservicio, haga un POST en él - un método API llamado fail_old_requests;
- en este método de API, debe obtener datos de la base de datos, especificar filtros por usuario, estado y fecha en la solicitud;
- para cada solicitud, cambie el estado en el servicio que administra las solicitudes;
- luego envíe una solicitud al servicio de notificación para notificar a los usuarios sobre el cambio en el estado de la aplicación.
El diagrama de secuencia para esta tarea podría verse así:
y qué errores podría encontrar:
- bajo el nuevo microservicio, el analista podría referirse al método API habitual en el microservicio para trabajar con solicitudes, pero es difícil reconocer tal escenario (en mi práctica, hubo un caso en el que el analista entendió el método API habitual como un microservicio, hasta donde yo sé, el analista no se adaptó a la terminología correcta);
- tal vez la aplicación tenga sub-aplicaciones o aplicaciones relacionadas, cuya existencia el nuevo desarrollador puede desconocer, y el analista puede olvidarse de informar y esperar que el desarrollador mismo obtenga la información;
- Quizás habrá muchas aplicaciones, y su rechazo en la venta llevará mucho tiempo. En este caso, sería mejor colocar y permitir el rechazo en segundo plano;
- — , . , .
Como resultado, resulta que dicha solución tendrá que reescribirse desde cero, ya que la presencia de tales errores puede hacer inviable la implementación.
Si escribe una solución técnica antes del desarrollo y usa un diagrama de secuencia para mayor claridad, durante su revisión, los colegas más inmersos en el área temática podrán ver errores y señalarlos. Y probablemente el propio desarrollador podrá ver algunos problemas y solucionarlos antes de la revisión.
Les aseguro, solo decir la solución al problema no significa resolver el problema correctamente, uno no lo expresará correctamente y el otro no entenderá correctamente, y la tarea no se implementará correctamente. El diagrama de secuencia no es una fórmula mágica, pero en muchos casos ayudará a aclarar algunos detalles.
Cómo se vería el diagrama después de las correcciones:
¿Para qué sirven los gráficos?
No todas las personas pueden transferir bien un pensamiento al papel, por lo que a veces es mejor diluir el texto con una descripción gráfica. Una descripción más clara de la tarea será útil no solo para los desarrolladores, sino también para los probadores, ya que enfrentan el mismo problema de inmersión que los desarrolladores. Los probadores no solo deben verificar los resultados positivos, sino también asegurarse de que el sistema responde de manera correcta y predecible en cualquier situación; para emular estos casos, es necesario comprender bien qué ha cambiado en el sistema. Para el equipo en su conjunto, puede ser más conveniente almacenar la documentación en forma de diagramas o esquemas varios, ya que son lacónicos, con grandes cambios, requieren menos tiempo para editar que una descripción textual. En una refactorización importante, los gráficos son indispensables porque le permiten comprender rápidamente quién y cómo está trabajando con un nodo en particular en el sistema.Para los líderes de equipo, la cosa será útil ya que puede reducir su tiempo y el tiempo de inmersión de los colegas junior y, en consecuencia, planificar las tareas con mayor precisión. Al transferir casos de un desarrollador a otro, los costos de tiempo se reducen, respectivamente, la situación con el factor de bus mejora.
¿Qué conclusiones se pueden sacar?
Los diagramas de secuencia son una herramienta muy poderosa y útil que le ahorra tiempo a usted y a sus colegas. Una descripción visual facilita la comprensión y le permite centrarse en la solución en sí sin profundizar en la implementación técnica. Pero en ningún caso diga que tal descripción visual es una salvación de todos los problemas, pero ayudará a resolver una parte significativa de ellos.
Los diagramas definitivamente ayudarán con:
- la calidad y velocidad de inmersión en el proyecto / tarea;
- mejorar la situación con el factor bus;
- reducir los costos laborales para el mantenimiento de la documentación técnica;
- simplificar la transferencia de casos entre colegas;
- Reduzca los costos de mano de obra para la implementación, las pruebas y la revisión del código, ya que la lógica para resolver el problema se revisa incluso antes del inicio de la implementación; evitará muchos errores.
Personalmente, en mi práctica, los diagramas han sido y siguen siendo una herramienta indispensable.
Deseo que usted también encuentre herramientas que optimicen su trabajo. Gracias por leer hasta el final.
PD Escribe en los comentarios, ¿utilizas esta práctica, qué herramientas utilizas?