¿Cómo será la programación en 2025?



A menudo leemos sobre las mejores prácticas en programación, sobre las nuevas características del marco o las novedades de la próxima versión de PHP. Leemos cómo cambiar " esto por esto " , por qué alguna técnica es buena o mala, o qué paquete nuevo puedes usar en tu proyecto. Pero todo esto es especulación solo sobre el pasado o el presente.



Terminaré de leer el libro « de Lo inevitable » , escrito por el fundador de la revista Wired, en el que sólo habla del futuro. Inspirado por este libro, sugiero mirar el futuro de la programación.



Hoy luchamos contra la deuda técnica (sea lo que sea que eso signifique), código heredado que es difícil de mantener y costoso de modificar, pero que genera mucho dinero al mismo tiempo. De forma regular, tenemos que refactorizar el código, seguir los principios de DDD, escribir pruebas, actualizar la versión de PHP por motivos de seguridad, instalar las últimas versiones de software en el servidor y automatizar el diseño.



Hay tanto trabajo de rutina actual que no hay absolutamente tiempo para mirar decenas de otros proyectos que nuestra empresa apoya ... o, al menos, lo almacena en algún lugar de nuestros servidores. Deberíamos contratar a un experto para ayudar a mejorar cada aspecto al menos un poco. No porque estos proyectos sean malos, sino simplemente porque hay muchas tecnologías que podemos usar, e incluso más código que tenemos que mantener.



¿Cómo sucederá todo esto en el futuro?



IDE utilizará inteligencia artificial



En el futuro, teclear el código será más fácil. Nuestro IDE estará impulsado por inteligencia artificial, que aprende de los datos anónimos de otros proyectos PHP y todos los proyectos de código abierto en Github y Gitlab.



Gracias a esta IA, cuando comencemos a escribir "class HomepageC ...", el IDE sabrá que estamos creando un controlador de página de inicio, que estamos usando Symfony, así como su versión de composer.json, y ofrecerá agregar automáticamente modificadores de finalización al resto del código. y tipos fuertes, basados ​​en el conocimiento de la versión de PHP que se está utilizando, también de composer.json. Generará una plantilla para el motor de plantillas que estamos usando e imitará el contenido que se encuentra en otras plantillas que ya tenemos en nuestro proyecto.



Gracias a la enorme cantidad de datos anónimos y datos de las tiendas de códigos públicos, la IA sabrá cómo probar mejor el controlador y utilizará este conocimiento para crear una prueba de controlador óptima.



Mejor práctica verificada



Cuando hablamos de "mejores prácticas", no nos referimos a lo que yo o alguien más escribimos en una publicación o libro basado únicamente en experiencias personales. Estas opiniones a menudo se basan en experiencias de unos pocos proyectos y están cargadas de emociones.



En el futuro, el concepto de "mejores prácticas" será reemplazado por "práctica verificada" y se basará en datos reales asociados con dos indicadores rígidos: la deuda técnica y la eficiencia de la codificación. La deuda tecnológica tendrá un equivalente financiero que mostrará cuánto costará mantener cada línea de código en el futuro. ¿Eres libre de escribir código estático sin clases escritas? La cuerda puede "costar" $ 10. ¿Estás escribiendo clases finales con tipos fuertes y un método público? En este caso, la línea costará $ 2.



Estos números no serán aleatorios, sino que se basarán en el análisis constante de una cantidad colosal de big data, anónimos para todos los proyectos que elijan utilizar esta función. El código se comparará con los costos monetarios necesarios para mantener y mejorar los proyectos. Gracias a estos comentarios, la IA también sabrá qué versión es más beneficiosa para su proyecto en particular.



La IA conocerá el contexto de su proyecto y comparará los datos en consecuencia. ¿Tiene un proyecto CLI? Se comparará con el código de otros proyectos CLI en esta área temática. ¿Estás creando un sitio web? Se comparará con diseños de otros sitios.



La eficiencia de la codificación estará determinada por la métrica de "mantenibilidad" del proyecto. Se medirá en una escala de 0 a 100 puntos, donde 0 significa que se necesitan muchas horas para comprender el código y que puede llevar días o incluso semanas realizar cambios. Un código con una puntuación de 100 será fácil de entender para un desarrollador junior y podrá cambiar el código casi instantáneamente.



Autocompletado verificado por IDE



El IDE conocerá estas métricas y también seguirá los patrones utilizados en su código. Cuando comienzas a escribir un fragmento de código cuya eficiencia es de 40-50 puntos, aparecerá la finalización automática con una sugerencia de código con la misma funcionalidad, pero con una eficiencia de 80-90. Esto es similar al trabajo que hacen hoy Rector o PHPStan.



