El hombre es el principal valor de cualquier empresa. El éxito de todo el negocio depende de cómo las personas se comunican entre sí, cómo logran sus objetivos juntas y en el trabajo en equipo. Perfeccionar constantemente las habilidades, procesos y herramientas le permite trabajar de manera más eficiente.
En Market estamos trabajando para ofrecer nuevas funciones a nuestros usuarios lo más rápido posible. Para hacer esto, estudiamos constantemente nuestros procesos y optimizamos todas las etapas de la tarea. Hoy les diremos a los lectores de Habr sobre la optimización de uno de ellos, es decir, el proceso de revisión del código.
Primero debe imaginar qué tipo de flujo en el desarrollo hemos adoptado:
Lo mismo, solo punto por punto y en palabras:
- El desarrollador toma la tarea.
- La hace.
- Rellena Github y abre relaciones públicas.
- Pasa una revisión de código.
- Recoge un soporte de demostración y se lo da a un probador.
- El probador verifica el soporte de demostración.
- La tarea verificada se recopila en la versión.
- Pruebas en lanzamiento.
- Diseño en prod.
- Pruebas finales en batalla.
Por áreas de responsabilidad, la tarea se divide en los siguientes pasos:
1-5 - responsabilidad sobre el desarrollador;
6-7 - responsabilidad en el probador;
8-10 - responsabilidad en el maestro de lanzamiento.
Entonces, comenzaron a analizar lo que nos lleva más tiempo. Afortunadamente, existen herramientas de análisis interno. Todos confiaron en lo que llevará más tiempo, por supuesto, el proceso de desarrollo en sí mismo (el estado "En el trabajo") ... y resultó de esa manera. Pero un momento nos sorprendió más. ¡La duración promedio de una revisión es de dos semanas!
Paso 1. Analizando PR
Comenzando a estudiar las solicitudes de extracción, inmediatamente se enfrentaron a un hecho muy interesante. Resultó que tenemos un gran cementerio de solicitudes de extracción no cerradas. La mayoría de los autores de estas relaciones públicas ya no trabajaban para la empresa, pero su legado todavía estaba con nosotros. Quien nunca ha visto dinosaurios, aquí están:
Estas solicitudes de extracción agregaron ruido e interfirieron con el análisis correcto del tiempo de revisión del código. Con una mente tranquila, los cerramos. Solo quedaba contar el tiempo. Pero todavía estaba en el área de 2-3 días. No es bueno
Paso 2: Desmontaje con un navegador
Reviewer es un sistema desarrollado en Yandex que llama en PR dos personas aleatorias con experiencia en un código mutable y que tiene en cuenta las vacaciones y las ausencias. El análisis de las relaciones públicas semanales reveló un grupo de personas que constantemente arrastran la revisión del código. Después de entrevistar a colegas, encontramos otro problema en nuestro proceso. Los colegas se quejaron de que recibían demasiadas solicitudes de extracción por día de los celosos, y simplemente no tenían suficiente tiempo para su trabajo principal.
Esto no coincidió con nuestros indicadores: uno o dos RP por día por persona. El estudio condujo a Github, donde tenemos un equipo separado de revisores. Este equipo no ha sido actualizado por varios años. Desde entonces, el número de empleados se ha duplicado, pero ninguno de los recién llegados se incluyó en el equipo de revisores. En otras palabras, ¡la mitad del equipo no participó en la revisión del código! Se corrigió este molesto malentendido.
Paso 3. Extender herramientas
En esta etapa, tratamos de simplificar la vida ya simple, como pensamos, de los revisores. Las siguientes herramientas estaban en el arsenal de front-end:
- correctores de estilo de código;
- prueba de funcionamiento;
- varios controles nerd en el propio PR;
- revisionista
- alertas en correo y rastreador de tareas.
Parece que todo está ahí. Toma y revisa!
Lo primero que resultó ser incorrecto: un proceso de revisión de código diferente en diferentes repositorios. Unificamos y al mismo tiempo probamos la colocación de etiquetas para una búsqueda conveniente de relaciones públicas a través de la interfaz de Github.
La segunda cosa que notaron: el correo no es la mejor herramienta para informar rápidamente sobre el estado de las revisiones de código. Muchos, para no distraerse del trabajo, analiza su correo varias veces al día. Los mensajeros son un asunto completamente diferente. La reacción a los mensajes en los mensajeros es mucho mayor. Y se decidió conectar el bot a nuestro messenger. El bot envía alertas sobre el estado de una revisión de código para el autor de la solicitud de extracción y alienta a las personas a revisar. Muy comodo
Paso 4. Primero SLA
Paralelamente a las acciones 2 y 3, comenzamos a trabajar estrechamente con los empleados y explicamos que la revisión del código es inseparable de la tarea misma. Explicaron que llevar a "Verified" es responsabilidad del desarrollador. ¡Además, la responsabilidad no es solo de los colegas, sino también de los usuarios! Entrega rápida de funciones a ventas: eso es lo que quería lograr. Y el equipo simpatizaba con el proceso de mejora.
En esta etapa, nació la primera idea de la revisión de código ideal. Por supuesto, todos quieren que tenga lugar en 5 minutos, pero esto no siempre es posible. Teniendo en cuenta que tenemos un equipo multirregional (con una diferencia horaria de cuatro horas), acordamos que nuestro SLA será de un día, es decir. 24 horas Este SLA se anunció a todos los empleados y, frotándose las manos, comenzó a esperar los resultados.
Pero la situación no ha cambiado. En las mejores semanas, la mitad de las solicitudes de extracción caben en 1 día. El resto salió por él.
Teníamos un pequeño script que evaluaba la revisión del código de tiempo en PR. Comenzamos a culparlos diariamente por todos los RP en busca de "rezagados". Casi todos los días había un paquete de tales.
Tomó mucho tiempo analizarlos. Muy a menudo, el guión mismo calculó deshonestamente el tiempo de la revisión. No tuvo en cuenta que algunos RP se crearon fuera del horario laboral (sí, a algunas personas valientes y hábiles les gusta trabajar durante una o dos horas por la noche, ¡vengan a trabajar!). Todo esto nos dijo que nuestras herramientas de monitoreo de solicitud de extracción no son las más efectivas, ya que son deshonestas. Tengo que encontrar nuevas herramientas.
Paso 5. Rastreador de SLA
La ayuda vino de donde no esperaban. Nuestros colegas de Tracker anunciaron algo sorprendente: ahora puede instalar SLA en el mismo Tracker. Además, puede configurarlo de manera completamente diferente. Un cierto temporizador es activado por algún evento en la tarea. Para algún evento, puede pausar. Y detente en algún evento. ¡Sí, esto es lo que necesitamos!
Inmediatamente entraron en un estudio detallado de la documentación (por cierto, aquí está ) y configuraron nuestras colas (hay varias, ya que hay varios repositorios). Configuramos el temporizador para que se encienda cuando se cambia al estado "Necesita revisión de código" y finaliza cuando cambia a cualquier otro estado, excepto "Hay comentarios" - cuando pasa, el temporizador se detiene, es decir No perdió su tiempo.
¡También fue genial que el temporizador tuviera en cuenta las horas de trabajo y un calendario! Establecemos que 9h se asigna a la revisión del código, es decir Un día hábil. En este caso, se activa una alerta 2 horas después del inicio, o si se interrumpe un plazo de nueve horas. El resultado fue una especie de monitoreo honesto. Al principio, encendimos el temporizador por el bien del experimento, recolectamos un paquete de errores y los exportamos al Rastreador.
Vale la pena señalar que el temporizador se habilitó solo para las tareas que se crearon después de la implementación del temporizador. Por lo tanto, no se pudo ver el efecto instantáneo. Pero ya en esta etapa, comenzó una dinámica positiva. Tuvimos efecto un mes después, cuando el flujo de boletos nuevos con un temporizador comenzó a desplazar a los viejos. Se notó que el tiempo aproximado de la revisión del código se concentró en el área de los mensajes recordatorios, es decir. marca 2h y 9h.
En el momento de escribir esto, tenemos 415 tareas en las que el temporizador ha comenzado. De estos, 29 fueron más allá de la frontera de nueve horas. Sin embargo, si observa más de cerca, también encontrará tales tareas, cuya revisión de código se completó en la próxima hora. Si también los descartamos, quedan 17 tareas. ¡Y esto es alrededor del 4.1%!
El resultado Samurai constantemente afilando su espada
Mirando hacia atrás y recordando todas nuestras acciones, se puede llegar a una conclusión: todos los medios son buenos. Todos nuestros pasos condujeron al resultado deseado: ¡más del 92% de las solicitudes de extracción comenzaron a satisfacer nuestro SLA ! Cada vez menos tareas desgarradas, la revisión de código es más rápida. ¡Poco a poco, poco a poco, el 75% de la revisión del código comenzó a caber en 5 horas ! Y la dinámica de mejora sigue siendo positiva. Además de los indicadores numéricos, comenzamos a recibir comentarios más positivos de los subcontratistas. Aún más satisfecho con el hecho de que el equipo reaccionó a todo este proceso. Incluso un proceso como la aceleración de revisión de código reunió al equipo aún más. Cada participante comenzó a comprender la responsabilidad que tiene ante los demás, ya que un código de revisión rápida nos permite beneficiar a nuestros usuarios aún más rápido.
Por supuesto, 9h no es el último sueño, pero sigue siendo un éxito. Pero en eso no pretendemos detenernos. Continuamos monitoreando el proceso de revisión del código y resolviendo todos los problemas técnicos e incluso psicológicos que enfrentan los empleados para que nuestro proceso sea lo más productivo posible y al mismo tiempo cómodo para el equipo.
Q&A ¿Y si ...?
P : ¿Qué pasa si creo que me están mirando? ¿Para qué sirve este temporizador?
R : Estamos monitoreando no específicamente a alguien, sino al proceso. La solicitud de extracción tiene dos lados: el autor y los revisores. Si los revisores arrastran el cheque, entonces el autor sufre. Por otro lado, también es inhumano separar a los inspectores del trabajo de inmediato. Es necesario encontrar un equilibrio para que ambos lados estén cómodos. El temporizador no es necesario para castigar a alguien, sino para registrar todas las desviaciones. La mayoría de estas desviaciones no ocurren por culpa de los revisores, sino por culpa de problemas técnicos. El desafío es solucionar estos problemas. Para que otros no los encuentren. Mejoramiento continuo
P : ¿Y si hay relaciones públicas complejas, más de 100500 líneas de código y hay "cambiar la letra"? ¿Dónde está la justicia?
A : Sí, esto es verdad. Cuando estábamos trabajando en la revisión del código estándar, lo llevamos a lo largo del límite superior, es decir, La revisión del código de relaciones públicas complejas debe encajar en el SLA. Pero al mismo tiempo, no tenemos el objetivo de llevar a todos a estos límites. Siempre simpatizamos con las solicitudes de extracción, en las que hay una discusión animada y útil, a pesar de la barra rota en un día.
Tenemos planes para las calificaciones de SLA en los puntos de historia. 1SP - 1h, 3SP - 5h, 5SP - 2d, por ejemplo. Afortunadamente, el Rastreador ya es capaz de esto. Todavía no estamos preparados para esto, todavía tenemos un largo camino por recorrer.