Síndrome de fontanería: reglas de código heredadas para pruebas

Muchos se encontraron con un recién llegado que vino al proyecto y declararon que "todo debe rehacerse urgentemente". Y algunos mismos dijeron o pensaron. Este es el "síndrome de fontanería": comportamiento caracterizado por el deseo de hacer todo a su manera, "correctamente", cuando se trabaja en un nuevo proyecto o cuando se cambia a un nuevo trabajo. Por lo tanto, el código, las tecnologías o las herramientas existentes deben reescribirse, preferiblemente "por sí mismos". El tema sería común si no se repitiera tan a menudo de un proyecto a otro, con cada nuevo reclutamiento.

Cuanto más "viva" el proyecto, más se acumula un código heredado "histórico" y mayores son las posibilidades de encontrar los ojos ardientes de un fontanero afectado por el "síndrome". En esta publicación, me gustaría decirle a qué principios se adhiere Parallels (inmediatamente, el spoiler es el principio de "no hacer daño"), y qué hacemos si decidimos "rehacer todo" después de todo. Aunque en general creemos que este síndrome debe tratarse, y que el uso del legado a veces es incluso útil, ya que le permite lanzar el producto a tiempo y no perder el tiempo desarrollando sus tecnologías.

Cuando trabaja con "programas de larga duración", un porcentaje lo suficientemente grande en ellos es el código heredado. Por ejemplo, Parallels Desktop lleva más de 15 años en desarrollo. Cada año, el equipo se expande, llega gente nueva, mira lo que está escrito y declara: "Todo está torcido, arranquemos las manos del programador y reescribamos todo". ¿Una situación familiar?

Antes de comenzar a decir si el código heredado es bueno o malo, me gustaría decidir sobre los conceptos de quién entiende esto y qué. Usualmente se usan dos definiciones: la primera es el código que no está cubierto por las pruebas. Desde el punto de vista de las pruebas automáticas, todo el código no está cubierto por las pruebas. El segundo código heredado es el código que heredó. Cuando necesitas entender cómo funciona, pero nadie a quien preguntar. Y tienes que molestarte tú mismo.

Sabiduría potenciada

I. Lo mejor es enemigo de lo bueno. Si el código o sistema heredado realiza todas las funciones necesarias con una calidad aceptable, entonces no necesita mejorarlo, es mejor dirigir su energía hirviendo a algo más útil.

II De lo importante y lo nuevo, elija lo importante, de lo igual elija lo nuevo. Si el código heredado contiene una funcionalidad importante y no está cubierto por las pruebas, debe prestarle la máxima atención, tanto en términos de procesamiento del código como en términos de cubrirlo con pruebas. Si el código heredado y las nuevas funciones tienen la misma importancia, entonces debe centrarse en las nuevas funciones (desarrollo y pruebas).

III. Si lo viejo no es susceptible de mejora, construya uno nuevo cerca, luego descarte el viejo. Si el código heredado es necesario pero imposible de cambiar, use el código anterior hasta que escriba y depure el nuevo. Cuando el nuevo código funciona, se puede tirar el antiguo.

Que hacer

Paso 1. Miramos quien dijo
1. Profesional independiente . Muy a menudo, las personas que no tienen experiencia en unirse a un gran proyecto desde el costado rehacen completamente el código. Por ejemplo, yo mismo trabajé por primera vez en freelance, escribí proyectos desde cero y, como muchos desarrolladores similares, desarrollé un hábito bastante estable: hacer exactamente lo que me siento cómodo.

2. Sin experiencia . A veces, tales declaraciones indican una falta de calificación de la persona misma en el área temática: no conoce la historia del proyecto y, por ejemplo, que esta construcción "terrible" (en su opinión) fue el resultado de personas que tropezaron con errores externos en el proceso de desarrollo sistemas y comenzó a sortearlos. Como resultado, había una especie de espagueti de parches y muletas interconectados para estos errores. Tal conocimiento de todas las trampas existentes en los humanos desde el exterior no puede ser en principio.