El análisis de rendimiento también se realizará junto con el análisis de rendimiento de codificación. El rendimiento se medirá automáticamente cada vez que el código cambie en segundo plano en el contenedor de Docker y se le informará de cualquier pérdida de memoria o aumento del tiempo de ejecución. Este análisis será tan preciso que marcará la cadena o los caracteres específicos que causaron la fuga y sugerirá una solución que solo debe aceptar.



Refactorización de AST



La refactorización también será más poderosa de lo que es hoy. Se basará en el árbol de sintaxis abstracta (AST). El IDE le sugerirá la mejor refactorización que planea hacer ahora, basándose en datos anónimos de todos los proyectos abiertos y cerrados.



En lugar de referirse a las mejores prácticas, sabrá que:



  • La solución A le costará $ 3 por línea en deuda técnica y tendrá una calificación de 95 en eficiencia y 45 en desempeño.
  • La solución B le costará $ 1 por línea en deuda técnica, con una calificación de eficiencia de 70 y una calificación de rendimiento de 50


¿Estás construyendo una startup y quieres probar tu idea? Luego, elegirá la opción A. ¿Qué sucede si su empresa es estable y debería seguir siéndolo en el futuro? Luego debe cambiar a la opción B, que es más barata en soporte y rendimiento, pero un poco más lenta en desarrollo.



No tendrá que discutir con un colega o con su jefe por qué debe usar esta o aquella solución. Compara los números y luego decide basándose en sus prioridades actuales.



Arquitectura de contexto



Tu código tendrá una arquitectura contextual. La IA sabrá cuándo moverse entre contextos basándose en datos de otros proyectos y el costo final de migrar a ellos. ¿Estás iniciando un proyecto de WordPress? Está bien. Pero, ¿qué pasa si su proyecto se vuelve más popular y necesita cambiar a algún marco PHP que se adapte mejor a sus necesidades? El IDE le pedirá que cambie a Laravel. Un clic y listo.



Tres años después, su proyecto crece y tendrá muchas tareas para integrar servicios de terceros que ya están integrados en el marco de Symfony. El IDE te pedirá que migres ... haz clic ... y boom, estás en Symfony 9. ¿Descubriste que no hay suficientes desarrolladores de Symfony en el mercado para manejar el desarrollo de tu proyecto? Un clic y el IDE transferirá el proyecto a un marco para el que hay suficientes desarrolladores a un costo razonable.



Respuestas versionadas de StackOverflow 



El IDE escaneará su código y analizará sus hábitos de codificación. Por lo general, escribe una función en 15 minutos, pero ahora tarda casi 2 horas. En los próximos años, el IDE será tan bueno que notará incluso una ligera disminución en la velocidad de escritura del código en cuestión de segundos.



Luego, el IDE verificará su código, escaneará las respuestas en StackOverflow, comparará las respuestas con las versiones de su composer.lock y le sugerirá que utilice el código específico que mejor se adapte a sus necesidades.



¿Le preocupa que este fragmento de código se copie al azar y rompa su proyecto? La calificación de la respuesta ya no se basa en la votación del usuario, sino que ahora tiene en cuenta el porcentaje de uso de la respuesta si se integra con éxito en el código del proyecto.



Fragmentos de código probados



Además, StackOverflow prueba diariamente los fragmentos de código y también antes de copiarlos en su proyecto. Es con la versión de su entorno local, por lo que puede estar seguro de que el código funcionará. Las personas ya no escriben versiones de estas respuestas por sí mismas, como lo hacían en el pasado. El código de la respuesta se actualiza automáticamente con cada versión de la tecnología o el marco que utiliza. Se ha dado alguna respuesta para Symfony 5. ¿Qué pasará cuando se lance Symfony 6? El código antiguo en la respuesta se actualizará con la receta de AST que se lanzó con Symfony 6. De esta manera, el humano y el IDE pueden trabajar fácilmente con él.



Financiamiento basado en actividades de código abierto



Se creará un nuevo proyecto que vinculará empresas comerciales y contribuyentes de código abierto. El proyecto de código abierto será financiado por las empresas que lo utilicen. Los desarrolladores que contribuyan serán financiados a través de un sistema único basado en los flujos de dinero entrante, sin tarifas adicionales para cubrir los costos.



La financiación se determinará utilizando métricas como el impacto de las funciones, la carga de trabajo, el tiempo empleado, la eficiencia del código, etc. Por lo tanto, el código se desarrollará de manera mucho más consistente que cuando fue desarrollado por colaboradores independientes en su tiempo libre. Un desarrollador en un proyecto de código abierto, de hecho, obtendrá un trabajo de tiempo completo financiado por ese proyecto.



¿Qué recibirán estas empresas como recompensa? Promoción específica de la comunidad, lanzamientos previos al lanzamiento de nuevas versiones y acceso directo a consultores expertos que han creado los proyectos de código abierto que utilizan (estas empresas).



Consolidar marcos



