Sobre la obsolescencia del código y el ciclo de vida del software





Startup, nuevas tecnologías, lenguajes y frameworks modernos. Todo esto es tan emocionante cuando empezamos a hacer algo desde cero. Y definitivamente intentaremos elegir tecnologías modernas y populares amadas por millones para nuestro proyecto. Pero el tiempo no detiene su implacable carrera, y de repente miramos hacia atrás y vemos que nuestra "startup" ya tiene 15 años. Y el mundo que nos rodea ha cambiado hace mucho tiempo. Y todavía tenemos el mismo Basic / Delphi / Fortran / lo que sea en nuestro proyecto. ¿Y cómo vivir con eso?



No, no quiero criar otro holívar en absoluto, y esto está lejos de ser un abanico. Es solo mi dolor personal, liderar proyectos por valor de más de un millón de líneas de código en tecnologías obsoletas, en particular en Delphi.



Y resulta interesante cuánto dura un proyecto exitoso en general. Si miras a tu alrededor, entonces, en principio, hay bastantes proyectos con una "historia barbuda". Estos son WinRAR, Microsoft Office, AutoCAD, Photoshop, 3DSmax y muchos otros. Además, se trata de proyectos para un público masivo. Y cuántos sistemas bancarios diferentes, CIS, CRM y otros sistemas "corporativos" de varios niveles existen. Y muchos de ellos no se escribieron en los últimos cinco años.



Por supuesto, me gustaría estar al día, pero migrar un gran proyecto de un idioma a otro, en mi opinión, es una tarea difícil. No solo se está llevando a cabo esta migración y se está escribiendo un nuevo código, el proyecto antiguo también debe continuar funcionando, viviendo y desarrollándose. En un proyecto nuevo, es necesario repetir toda la lógica del anterior, pero no siempre está claro. En un proyecto antiguo, se puede construir mucha lógica en bibliotecas que no han sido compatibles con sus desarrolladores durante mucho tiempo. En un nuevo proyecto, estas bibliotecas deben reemplazarse. Si estos son componentes visuales, esto es aún más difícil, porque además de encontrar un reemplazo, también debe considerar cómo reescribir el código para trabajar con estos componentes visuales para que el nuevo componente repita el comportamiento del anterior. Por supuesto, todo es solucionable y no hay objetivo de repetir el trabajo del proyecto al 100%,pero incluso el 50% de hacer esto es muy, muy difícil, y en el proceso de reescritura de este tipo puede resultar que la plataforma / lenguaje en el que decidieron reescribir de alguna manera no es adecuado o ya está perdiendo popularidad.



Por supuesto, me refiero principalmente a proyectos grandes con una capa significativa de lógica. Un millón de líneas y más. Aquellos. no sobre mini-sitios, no sobre microservicios, sino sobre tales monolitos (incluso si están divididos en "componentes" / "capas", etc.).



Me gustaría conocer la opinión de los aquí presentes, ¿ha encontrado problemas similares y cómo ha actuado en situaciones similares?



¿Qué soluciones recomendaría aplicar durante el desarrollo para que en 10-15 años no haya ningún deseo de transferir el proyecto a otra plataforma?



¡Gracias por las respuestas!



All Articles