3. D'Artagnan . En la mayoría de los casos, esto sucede con ingenieros que no tienen experiencia en productos y experiencia en grandes proyectos que no entienden el precio que obtienen. Un hombre golpea su pecho con el talón y dice que lo hará de manera brillante, fresca y en solo una semana, pero puede estar profundamente equivocado acerca de sus habilidades y porque pierde por completo puntos como las pruebas y la integración en el sistema más grande existente.

4. Especialista altamente calificado. El único tipo de "solicitantes" que debe escuchar, aunque se apresura a rehacer su consejo, todavía no vale la pena hasta que se complete el Paso 2. Es posible que tengamos un profesional de primera clase y él realmente pueda demostrar que no lo hacemos. Entonces, y puede hacerlo mejor. Pero el hecho es que no he conocido a una sola persona de nivel Senior con tales declaraciones. Cuando una persona crece a tal nivel, ya puede imaginar el proyecto como un todo y comprende todas las deficiencias del método "revolucionario".

Paso 2. Hacer argumento
Lo primero que una persona necesita para detenerse y analizar sus argumentos. Esta prueba debe ser iniciada por el líder del equipo. Con la advertencia de que el "síndrome de plomería" no comenzó a sufrir a una persona que él mismo llegó a liderar el equipo. Luego, el análisis del vuelo es el trabajo del gerente del proyecto, aunque, francamente, un líder de equipo maduro nunca inicia una alteración completa sin una argumentación seria.

Qué argumentos fallarán:
“Escribiremos el nuestro, con ajedrez y poetas”
Muy a menudo, si un producto ha estado en el mercado durante mucho tiempo, entonces ya funciona de alguna manera. Él ya ha demostrado que, a pesar de la naturaleza terrible de lo que está debajo del capó, está funcionando. Por ejemplo, tenemos Parallels Desktop (una solución para ejecutar Windows y otros sistemas operativos en una Mac sin reiniciar), y a veces puedes escuchar a los principiantes: "de alguna manera, aquí eres demasiado complicado, escribamos mi máquina virtual". Y dado que tales cosas, en principio, no se pueden hacer de inmediato, cuando una persona dice esto, está fuera de tema o no está solo. Es necesario darle la primera experiencia en el proyecto y comprender por qué se implementó desde el principio.

"Es feo".
El problema es que a menudo una persona no tiene otros argumentos. "No tecnológicamente avanzado", "hecho en un poco de basura", "por qué está escrito en C, ahora está de moda escribir en Go". Estos no son argumentos para rehacer el sistema. Porque cuando va más allá de su código único, comienza a darse cuenta de que su retrabajo puede ser peor de lo que era antes. Puede parecer más bonito por dentro y trabajar más lentamente, lo cual es inaceptable para el producto. No vi esto en Parallels, pero en la compañía anterior tuvimos que experimentar completamente todas las consecuencias de este paso. Decidimos que una familia de controladores para ciertos equipos se implementaba feamente, y necesitábamos un diseño más elegante y extendido que fuera más fácil de mantener y agregarle nuevas características. Escribieron nuevos y hermosos durante un año y medio, pero al final resultó igual de horrible y no dio ninguna ventaja. Y el costo de los recursos resultó ser muy grande: dos desarrolladores engullieron una empresa y medio año de trabajo.

Por qué es mejor no tocar el código a largo plazo de un proyecto grande

Incluso puedes matar tu proyecto
¿Dónde está la garantía de que volverás a escribir algo y funcionará correctamente? Después de todo, esto aún no es así. Desde el punto de vista comercial, debe vivir en la actualidad y garantizar la continuidad de la generación de ingresos.

Puedes romper muletas
En cualquier proyecto, existe algo como kludge (mejor conocido como "muleta") y muchas cosas indocumentadas. Sí, existe una metodología de desarrollo de este tipo, cuando la documentación se escribe por primera vez, y luego el desarrollo es estrictamente seguido por ella, pero aún se mostró en los años 90 como demasiado inercial para las tareas comerciales. Tal vez de esta manera pueda hacer un cohete, es decir, en procesos donde el desarrollo ha estado ocurriendo durante varias décadas, esto está justificado, ya que existen grandes riesgos de desviaciones. E incluso allí tienes que hacer algunos cambios sobre la marcha.