Se consolidarán ~ 10 frameworks PHP actualmente existentes. Las comunidades alrededor de los frameworks PHP aprenderán a colaborar más, en lugar de desarrollar copias casi idénticas de frameworks con un enfoque MVC.



Gracias a las migraciones de AST, puede cambiar a cualquier marco PHP. Esto reducirá la selección a 3-4 marcos. Si la migración entre marcos es cuestión de 1 clic en su IDE, entonces no habrá más competencia basada en la afirmación de que "sucedió históricamente" y los hábitos, pero solo en la calidad.



Reducir la cantidad de marcos conducirá a su enfoque más limitado: un marco tendrá éxito en API, otro en CLI, el tercero en sitios con excelente UX.



Cuando toda la comunidad PHP se concentre en menos marcos, nos permitirá invertir el esfuerzo ahorrado en desarrollar nuevas tecnologías y características.



Solo 1 versión estable de PHP



Gracias a las migraciones AST automáticas, solo habrá dos versiones de PHP: estable y dev. Dado que la actualización de cualquier paquete o proyecto será muy rápida y económica, no hay razón para no actualizar a la última versión. La comunidad PHP puede tardar uno o dos años en aceptar esto y mantener todos los proyectos sincronizados. Pero cuando esto suceda, dentro de un mes después del lanzamiento de la nueva versión de PHP, todo el ecosistema de código abierto lo utilizará como versión mínima.



Actualizaciones de código instantáneas y totalmente automáticas



El código PHP no necesita actualizarse manualmente. Cada versión de PHP tendrá una "receta" de actualización completa basada en AST que puede usar para actualizar automáticamente el código en su proyecto. GitHub manejará estas "recetas", por lo que cuando se lance una nueva versión de PHP, GitHub comenzará a enviar automáticamente una solicitud de extracción a su repositorio. Habrá actualizaciones automáticas no solo para PHP, sino también para cualquier marco o paquete. Como Dependabot, que se integró recientemente en GitHub, pero ahora con una actualización de código y todos los problemas de compatibilidad con versiones anteriores.



Actualizador de GitHub



Si no desea hacerse cargo de todos los RP usted mismo, puede registrarse en el programa de actualización automática para que GitHub lo haga por usted. También actualizará adecuadamente las versiones y su SemVer.



SemVer automatizado 



No habrá debate sobre si el cambio es una ruptura de compatibilidad con versiones anteriores o simplemente un parche. AI analizará el código antes y después, y en base a esto tomará decisiones. Será tan inteligente que podrá determinar qué impacto tiene un cambio en particular. Si esto no afecta ningún código en otros proyectos, se lanzará como parche.



PHP RFC basado en lecciones aprendidas



El mismo análisis de ruptura de compatibilidad con versiones anteriores será posible para cualquier RFC en el código principal de PHP. ¿Quiere sugerir constantes escritas? AI le dirá cuántos proyectos de los 10,000 principales en Github se romperán como porcentaje. Algo similar ahora se está haciendo manualmente en algunos RFC.



Repensar la ruptura de compatibilidad con versiones anteriores



La IA también le ayudará a generar "recetas" de migración de AST, por lo que una actualización instantánea puede manejar completamente la interrupción de la compatibilidad con versiones anteriores. Esto conducirá a un cambio en el concepto mismo. Las rupturas de compatibilidad con versiones anteriores solo ocurrirán cuando las actualizaciones automáticas no puedan ocurrir y se requiera que un humano cambie el código.



Pruebe RFC localmente



Además, cualquiera puede probar la función RFC localmente justo después de que se crea el PR en GitHub. ¿Cómo? Github creará automáticamente una versión temporal con una etiqueta de desarrollo especial y enviará esa versión de PHP al registro del paquete. Creas un RFC para agregar constantes escritas, lo envías como PR a GitHub y después de 1 minuto puedes ejecutar sudo apt-get install php-dev-typed-constant para obtener PHP con este RFC en tu máquina local.



Por lo tanto, los programadores podrán probar esta función incluso antes de ser incluidos en la rama principal e incluso antes de votar en el RFC. En este caso, incluso la votación sobre nuevas características se basará en datos y experiencias reales, y no en emociones, opiniones subjetivas y argumentos.



¿Qué nos depara el futuro?



En el futuro, nuestras capacidades no estarán limitadas por nuestra historia, elecciones pasadas o tecnologías en rápida evolución que hacen que nuestro código se vuelva obsoleto rápidamente. Con solo un clic, todas nuestras herramientas son las más avanzadas del mercado actual.



Esto nos permitirá experimentar más, probar nuestras suposiciones y obtener comentarios reales. Esto conducirá a una automatización aún mejor de los procesos de codificación e invenciones en el lenguaje, los patrones y la arquitectura de aplicaciones que ni siquiera podemos imaginar hoy.



"La mejor forma de predecir el futuro es crearlo". 



¡Feliz creación!



All Articles