◾️ 🎐 🍖 Domar a la bestia: código heredado, pruebas y tú 👌🏿 🥨 😖

El código heredado es un código "antiguo", cuya edad puede ser de 2 meses y 10 años. A menudo, los desarrolladores escribieron sobre eso, que la compañía recuerda vagamente. Quizás no existían en absoluto, y el código heredado nació con el Universo durante el Big Bang. Desde entonces, los requisitos para ello han cambiado muchas veces, el código se corrigió en el modo "ayer fue necesario" y nadie escribió la documentación, como las pruebas. El código heredado es confuso y frágil, no muestra ni el principio ni el final. ¿Cómo acercarse a él?

De aquí en adelante tomas de la serie "Rick and Morty". Autores Justin Royland y Dan Harmon.

Necesitas llegar a él con pruebas, pero prepárate para el dolor. Los problemas comenzarán desde el momento en que decida emprender dicho proyecto. Debe comprender por qué quiere emprenderlo, convencer a la gerencia para que apruebe la prueba del código heredado y ayudar a sus colegas. Después de eso, surgen preguntas, ¿dónde comenzar el estudio, qué pruebas ejecutar primero y cómo no romper todo? Pero lo principal es cómo no caer en la desesperación cuando te das cuenta de que el trabajo no tiene fin.

Kirill Borisov ha estado en la industria durante 12 años, a lo largo de los años ha recorrido un largo camino en muletas, códigos rotos y marcos podridos de sistemas antiguos: desde sistemas de contabilidad monolíticos hasta microservicios de autorización. El viaje le otorgó experiencia e historias que compartirá en forma de valiosos consejos.

Tengo un sueño: algún día trabajar en un nuevo proyecto. Todo estará bien desde el principio y tan fresco como la primera nevada: pruebas, arquitectura y significado. Pero esto es solo un sueño, porque durante 10 años he estado vendiendo mi talento por dinero y pasando de un proyecto heredado a otro.

Durante este tiempo no me quedan nervios, pero puedo salvar los tuyos compartiendo mi experiencia de interactuar con el legado. Te diré cómo domar a la bestia (código heredado): trabajar con código y personas, implementar pruebas, si es necesario hacerlo y cómo los desarrolladores se relacionan con esto.

Lo que no estará aquí:

Consejos para escribir exámenes. Muchos libros, artículos y varios videos cubren esta pregunta.
Metodologías de discusión. BDD, TDD, ATDD: todo a su discreción.
Todo lo que puede violar la NDA. Las personas tienen una memoria larga y los abogados tienen armas largas.

¿Qué es el código heredado?

Hay muchas definiciones Creo que este es un código " bastante antiguo " de 2 meses a 10 años. El código heredado es confuso y frágil, pero como una serpiente gigante devora su cola.

Esto es lo que no le permite comenzar a probarlo con calma. Todos los desarrolladores, desde principiantes hasta experimentados, cuando llegan a un proyecto heredado, toman una lanza de pruebas y se apresuran a matar a este monstruo. La lanza se rompe, y con ella la gente. Como resultado, sigue habiendo un desarrollador sin signos de vida, que ha estado trabajando en un proyecto heredado durante décadas.

¿Es posible vencer a esta bestia? Sí, pero se necesita preparación.

Formación

La lucha contra la bestia no es tan importante como la fase preparatoria. Comienza con tres preguntas para uno mismo.

"¿Por qué estoy haciendo esto?" ¿En serio, porque? Después de todo, solo hay dos opciones.

, , , .
, .

¿Quieres trabajar para la comodidad de los demás o para tu propia gloria? Si para el último, con el primer éxito, el interés se desvanecerá, usted se desvanecerá, todo se desvanecerá. Cambiarás a otra cosa, y los restos podridos de tus esfuerzos obstruirán el proyecto durante mucho tiempo.

"¿Sé lo que estoy haciendo?" Si escribiste pruebas, ya sabes. De lo contrario, antes de apresurarse hacia el monstruo, domine los conceptos básicos: escriba 3-4 pruebas, cubra una pequeña parte del código, llene su mano y sienta el poder.

"¿Tengo tiempo para esto?" Es genial intervenir en el código con buenos impulsos y mejorarlo, trabajando para el futuro. Pero tal vez no haya tiempo para esto cuando el presente arda. Si es así, entonces el proyecto te necesita, no una imagen brillante del futuro.

Cuando responda afirmativamente a todas las preguntas, continúe con el siguiente paso.

Reconocimiento

Examina la estructura del proyecto . ¿Tiene una idea sobre la estructura del proyecto, los componentes y el principio del trabajo? Seguramente sí, pero quizás no coincida con la realidad. Es importante comprender lo que tiene que enfrentar antes de comenzar a trabajar. Dedique algo de tiempo para revisar el proyecto y estudiarlo a fondo.