Y desde el punto de vista del desarrollo comercial de software, no hay tanto tiempo para tener primero todo en cuenta en la documentación y luego hacerlo. Y resulta que todos los productos tienen una gran cantidad de datos sin decir. Al encontrarse con algún tipo de problema ambiental, por ejemplo, un poco de hierro funcionó para evitar la especificación, hizo una ronda de trabajo para ello. En muchos casos, si fue un cambio relativamente menor, a menudo se olvida y no se refleja en la documentación. Simplemente está encajado en el código, y con mayor frecuencia, desafortunadamente con algún tipo de comentario sensato.

Y comienza: arrojemos todas estas muletas, ya que no está claro que estropee el código. Y no piensan a lo que les llevará. Por ejemplo, cuando hicimos uno de nuestros parches para el kernel de Linux, entonces en un lugar golpeó una muleta: era muy feo y al mismo tiempo bastante mal descrito. Y luego, en la discusión, aprendieron: ciertos equipos sin este almacén no funcionan. Sí, ya no se produce, pero los usuarios todavía lo tienen y funciona. Y la pérdida de soporte para este hardware va en contra de la filosofía de la comunidad Linux. Tuve que volver a escribir nuestro código para que esta solución se conservara uno a uno, y luego todos quedaron satisfechos.

Puedes desperdiciar recursos
Un ejemplo de tal desperdicio de recursos se da arriba. Debe entenderse que cualquier revolución conduce a una guerra civil, a un cierto período con un deterioro en el estado de cosas, en el que nada funcionará.

Puedes perder el iniciador y el proyecto
El síndrome de fontanería afecta principalmente a los nuevos empleados. Vale la pena recordar que esas personas están en riesgo porque pueden abandonar la empresa durante el período de prueba (no es por nada que dicen que el período de prueba no es solo para la persona, sino también para la empresa). Al hombre le dieron carta blanca, comenzó a rehacerla, y luego declaró que no le gustaba el café en la compañía y se fue. Esta es una situación muy peligrosa. Resulta que no hay nada nuevo, pero lo viejo ya está roto. Entonces alguien (y de ninguna manera un entusiasta) tendrá que ponerlo en forma de trabajo.

¿Qué hacer cuando la decisión de no rehacer la decisión es obvia y la persona está "ardiendo con una idea"?

Permitir tiempo para refrescarse y pensar
Solo necesita dar tiempo a la persona que vino a un gran proyecto existente para conocerse mejor. Para cuando una idea proviene de una persona que ha estado trabajando durante mucho tiempo en una empresa y específicamente con este producto, sus iniciativas se tomarán mucho más en serio y serán analizadas por sus argumentos. Debe explicarle que no debe tirar en un área con la que aún no está suficientemente familiarizado y no conoce la situación actual. Es dudoso que una persona que acaba de llegar, después de haber leído el código, pueda explicar razonablemente por qué todo está mal y por qué debe cambiarse.

Si una persona rechaza tal rechazo u ofrece mucho, entonces esta es una ocasión para tomar nota de que, tal vez, este desarrollador no está listo para trabajar en un equipo y pueden surgir dificultades de comunicación con él (y este es un factor muy importante para nosotros). Desde entonces, el líder del equipo tendrá que trabajar por separado, en "modo manual". Tal vez esa persona debería reconsiderar sus puntos de vista sobre su carrera y entrar en forma independiente, donde puede hacer todo "según sea necesario".

Dirige su energía en una dirección diferente
La mayoría de los productos grandes siempre tienen algunos cuellos de botella y problemas que surgen regularmente, ya que todo cambia fuera. Aunque, en mi opinión, sigue siendo muy peligroso dejar que una nueva persona vaya al código hasta que trabaje durante un par de meses para depurar pequeños errores, conozca el código existente y demuestre su nivel de habilidad.
Es posible asignarle una tarea de algunos proyectos paralelos, para que pueda poner sus cosas nuevas allí y ver qué pasa. Esto se estipula que existen tales espacios en los recursos, ya que hay un número limitado de tareas, aquí, como en un negocio de riesgo, invertí en 100 empresas y recibí ganancias en una.

Cuando todavía necesitas rehacer

