Determinar si el lenguaje / marco / tecnología es 'a prueba de futuro'

Soy desarrollador de PHP y recientemente comencé a trabajar con CodeIgniter. Parece que cada vez que busco algo relacionado con CodeIgniter, las publicaciones de blog y lo que no son generalmente de '09 o '10, por lo que me hizo pensar, ¿CodeIgniter sigue siendo relevante y será en el futuro? ¿Hay otro marco que está teniendo lugar?

Lo mismo ocurre con otros lenguajes y marcos también. ¿En qué momento abandonas el aprendizaje de ciertos idiomas o marcos? ¿Hay alguna manera fácil de encontrar aquellos que están surgiendo y que vale la pena recoger?

No es una ciencia exacta, así que no espere poder predecir las tendencias futuras en el panorama tecnológico más de 5 años con certeza.

Pero buscaría todo lo siguiente:

• Base instalada : una base instalada más grande significa que muchas compañías intentarán invertir en la tecnología y su mantenimiento, lo que significa que se necesitarán desarrolladores para trabajar con la tecnología. Se produce un ciclo positivo. Por ejemplo Java, COBOL como antes, no se va a desaparecer por un muy largo tiempo.
• Amplio soporte de la industria : ¿hay múltiples actores importantes de la industria que respalden la tecnología? Solo un patrocinador comprometido es una señal de advertencia: podría caerse o dejarse de lado en cualquier momento con un solo cambio de estrategia.
• Código abierto : los principales productos de código abierto han demostrado ser apuestas extremadamente buenas a largo plazo (consulte Linux, Apache, Red Hat, JBoss, Eclipse, por ejemplo ...). Los productos patentados, por otro lado, son algo así como el capricho de un único proveedor donde corre el riesgo de descontinuar / aumentar los precios / intentar forzar a migrar a su "próximo gran negocio".
• Calidad : los productos de alta calidad simplemente vivirán más tiempo porque la gente querrá usarlos en lugar de cambiar a otra cosa. Por el contrario, los productos de baja calidad se abandonarán tan pronto como aparezca algo mejor.
• Innovación : ¿la tecnología está a la vanguardia de la innovación? Si es así, es probable que gane adopción y soporte entre las empresas y usuarios más innovadores. Esto finalmente comenzará a convertirse en la corriente principal (diría que nuevos lenguajes como Scala y Clojure, por ejemplo, están en esta categoría)
• Comunidad : ¿existe una comunidad positiva, de mente abierta, pragmática, comprometida y útil en torno a la tecnología? Estas son las personas que finalmente garantizarán su futuro .....

No hay forma de saber si algo va a ser una prueba futura en la que preferiría centrarme si la tecnología me ayuda a resolver el problema que tengo hoy. Abandonaría el aprendizaje de un determinado idioma o marco cuando ya no funcione para resolver sus problemas.

Participe en la comunidad que representa lo que está haciendo y puede tener una buena idea de lo que va y viene, pero aun así prefiero pasar mi tiempo con la mejor herramienta para el trabajo, no lo que está de moda o lo que creo que estará de moda. año o dos a partir de ahora.

No hay forma de determinar definitivamente si algo es una prueba futura. Lo más cercano que puede llegar es determinar el nivel de actividad en torno a un lenguaje o marco en particular: si hay mucha actividad de desarrollador, generalmente es una buena señal de que el lenguaje / marco está aumentando en popularidad y será viable por un tiempo . El inverso indica que hay menos entusiasmo y que el soporte (a través de foros de desarrolladores) puede ser más difícil de conseguir.

Mientras su lenguaje / marco de elección resuelva el problema que está tratando de resolver, no debería tener que preocuparse por el futuro, a menos que esté trabajando claramente con una tecnología moribunda. La tecnología sigue cambiando: una cosa que puede hacer es realizar un seguimiento de las tendencias de la industria. Aprender nuevos lenguajes / marcos de programación, como se señala en este hilo , puede ayudarlo a mantenerse al día con las tendencias y le brinda la oportunidad de evaluar continuamente nuevas herramientas.

La "prueba de futuro" tiene que ver tanto con la fuerza de voluntad y la terquedad como con las preocupaciones más pragmáticas.