Haz un diagrama de dependencia . Ningún proyecto vive en el vacío. Bases de datos, servicios externos, bibliotecas: todo esto se puede utilizar en el proyecto.

¿Qué te han hecho? Puede que no seas el primero en luchar contra la bestia. Examine las prácticas de los "antepasados" que quemaron y abandonaron el proyecto.

Después del reconocimiento, pasamos a las hostilidades.

Luchar con la organización

La primera ronda es una pelea con su organización. Lo principal es su gerente, jefe directo.

Gerente . No es tan aterrador como parece. Esta es una persona ordinaria con necesidades ordinarias: entregar el proyecto a tiempo y sin problemas innecesarios, obtener dinero y bonificaciones y seguir adelante.

El líder no está en contra de sus empresas. Él está en contra de ti corriendo al proyecto con gritos: “¡Pruebas! Pruebas! ¡Pruebas! Si lo hace, él lo verá como la persona que pasa su tiempo y ralentiza el resto.

Muestra el beneficio. El gerente habla el lenguaje del bien, el tiempo y el dinero. Comprenda que están motivados por el deseo de cerrar el proyecto a tiempo y obtener más resultados por menos recursos.

La prueba no debe presentarse así:

- ¡Oh, será genial!

Nuestras ideas deben promoverse de la siguiente manera:

- En el último trimestre, tuvimos 50 bloqueos que se pudieron solucionar en la etapa de desarrollo del producto. Puedes arreglarlo usando pruebas. Confirmarán que los cambios no cambiaron la funcionalidad, si no lo esperamos. Ahorraremos las horas dedicadas a resolver estos problemas y reduciremos el monto de la multa que se pagó debido a un sistema defectuoso.

Al decir "optimización, dinero, ahorro de tiempo", usted habla el idioma del gerente. Cuando escucha estas palabras, está imbuido de la idea. Él ve en ti no al próximo programador rabioso que le apasiona la tecnología nueva, sino a una persona interesada en mejorar el producto. No aprobará todas sus ideas a la vez, pero es muy probable que proponga Prueba de concepto.

Prueba de concepto aumenta las posibilidades.Proporcione al administrador un fragmento de código aislado y separado, un subsistema cubierto por pruebas, arranques y ejecuciones. Esto se puede hacer si toma uno de los errores que aparecen con cierta frecuencia e intenta atraparlo y solucionarlo con una prueba. PoC confirmará sus intenciones, mostrará que tiene un plan y su trabajo trae resultados.

No prometas mucho. Para el gerente, los números son importantes: cuáles son los resultados, el momento y por qué fuerzas. Pero el gerente es una criatura codiciosa de resultados. No prometas demasiado desde el principio. Si promete resolver todos los problemas de una vez, el gerente acudirá a las autoridades con esto. Las autoridades dirán: "¡Genial!", Pero reducirá los fondos y reducirá los plazos con la esperanza de que entreguemos el sistema mucho antes.

Cuando estamos de acuerdo con el gerente, recurrimos a aquellos con quienes tenemos que trabajar todos los días.

Colegas

No les gusta el cambio. Un colega típico en un proyecto de legado típico es una persona que ha perdido la fe en la vida y el futuro. No está dispuesto a cambiar y se resignó al destino: "Estoy aquí para siempre, no hay forma de salir del pantano". El problema es que comienzas a remover agua en este pantano. Usted le exige que escriba y ejecute algunas pruebas, pero él quiere hacer su trabajo, cerrar la tarea e irse a casa.

Involucre a sus colegas con los beneficios: explique por qué se sentirán mejor. Por ejemplo, constantemente dedican tiempo y esfuerzo, permanecen después del trabajo para curar algunos errores. Presiónelo: "Si no implementa un código roto para la producción, no tendrá que perder tiempo reparándolo. Escribiremos pruebas, atraparemos ese código, se romperá menos ".

Mostrar paciencia y empatía.Te comunicas con la gente. Pregunta por qué están preocupados por tu idea. Sugiera encontrar un terreno común para entenderse. Esta es la táctica principal para trabajar con las personas: no peleen, no choquen sus frentes, sean más amigables.

Es posible que no pueda presentar la idea antes de la reunión de colegas en el próximo stand-up de equipo. El mecanismo del "pensamiento grupal" funciona en el equipo: nadie quiere tomar una decisión, todos se miran y ven que nadie arde de entusiasmo.

Hay un truco sucio para resolver este problema. Desafortunadamente, en mi vida lo usé más de una vez.

Divide y vencerás. Diríjase a uno de sus colegas durante el almuerzo o en la esquina y diga: “Todo el equipo ya se ha registrado, usted es el único que frena el proceso. ¿Quizás podamos encontrar un lenguaje común?