El producto muere bajo las condiciones existentes.
El argumento para rehacer: si el entorno externo ha cambiado tanto que el producto existente ha dejado de funcionar. Por ejemplo, cuando lanzaron un nuevo sistema operativo, los usuarios comenzaron a cambiar en grandes cantidades, pero en este sistema operativo algo cambió para que su producto, que funcionaba normalmente en versiones anteriores, dejara de funcionar o se volviera completamente inconveniente para el usuario usarlo. O cuando la plataforma muere, por ejemplo, de una antigua, puedes citar BeOS, bajo la cual trabajaron bastante con productos multimedia, por ejemplo, música compuesta. El sistema murió y, dado que era bastante distintivo, sus códigos prácticamente no se transfirieron a otros sistemas. Con el sistema operativo BeOS en sí, sucedió lo mismo: había computadoras Atom a las que apuntaban, y luego el fabricante dejó de lanzar estos procesadores, y las personas que escribieron para esta computadora prácticamente se quedaron sin nada. Y se vieron obligados a adaptarse urgentemente a Intel, lo que resultó mal para ellos: el nicho estaba ocupado y otro sistema operativo reinaba allí. Y para prolongar al menos de alguna manera su vida, tuvieron que rehacerlo seriamente para mejorar la portabilidad, etc.

Síndrome de fontanería trabajado: etapas de remodelación

Es necesario hacerlo evolutivamente y en paralelo, sin romper el sistema. El proceso y las etapas de la alteración dependen de si estamos cambiando todo el producto en su conjunto o una parte significativa de este. Si todo el producto, este es en realidad el comienzo de un nuevo proyecto desde cero. Pero en la mayoría de los casos, todavía cambian de parte, ya que en el primer caso pasará más de un año antes de que la nueva base de código gane estabilidad y cumpla con las cualidades del consumidor para satisfacer al menos el nivel que tenía.

Si reemplaza el componente, entonces es aconsejable hacerlo: si la interfaz externa no requiere un cambio, entonces silenciosamente hacemos la segunda implementación. Es aconsejable encontrar inmediatamente las líneas divisorias: aquí queda lo viejo, pero aquí ya es posible rehacer, encontrar puntos de entrada. Y así, manteniendo la interfaz, cambie el relleno.

Es como con un automóvil, en el que decidieron reemplazar el motor de gasolina con un motor eléctrico. Para el usuario, poco ha cambiado: el mismo cuerpo, las cuatro ruedas y el volante permanecen. Y debajo del capó, todo lo demás puede ser.

Si logras encontrar un punto de división de este tipo, entonces puedes rehacer evolutivamente y cualquiera que se encuentre en ese punto de división puede que ni siquiera note los cambios (excepto, con suerte, una mejor calidad de trabajo). Y luego, en el proceso de prueba interna, cambie y guarde el producto. Desafortunadamente, esto está lejos de ser siempre posible, y luego la alteración puede conducir al desastre.

O esta opción: la interfaz es fija, la implementación se realiza y luego la interfaz comienza a cambiar de forma iterativa.

Tiene sentido comenzar una alteración grave en las ramas laterales y hasta que tenga un aspecto final, no se integra en el producto principal. Incluso con respecto a los subsistemas, es peor si con este nombre comenzamos a hacer algo completamente nuevo y el equipo se separó, entonces no hay ningún producto.

En lugar de una conclusión

Un niño nació con una nuez en lugar de un ombligo. Y periódicamente preguntaba a sus padres por qué tenía una nuez allí. Los padres prometieron contarle sobre esto en su cumpleaños número 14. El chico cumplió 14. Y luego volvió a hablar con su padre y su madre y le preguntó por qué tenía una nuez en lugar de un ombligo. Los padres prometieron contarle al respecto cuando tenga 18 años. A los 18 años, volvió a preguntar, y luego le dijeron que hay una isla tropical en la que crece una palmera, y debajo de esta palmera está enterrado un tronco. Hay respuestas a todas sus preguntas. El tipo ahorró dinero durante mucho tiempo y aún se envenenó en esta isla. Encontré una palmera, saqué un cofre en el que había una llave inglesa. Sin dudarlo, desenroscó la tuerca con la llave encontrada y su culo se cayó. Moraleja: a veces no es necesario buscar aventuras en el quinto punto.