Un ejemplo extremo es este . Sparkle Filters TODAVÍA FUNCIONA con una computadora IBM 402 de finales de los años 40 como su sistema de contabilidad. Esta es una máquina que se programa utilizando enchufes eléctricos en lugar de "archivos".

Personalmente, he tenido experiencia con una compañía que aún mantiene máquinas basadas en MS-DOS dentro de instrumentos especializados que están diseñados para funcionar durante décadas. Incluso he descartado un PDP operativo tan tarde como 1997.

¡Diría que si su compañía recibe una visita del museo de historia de la computadora, como lo hicieron Sparkle Filters, eso sería una señal de que usted (o sus antepasados) han logrado "proteger el sistema" con éxito!

Puedo responder si una tecnología en particular está preparada para el futuro; la respuesta es casi seguro que no, ya que no pusiste un calendario en esto.

Para responder a esta pregunta, necesitará agregar más detalles a los requisitos. Por ejemplo:

• ¿De qué calendario estamos hablando: 1 año, 3 años, más de 5 años?
• ¿Cuál sería el costo de elegir algo que no esté disponible en 5 años?
• ¿Qué beneficios obtendrá al elegir una opción menos "segura", y los beneficios superan los riesgos?

La elección de un lenguaje / marco / tecnología es realmente una parte de la gestión de riesgos en el proyecto. Al igual que con todos los riesgos, deberá considerar una serie de factores (estoy tratando de mantener este breve) y luego tomar medidas para reducirlo a un nivel apropiado para la situación en cuestión.

Como con la mayoría de las cosas en la vida, la actividad que involucra el menor riesgo puede no ser la mejor opción.

En resumen, con cuánta incertidumbre está preparado para vivir en comparación con los beneficios que va a cosechar al usar durante el tiempo de vida esperado del proyecto.

Cuanto más tiempo desees mirar hacia el futuro, menos certeza habrá. Si está satisfecho con solo preocuparse por los próximos 2 años, por ejemplo, su elección será mucho más fácil de hacer (y dejará muchas más opciones disponibles para usted) que elegir algo que deba estar disponible durante los próximos 10 años.

Hay tantos factores en esto que diría que es imposible. Entre las cosas que podrían salir mal están:

• Moda. La gente pierde interés y dirige su atención a una nueva plataforma más bonita. Perl tenía casi el monopolio de las aplicaciones web alrededor del año 2000. Ahora apenas se menciona.
• Cuota de mercado de los vendedores. alrededor del año 2000, aunque C ++ / Sun Solaris era bueno hasta el año 3000.
• Travesuras corporativas. Hace un par de años, habría elegido Java como la plataforma a prueba de futuro. Con ORACLE con derechos de autor de la API, etc. Creo que veré un cambio hacia otro marco de lenguaje, solo desearía saber cuál.
• Fin del camino. Estoy pensando en cosas como Visual Basic que, después de una larga y honorable historia, ya no se pueden estirar para acomodar las últimas ideas en el desarrollo de software.
• El perdedor gana. PHP (que me gusta) no ganó y nunca ganó ningún concurso de belleza entre desarrolladores, pero se ha convertido en el rey indiscutible de la web. Cuando escribí un php por primera vez en 2004, nunca lo habría respaldado como la lengua franca del desarrollo web.
• Los patitos feos. Javascript sin cambiar una sola sintaxis o agregar una sola API, de repente pasó de ser un lenguaje de scripts hokey que un banner animado molesto agrega a la pieza central de WEB 2.0.

Al final no importa tanto. CodeIgniter trabaja para usted y le ofrece lo que desea. Nada de lo que haga dejará de funcionar porque las publicaciones en el blog son antiguas o la tasa de publicación se ha ralentizado. Así que mi consejo sería usar lo que funciona ahora y lidiar con el futuro cuando llegue.

Un framework PHP, Symfony, explicó esto perfectamente en su sitio .

10 criterios para elegir el marco correcto

¡Estás progresando y eso es algo bueno! Ya sabe que va a utilizar un marco para desarrollar su sitio o su aplicación. ¿Pero cual? Aquí hay una lista de verificación que puede usar para evitar cometer un error:

1.Popularidad y tamaño de la comunidad.