Después de pasar por todo, firmas a todos. Todos se avergonzarán de admitir que pensaron que todos los demás ya se habían inscrito. Es deshonroso y terrible, pero funciona. Use esta técnica de manera responsable y como último recurso. Recuerde: aún tiene que trabajar con estas personas.

Cuando resolvimos con colegas, estamos esperando a otra bestia codiciosa.

Pelea con el coche

Este es el truco del código llamado producto. Empecemos con lo básico.

Desmontar la basura. Es necesario realizar pruebas para que con un impacto mínimo en el sistema se obtenga un resultado verificable. Pero cualquier sistema heredado está lleno de datos: se han agregado durante años desde el lanzamiento y afectan el comportamiento del sistema. Por lo tanto, es necesario probar "desde cero".

Prepare un "sistema esférico en el vacío": vacíe las fuentes de datos, realice las configuraciones mínimas que inicia el sistema, apague todos los posibles "hacks" y "características". Haga que el sistema se inicie. Si se inicia, tiene el conjunto mínimo de datos necesario para funcionar. Este ya es un buen punto de partida: una "pizarra limpia".

Usando algunos efectos medibles, por ejemplo, presionando un botón determinado, obtendrá un resultado de trabajo medible. Con esto, puede continuar con el siguiente paso.

Desentrañar los datos. Cualquier proyecto heredado funciona según el principio de "debe entregarse ayer". Todo lo que fuiste a la universidad o leíste en libros no funciona aquí. Cuando comience a probar, encontrará, por ejemplo, una dependencia cíclica, imposible de recrear en el programa, pero necesaria para funcionar.

Comience con el "objeto principal". Para lidiar con el bosque de dependencia, trate de pensar qué objeto es el principal. Por ejemplo, para el sistema de contabilidad de almacén, el objeto principal es la "caja". Un objeto "estante" está asociado con él, y un objeto "fila" está asociado con un "estante".

Recrea el mínimo requerido.Si observa los enlaces entre los objetos y profundiza en el árbol de dependencias, puede determinar el mínimo necesario de datos para los objetos dependientes. Debe volver a crearlo para que el sistema funcione y pueda funcionar para probar su funcionalidad.

No tengas miedo de cambiar los enlaces. Puede que tenga que arremangarse y sumergirse profundamente en este desastre: eliminar y cambiar enlaces, cambiar la estructura de la base de datos. Has venido a mejorar el sistema, así que no tengas miedo de hacer cambios.

Pasamos a las pruebas. Para confundir productos viejos, una buena estrategia son las pruebas de humo.

Pruebas de humo

El concepto de "prueba de humo" nos llegó del mundo de la electrónica. Un ingeniero montó un circuito gigante con un montón de bombillas y cables. Pero antes de comenzar a probar, simplemente conecté el circuito a una toma de corriente. Si el humo comenzó, entonces algo salió mal.

En los sistemas de información, el concepto de pruebas de humo es bastante simple. Imagine un servicio web, tiene un punto final. Intentemos enviarle una solicitud GET sin parámetros. Si por alguna razón el producto se rompió repentinamente (error 500), entonces algo salió mal.

La prueba de humo es un buen comienzo . Esta es una prueba que prueba algunas funcionalidades y deja en claro que el sistema funciona o está dañado. Incluso una simple solicitud al punto final más simple ya afecta a más del 1% del código. Con pruebas tan pequeñas, estamos preparando un trampolín para realizar más pruebas.

La prueba de humo revela muchos problemas. Es posible que durante todo el período de funcionamiento del servicio nadie haya intentado enviar una solicitud sin parámetros.

Use esta táctica para cubrir varios puntos de entrada principales en su programa: formulario de ingreso de usuario / contraseña, servicios web básicos, botones. Esto es algo que ya puede mostrar al gerente y sus colegas.

Pruebas de funcionamiento

Estas no son pruebas de clases individuales o un método, sino el nivel más alto posible de probar una cierta parte de lo funcional.

Imagine la funcionalidad para "generar un informe en el servicio". En lugar de verificar partes individuales, probamos la situación de la solicitud para crear un informe con ciertos parámetros y obtener un archivo de datos. No es necesario conocer el mecanismo para generar el informe, pero si el servicio proporciona ciertos datos de salida con ciertos datos de entrada, entonces este recuadro negro con cierta probabilidad funciona como debería.

La cobertura de la funcionalidad principal con tales pruebas le permite comenzar rápidamente y cubre de inmediato áreas extensas. Estarás seguro de que el código funciona al menos aproximadamente como lo imaginas, gana más confianza, llena tu mano y revela aún más problemas.

Las pruebas funcionales son un medio, no un fin.

