Notas Técnicas de Deuda

1. Notas técnicas de deuda

1.1 ¿Qué es la deuda técnica?

En 1992, Ward Cunningham propuso por primera vez el concepto de "deuda técnica" en el Manifiesto Ágil, que se refiere principalmente a la deuda acumulada al tomar decisiones técnicas incorrectas o subóptimas de forma intencionada o no. Posteriormente, Martin Fowler, autor de "Refactoring", creó "cuatro cuadrantes de deuda técnica" basándose en la metáfora de Cunningham, que incluyen:

• Imprudente/intencional: “No tenemos tiempo para diseñar”;
• Cauteloso/Intencional: “Tenemos que cumplir ahora y afrontar las consecuencias de buscar velocidad más adelante”;
• Imprudente/involuntario: "¿Qué son las capas?";
• Cauteloso/Involuntario: “Ahora sabemos qué hacer”.

1.2 Discusión

Hace algún tiempo, el tema de la deuda técnica en Reddit volvió a generar un amplio debate entre los programadores. El usuario spo81rtyOP dijo: " La vida útil real de la mayoría del software es de sólo 5 a 10 años. Incluso si el software sobrevive, el hecho de que esté escrito enteramente a partir de una pila de tecnología obsoleta limitará su camino. Esta es la vida de un ingeniero de software. El verdadero destino. "

Al mismo tiempo, en los últimos 20 años, muchos lenguajes de programación también han "caído en desgracia", como Perl, Delphi, Fortran, FoxPro y ColdFusion. Quizás estos lenguajes de programación antiguos todavía existan en algunas aplicaciones, pero en la mayoría de los casos, las empresas que todavía usan estos lenguajes de programación tienen que modernizar y retirar las aplicaciones antiguas. Si crea un programa en estos lenguajes de programación obsoletos, puede terminar reescribiéndolo porque ya es difícil encontrar programadores que utilicen estos lenguajes.

A principios de la década de 2000, la gente pensaba que Adobe ColdFusion era el producto más popular, pero ¿qué pasa hoy? Ruby on Rails también puede seguir el camino de Adobe ColdFusion, que ha caído en desgracia y está teniendo dificultades para encontrar desarrolladores que lo utilicen . Lo que alguna vez fue exclusivo de Ruby on Rails ahora está disponible en otros idiomas.

Los lenguajes de programación van y vienen, y los desarrolladores no quieren aprender habilidades que no necesitan en el trabajo , dijo Watson . Al mismo tiempo, los desarrolladores pasan rápidamente de un trabajo a otro, siempre con la esperanza de tener algo nuevo e interesante en su currículum.

Watson predice que WebAssembly eventualmente superará el desarrollo front-end actual y un mundo completamente nuevo seguirá evolucionando.

El usuario chesterriley imaginó una posibilidad extrema: tal vez algún día en el futuro, la gente siga usando código escrito hace 100 años. El gran ganador puede ser algo así como una utilidad Unix o un código TCP/IP , o algún compilador, motor de ejecución o intérprete . También hay código de sistemas operativos como Linux o Windows . Las personas pueden descubrir repentinamente que el error que solucionaron en realidad data de hace más de 100 años.

Por supuesto, hay algunos códigos que realmente no se ven afectados por el revuelo actual. Curiosamente, la mayor parte de este tipo de código se concentra en el lado del servidor . Aunque siempre hay fuerzas poderosas que "subvierten" la forma en que se construyen servicios como los microservicios y las funciones Lambda, si se ignoran estos detalles de implementación, definitivamente todavía habrá servicios db+ ejecutándose en el espacio de memoria del servidor, y todavía habrá ciclos inactivos que no se utilizan. .

" Espero que los nuevos proyectos que nacen hoy tengan en cuenta la importancia de la mantenibilidad a largo plazo e incluso lo consideren como una premisa de diseño básica. Después de todo, en realidad no hay mucha gente que tenga la capacidad de mantener proyectos de software antiguos. Incluso "Aunque la población de la Tierra todavía ha aumentado, el número de desarrolladores con habilidades suficientes para mantener este software antiguo nunca ha podido mantenerse al día " .