Cuanto más conocido y reconocido sea el marco, más "vivirá", evolucionará y se completará: nuevas ideas, el número y la calidad de los complementos, etc.

2. Filosofía

Esta es la esencia misma del marco: es un criterio fundamental para garantizar que satisfaga sus necesidades. Una herramienta desarrollada por profesionales para sus propias necesidades obviamente satisfará las demandas de otros profesionales.

3. Sostenibilidad

Antes de elegir un marco, asegúrese de que pueda seguirle el ritmo durante todo el tiempo. Esto simplifica tanto el mantenimiento como la actualización de sus aplicaciones.

4. Apoyo

Otro criterio que no debe pasarse por alto es la facilidad de encontrar respuestas a sus preguntas y obtener ayuda. Identifique el soporte disponible: del editor. ¿De una comunidad (listas de correo, IRC, etc.)? ¿De las empresas de servicios (desarrollo, soporte, capacitación)?

5. Técnica

Para evitar quedar atrapado en un laberinto, siempre es preferible elegir una solución interoperable; uno que respete las mejores prácticas en términos de desarrollo (patrones de diseño)

6 seguridad

Cualquier aplicación es potencialmente vulnerable. Para minimizar el riesgo, siempre es mejor seleccionar un marco capaz de garantizar funciones de seguridad (gestión XSS, por ejemplo).

7 documentación

Es una necesidad absoluta evaluar la naturaleza, el volumen y la calidad de la literatura existente sobre un marco: una herramienta bien documentada es más fácil de usar y más actualizable.

8 licencia

Las licencias son importantes simplemente porque pueden tener un impacto significativo en sus aplicaciones. Por ejemplo, una aplicación desarrollada utilizando un marco con licencia GPL estará necesariamente sujeta a GPL. Por otro lado, este no es el caso para un marco con licencia MIT.

9. Disponibilidad de recursos en el mercado

Quizás desee tener un equipo técnico que lo rodee durante la fase de desarrollo o en el largo plazo, tanto para el mantenimiento como para las actualizaciones. En otras palabras, asegúrese de que las habilidades requeridas para la herramienta que está utilizando estén disponibles en el mercado abierto.

10. Pruébalo

Esa es la clave! No se conforme con leer reseñas, comentarios y rumores, buenos o malos, en Internet. Al probarlo, podrá tomar una decisión y asegurarse de que está completamente cómodo con la herramienta.

La clave es la paciencia. Paciencia, paciencia, paciencia. No hay forma segura de predecir el futuro. (¿tuve que escribir eso?) Pero si le das a la nueva tecnología un par de años y observas cómo se adopta, tendrás una buena idea de si se arraigará o no y si es adecuada para proyectos a largo plazo / inversión de tiempo .

Entonces, cuando aparezca NextNewThing (tm), siéntase libre de subirse al carro ... simplemente no por nada importante en los primeros años.

La respuesta de Mikeras es bastante agradable. Agregaré que la preparación para el futuro es un tipo de seguridad o gestión de riesgos realmente. A menudo requiere que renuncies a ciertas comodidades y beneficios de costo / productividad ahora para evitar problemas más adelante. He estado haciendo tecnología a prueba de futuro durante bastante tiempo. Hay ciertos patrones que pueden ayudar. Aquí hay algunos.

1. Los datos deben almacenarse en un formato abierto que sea fácil de extraer o transformar más tarde. Los formatos de archivo extraños son una gran técnica de bloqueo y área de trampa en general. Además, prefiera enfoques más simples como CSV, ASN.1 o JSON en lugar de basura complicada como XML o, por ejemplo, formato Word 97;). La idea es que sea lo suficientemente simple como para combinar un analizador usted mismo y el analizador de formato de bajo nivel es reutilizable en sus aplicaciones.

2. Idealmente, las aplicaciones deberían tener incorporadas interfaces neutrales y de proveedores, además de una descripción precisa de lo que hacen. Debe diseñar cosas donde pueda cambiar o desechar la implementación sin romper nada. Además, mudarse a una nueva plataforma es fácil si su método de llamar a procedimientos o procesar datos funciona en todas las plataformas. Entonces, las interfaces son lo más importante para corregir. Cuanto más simple, rápido y abierto sea el método de implementación de la interfaz, mejor.

