Muchos proyectos con los que trabajé, grandes proyectos, se convirtieron en legado, desenredando barbas, y como resultado, el desarrollo se volvió extremadamente difícil. Hubo casos en los que los proyectos simplemente murieron debido a la dificultad infernal de hacer cambios. Hoy les contaré sobre mi experiencia trabajando con proyectos, y por qué les escribo todo esto. Todo es muy subjetivo, por supuesto.
Entonces, trabajé e intenté, como un marinero que quiere rastrillar el agua y evitar que el barco se hunda, pero la calidad del proyecto disminuyó constantemente y hubo varias razones.
Los reconocerás fácilmente, son pacientes habituales, solo te recordaré sobre ellos:
- La arquitectura es escasa, es difícil implementar una nueva solución
- Errores de codificación
- No hay pruebas automáticas
Como resultado, de acuerdo con los resultados del desarrollo del proyecto durante los primeros 1-2 años, se obtiene una mezcla de legado, código de mierda, túneles enredados con pasajes secretos y pinturas rupestres ala "obras así, por qué no lo sé".
No me detengo mucho en esto, este es el tema # 1 en refactorización, tan directo a las conclusiones que saqué.
El producto desarrollado es una experiencia colectiva
Si el equipo tiene 1 megadesarrollador, realmente entusiasmado, funciona bien, entonces no lo arreglará solo, porque el equipo comete errores constantemente e invariablemente arrastrará el proyecto hacia abajo.
Por supuesto, puede intentar darle al equipo actual una tarea de refactorización, y luego los que lo soldaron rehacerán su propio resultado de trabajo y darán lo mismo, bueno, tal vez un poco mejor que la primera vez.
Por lo tanto, no debe esperar una mejora de calidad radical sin una mejora de equipo.
Este es un círculo vicioso número 1: la experiencia del equipo no es suficiente, pero comienza la refactorización y, atención, los mismos posons que lo escribieron lo hacen.
Alternativamente, puedes poner un buen lead que realizará una revisión y limpiará estos errores (aunque intentará hacerlo), pero al final terminará con un dolor de cabeza para los que trabajan mal, y luego o el reemplazo de los desarrolladores, o ellos mismos se irán, y, nuevamente. reemplazará a los desarrolladores.
Será una especie de selección natural en el proyecto.
La gente tiene miedo de cambiar el código.
Bienvenido, esta es una sesión de psicología para programadores.
Los programadores tienen mucho miedo de cambiar el código y se les puede entender:
- No hay suficientes pruebas o no
- No está claro cómo funciona el código
- Las fechas son en
- Sin recursos
- La gerencia no lo entenderá (normal, pero si la gerencia está en llamas, todo estará bien)
Como resultado, el antiguo y confuso código heredado que arrastra el proyecto hacia abajo se percibe como "es mejor no tocar" y, como resultado, este "no tocar" dura para siempre y, lo que es peor, te obliga a escribir código de cierta manera, lo que provoca otros problemas técnicos que luego también derriban el proyecto.
Tomamos un proyecto, un código de mierda, los miedos de un equipo, lo multiplicamos por el tiempo y obtenemos una enorme deuda técnica, que sube de lleno y no permite que el equipo se mueva y desarrolle el proyecto normalmente rápidamente.
El proyecto comienza a desmoronarse, los plazos se interrumpen, las nuevas funciones se vuelven tremendamente más caras para el proyecto, los desarrolladores comienzan a ponerse nerviosos, algunos se van, las nuevas son más difíciles de encontrar, entiendes la idea ...
Entonces, creo que este es el problema n. ° 1, el miedo al código y los riesgos.
Por experiencia, se ha notado que si deja una deuda técnica, entonces esto es una bomba potencial, o al menos una comisión. Déjalos 100, 1000 y obtendrás un campo minado, en el que no solo vas (desarrolla el proyecto), no puedes arrastrarte.
Por lo tanto, la única forma de ahorrar la velocidad promedio de desarrollo del proyecto y no reducir la calidad es, gracias al límite, prestar atención a la calidad, refactorizar.
El incendio del consejo, todo el mundo lo sabe, pero de hecho la lista anterior no ha ido a ninguna parte, por lo que no puede simplemente tomarla y refactorizarla, porque obtendrá un proyecto que se está desmoronando, ¿y por qué?
Debido a que no hay pruebas, no está claro cómo funciona el código y, como resultado, en lugar de cambiar los dibujos y el ensamblaje del automóvil, resulta que Vasya y Petya tomaron un molinillo, cortaron Solaris y lo devolvieron a Tavria, pero no funciona. ¿Por qué? - oh, pero como no sabíamos acerca de esa influencia / comportamiento / tareas
Sí, puede refactorizar sin pruebas y luego estabilizar, pero muchos scripts de usuario o scripts de ejecución de código necesarios pueden perderse, o la estabilización puede llevar mucho tiempo.
Por lo tanto, un círculo vicioso más: no puede dejar el código solo, pero tampoco puede refactorizarlo, por así decirlo, porque existen grandes riesgos.
Resulta que no necesitamos Legacy, pero deshacerse de él da miedo y es peligroso, por lo que los equipos a menudo dejan Legacy como la "opción menos peligrosa" para obtener una solución aún más peligrosa para el proyecto más adelante.
Las pruebas son la clave
Resulta que para desbloquear la refactorización y hacerlo seguro, primero debe cubrir todos los casos con pruebas, y luego, cuando cortamos nuestro Solaris y lo ensamblamos en Tavria, la soldadura se detendrá y dirá "Hola, necesitamos un Solaris, te equivocaste aquí".
Las pruebas le permiten evitar errores durante la refactorización, es decir para hacerlo seguro, y luego puede cortar el proyecto como desee y necesite sin el miedo mismo de que los riesgos funcionen y haya problemas.
Por lo tanto, obtenemos una cadena:
Pruebas -> Refactorización -> Adiós barba y legado.
Suena simple, hermoso, pero en la práctica hay pocas pruebas. O no sucede en absoluto, y hay varias razones para esto, como de costumbre:
- Los desarrolladores consideran que las pruebas son un tema separado y no invierten en evaluaciones; escriben por separado del desarrollo. Es aún más difícil si la dirección del proyecto así lo cree y quiere recortar las pruebas para cumplir con los plazos.
- Las pruebas son tiempo, y el proyecto debe entregarse ahora, no hay tiempo para escribir pruebas para nosotros (en teoría, esto es lo mismo que el punto número 1)
- El proyecto / componente es simple, ¿por qué hay pruebas, todo es extremadamente simple y funciona allí?
- Primero escribiremos el código, luego lo cubriremos con pruebas. Pero no, no lo entendimos, el proyecto no se detuvo, no hubo tiempo. Así que esta tarea queda en la caja negra para siempre.
En realidad, hay un millón de razones, pero el hecho es que bloquea la refactorización y, como resultado, no permite que la calidad crezca.
Por lo tanto, las pruebas son una tarea crítica y, sin ellas, el desarrollo de alta calidad a largo plazo del proyecto será significativamente difícil, si no imposible.
¿Qué hacer, Houston?
Estoy escribiendo este artículo solo porque no todos entienden esto, y al menos hay alguien que lo leerá y querrá escribir pruebas, refactorizar, lo que significa que escribí este artículo por una razón.
Entonces, la tarea de todos: tome un módulo, componente, algo mal escrito, encuentre allí que le gustaría refactorizar, escriba pruebas para este módulo o componente y refactorice.
Como resultado, comprenderá que las pruebas son:
- Una forma de aprender código. Incluso puede ser mucho más eficiente que simplemente leerlo.
- Estabilidad
- El código antiguo realmente se puede refactorizar y la calidad del proyecto se puede mejorar
Escribí todo de una vez, de manera muy subjetiva, y tal vez me equivoque, esta es solo mi experiencia. Tal vez acabo de encontrarme con proyectos de este tipo, no lo sé, pero la información sigue siendo útil, y si estás pensando después de leerlo, esto también es bueno.
Les deseo a todos un buen código, pruebas y movimiento de calidad; por eso nos contratan, trabajemos bien.
PD Si lo desea, escriba su experiencia de refactorización en los comentarios, todos estarán interesados.