1.3 ¿Qué piensan los profesionales de la tecnología nacional?

Liu Yijing, CTO de Percent, cree que la clave para juzgar la deuda técnica es "lo que se debe hacer", un proceso que varía de una organización a otra, de un proyecto a otro y de una persona a otra, como los siguientes aspectos:

• Lo que la organización requiere pero no hace: sistemas, procesos, normas, aprendizaje compartido, etc.;
• Cosas que el negocio y la tecnología requieren pero que no se han hecho: funciones, rendimiento, seguridad, alta disponibilidad, expansión, monitoreo, herramientas auxiliares, etc.

Si se clasifica según los vínculos de la ingeniería de software, la deuda técnica se puede dividir en: análisis de requisitos, diseño de soluciones, diseño de arquitectura (arquitectura lógica, arquitectura funcional, arquitectura de datos, arquitectura de implementación, arquitectura de operación, etc.), codificación, pruebas, lanzamiento, etc. . Si se divide según el tipo de salida, se puede dividir en:

• Categoría de documento: documentos de procesos de gestión, documentos de análisis de requisitos, documentos de diseño, documentos de casos de prueba, etc.;
• Categoría de código: código, scripts, especificaciones, etc.;
• Categoría de paquete de software: paquete de software del producto, software dependiente, recursos dependientes, etc.;
• Categoría de entorno: entorno de desarrollo, entorno de prueba, entorno de prelanzamiento, entorno de producción, etc.

En cuanto a cómo decidir si reescribir o continuar manteniendo, es necesario juzgar si el "beneficio del mantenimiento continuo" o el "beneficio de reescribir" es mayor para decidir si continuar manteniendo o reescribir. Los beneficios de los siguientes aspectos se pueden considerar de manera integral:

• Código abierto: aumentar los ingresos comerciales existentes y apoyar el desarrollo de nuevos negocios;
• Ahorros: Ahorre personal de mantenimiento y gastos operativos;
• Organización: ajuste de la estructura de personal y desarrollo de capacidades organizativas.

La deuda es inevitable: siempre juzgue el "valor de tener deuda" y trátela lo antes posible cuando el valor sea muy bajo.

El director de I + D de Tencent, Wang Hui, dijo que si los recursos como la mano de obra, los recursos materiales y el tiempo de construcción son abundantes, cualquier cosa que pueda optimizarse se puede lograr hasta el extremo. Pero, por lo general, los recursos no son abundantes o son escasos, por lo que depende de la situación empresarial real. El enfoque constante de Tencent es "resistir primero y luego optimizar", si el proyecto realmente ha llegado al punto en el que la optimización es necesaria y si realmente ha llegado al punto en el que puede caer en cualquier momento si no se optimiza. Si resiste primero, esperará hasta que la empresa se apodere del mercado. Después de que los usuarios hayan ganado tracción y después de que el progreso del proyecto se ralentice, se pueden realizar algunas optimizaciones nuevamente. En este momento, alta disponibilidad, alto rendimiento, alta concurrencia, etc., puede ser necesario.

"Si los recursos del proyecto lo permiten, algunas optimizaciones y refactorizaciones ligeramente excesivas son aceptables, y es bueno mantener el entusiasmo técnico del equipo. Pero si los recursos no lo permiten, hay que contar el dinero gastado y juzgar si la deuda técnica es razonable. La naturaleza, cómo pagar mejor la deuda, si es realmente necesario pagarla, si realmente afecta el desarrollo empresarial, todo esto debe examinarse junto con las prioridades empresariales. Si la empresa no cumple con una ventana de tiempo, es posible que se pierda para siempre. Parte de la deuda técnica se puede pagar más tarde.", concluyó Wang Hui.