Es fácil engancharse con la aguja de prueba funcional: "¡Estoy probando la funcionalidad real! Esto es a lo que se enfrentan los usuarios ".

Una prueba funcional involucra grandes porciones de código que pueden interactuar con cantidades gigantescas de datos. Por lo tanto, 3-4 pruebas funcionales son buenas, 10 son peores y miles de pruebas que toman 9 horas son demasiado. Lamentablemente, esto también sucede.

Después de las pruebas funcionales, realice pruebas unitarias. Pero no voy a hablar de ellos, ya lo sabes todo.

Revisamos los conceptos básicos de las pruebas de máquinas y volvimos al tema principal. Los colegas y el gerente no son el peor enemigo en una batalla con el legado. El peor enemigo eres tú mismo.

Pelear con uno mismo

Prepárese para el hecho de que el camino parecerá interminable . Trabajar durante una semana en su plan llevará seis meses sin la posibilidad de completar el proyecto.

La resistencia es inevitable . Todos los aliados eventualmente comenzarán a dudar, intentarán desviarse, persuadirlos para que abandonen las pruebas y pasen a las funciones. Prepárate para esto. Recuerde a todos por qué se involucró en todo esto, cuánto esfuerzo y tiempo se invirtió. Argumento débil, pero podría funcionar.

Nadie garantiza el éxito . Incluso si muestras esfuerzos heroicos, ponte a trabajar, tu proyecto aún puede agotarse y la cruzada con las pruebas terminará en nada.

Esto es normal, este no es el final de la vida y la carrera. Esto ni siquiera es una confirmación de que eres un mal profesional. La única conclusión aquí es que este proyecto en particular falló.

Pero entonces tienes experiencia y conocimiento. La próxima vez, cuando tomes una nueva lanza en tu mano y tu caballo acelere a otro molino de viento, también estarás listo para romper esta lanza, pero más tarde, con un método diferente y con menos daño.

Ahora ofensivo, amargo y eterno.

Palabras de despedida

No tengas miedo de los comentarios. Tuve que entrar en esta trampa y ver cómo otros caen en ella. Hice algo y hice alarde de mis colegas: "¡Lo hice!" Pero de repente resulta que mi mecanismo conveniente es inconveniente para los colegas, y no pregunté.

Escribe pruebas, prueba lo que implementas . A menudo, la introducción de un nuevo marco de prueba es fascinante, pero usted no escribe las pruebas en sí. Entonces puede suceder que tan pronto como los escriba, comprenderá que no puede usar las pruebas. Quizás los colegas también vean esto, pero guarden silencio o simplemente no escriban pruebas.

Ayuda a colegas con problemasincluso si no lo piden. La ayuda no significa asumir todo el trabajo en sí mismo: relaja a los colegas y los alivia de la responsabilidad, y el número del "autobús" cae a la unidad. Luego te conviertes en un probador humano: algo se rompió, CI rojo, guía de prueba. Ayuda en el marco de lo razonable.

El número del "autobús" no es una broma. No siempre puede arrastrar el proyecto sobre usted mismo. Todos pueden agotarse, irse de vacaciones o renunciar. Por lo tanto, transmita a sus colegas su conocimiento y responsabilidad, que es necesario para hacer frente sin usted. Esto ayudará a evitar llamadas desagradables cuando te relajes en la playa, y CI vuelva a estar rojo.

Mejorar los mecanismos de prueba. Se pueden evitar muchos problemas simplemente porque las pruebas lentas de repente se vuelven rápidas. Anteriormente, ocupaban 20 líneas de código, pero ahora una. No se dio cuenta de esto, porque una vez que escribió algo y se olvidó: "Funciona, ¡no lo toque!" Pero esta regla no siempre es aplicable.

No eres el centro del universo. Nuevamente, repito que el número del "autobús" no es una broma. Más de una vez me encontré con una situación en la que una persona comenzó a probar, y luego recibió una oferta para el proyecto más fresca: dejó todo, se escapó, pero no dejó comentarios y documentación. Todo funciona hasta una nueva confirmación, pero es imposible solucionarlo; nadie comprende cómo funciona todo.

No quiero que seas esta persona. No se convierta en un factor limitante.

Escribe la documentación.
Realizar entrenamientos.
Comparte tu experiencia.

Cuando todos los colegas estén al mismo nivel que usted (más o menos), el proceso pasará de una carrera de una persona a una carrera de relevos de equipo con el paso de la bandera. Solo con el apoyo de sus colegas tendrá éxito. Si está solo en el proyecto, piense que alguien más después de usted también sufrirá solo. Dale a tu seguidor un amigo en forma de documentación, no dejes morir solo.

27 Moscow Python Conf++ Python 2 Python 3 — 2020 .

, (fb, vk, twitter) telegram- . !

Domar a la bestia: código heredado, pruebas y tú