3. La pila debe ser completamente de código abierto y libre de modificar. Las licencias GPL, LGPL, BSD, MIT, etc. están bien en este ángulo. La idea es que, si la comunidad comienza a desaparecer, entonces la pila podría necesitar ser movida a un nuevo [hardware / OS / protocolo / etc.]. Y necesitas el código para hacer eso.

4. El diseño de la pila debe ser extremadamente modular, y cada pieza debe ser entendida por una sola persona. Esto hace que sea más fácil para un nuevo grupo recogerlo y mantenerlo. Tener incluso los niveles más bajos del tiempo de ejecución, las bibliotecas y el compilador se pueden tener muy en cuenta si se necesita portar. A menudo, solo esa parte se puede portar y todo su código anterior funcionará.

5. Su aplicación debe hacerse de forma modular que elimine los detalles de la plataforma para minimizar el reproceso en esa área. Ayuda a estructurar las funciones en bloques de entrada / procesamiento / salida donde sea posible también. Esto puede ayudar a un análisis de lo que se verá afectado por un puerto (y el análisis de corrección en general a la 'metodología de sala limpia). La plataforma de enfoque de menor riesgo es utilizar las características de mínimo común denominador que son compatibles de manera universal con una interfaz que le permite usarlas, lo que reduce aún más la transferencia. (Dije que estarías perdiendo algo ...)

6. La escritura dinámica, la inferencia de tipos u otros enfoques de escritura flexibles ayudan. Un puerto a una nueva plataforma podría cambiar las definiciones de los tipos base. Los idiomas que escriben con fuerza internamente significan que te preocupas menos por estas cosas.

7. Mantenga el modelo de concurrencia simple. El mensaje dirigido por eventos que pasa a través de interfaces claras es portátil para ... básicamente todo. También hay corutinas. Solo desea evitar rutas que sean propensas tanto a errores como a problemas de portabilidad.

8. Mire los tiempos de ejecución portátiles de Mozilla y Apache. Tienen en cuenta muchos problemas específicos de la plataforma con ciertas opciones de interfaz e implementación. Pueden darle pistas sobre qué preocuparse, junto con proporcionar buenas soluciones a muchos problemas.

Ejemplo perfecto: Tcl. Lo sé, mucha gente lo odia y rara vez lo uso yo mismo. Sin embargo, Tcl es un lenguaje extremadamente fácil de entender, implementar (12 reglas principales) y codificar. Es pequeño, lo suficientemente rápido, se integra con servidores web, se integra en aplicaciones nativas, se ha portado a toneladas de cosas, tiene ciertas características de seguridad , y se ha actualizado regularmente desde los años 80 cuando se realizó. Usted o yo podríamos implementar un tiempo de ejecución TCL completo en poco tiempo para el lenguaje principal. Si tuviéramos que portar la biblioteca estándar, sería más fácil que portar .NET o Java. Y hay bastante código útil escrito para ello. Y se ha utilizado en tecnología web desde la locura del "agente móvil" a la que también apuntaban los applets de Java. Por ejemplo, el marco web de OpenACS se remonta a 1998 con un servidor anterior a ese.

Otros ejemplos: BASIC, COBOL y LISP (Scheme o CL). Todos estos idiomas se remontan a los años 50 o 60. Son lo suficientemente simples como para facilitar la comprensión, la implementación y la traducción mecánica. Sin embargo, puedes construir cosas útiles con ellos. COBOL todavía impulsa la mayor parte del procesamiento de transacciones del mundo, se ha actualizado algunas veces y se ejecuta incluso en .NET. Las antiguas aplicaciones QBasic / QuickBASIC todavía se ejecutan hoy con herramientas abiertas / gratuitas en plataformas modernas, junto con posibilidades de portabilidad a mejores herramientas como GAMBAS o RealBASIC. Los codificadores LISP naturalmente hacen que sus sistemas sean modulares y funcionales, lo que facilita la transferencia. Ha habido un flujo constante de implementaciones durante décadas, abierto y comercial.

Entonces, interfaces, apertura, simplicidad, modularidad y arquitectura / diseño / codificación neutral en la plataforma. ESTOS le proporcionarán las pruebas de futuro que necesita. La mayor parte del tiempo, de cualquier manera.