Déterminer si le langage / le cadre / la technologie est «à l'épreuve du temps»

Je suis développeur PHP et j'ai récemment commencé à travailler avec CodeIgniter. Il semble que chaque fois que je recherche quelque chose en rapport avec CodeIgniter, les articles de blog et ce qui ne vient généralement pas de '09 ou '10, donc cela m'a fait réfléchir, est-ce que CodeIgniter est toujours pertinent et est-ce que ça va être à l'avenir? Y a-t-il un autre cadre qui prend sa place?

Il en va de même pour les autres langages et frameworks également. À quel moment abandonnez-vous l'apprentissage de certains langages ou cadres? Existe-t-il un moyen facile de trouver ceux qui émergent et méritent d'être ramassés?

Ce n'est pas une science exacte, alors ne vous attendez pas à être en mesure de prédire les tendances futures du paysage technologique plus de 5 ans avec certitude.

Mais je chercherais tout ce qui suit:

• Base installée - une base installée plus grande signifie que de nombreuses entreprises continueront d'investir dans la technologie et sa maintenance, ce qui signifie que les développeurs devront travailler avec la technologie. Un cycle positif s'ensuit. Par exemple, Java, comme COBOL avant lui, ne disparaîtra pas très longtemps.
• Large soutien de l'industrie - y a-t-il plusieurs acteurs majeurs de l'industrie qui soutiennent la technologie? Un seul contributeur engagé est un signe d'avertissement - il pourrait être abandonné ou mis à l'écart à tout moment avec un seul changement de stratégie.
• Open source - les principaux produits open source se sont avérés être de très bons paris à long terme (regardez Linux, Apache, Red Hat, JBoss, Eclipse par exemple ....). Les produits exclusifs, quant à eux, sont quelque peu aux caprices d'un seul fournisseur où vous risquez de cesser / d'augmenter les prix / d'essayer de forcer à migrer vers leur «prochaine grande chose».
• Qualité - les produits de haute qualité vivront simplement plus longtemps parce que les gens voudront les utiliser plutôt que de passer à autre chose. À l'inverse, les produits de mauvaise qualité seront abandonnés dès que quelque chose de mieux arrivera.
• Innovation - la technologie est-elle à la pointe de l'innovation? Si tel est le cas, il est susceptible de gagner en adoption et en soutien auprès des entreprises et des utilisateurs les plus innovants. Cela va finalement commencer à devenir courant (je dirais que de nouvelles langues comme Scala et Clojure par exemple sont dans cette catégorie)
• Communauté - existe-t-il une communauté positive, ouverte d'esprit, pragmatique, engagée et serviable autour de la technologie? Ce sont ces gens qui garantiront finalement son avenir .....

Il n'y a aucun moyen de savoir si quelque chose sera à l'épreuve du temps. Je préfère me concentrer sur la technologie qui m'aidera à résoudre le problème que j'ai aujourd'hui. Vous abandonneriez l'apprentissage d'un certain langage ou cadre quand il ne fonctionnerait plus pour résoudre vos problèmes.

Soyez impliqué dans la communauté qui représente ce que vous faites et vous pouvez avoir une bonne idée de ce qui va et vient, mais même dans ce cas, je préfère passer mon temps avec le meilleur outil pour le travail, pas ce qui est chaud ou ce que je pense sera chaud. dans un an ou deux.

Il n'y a aucun moyen de déterminer définitivement si quelque chose est à l'épreuve du temps. Le plus proche que vous pouvez faire est de déterminer le niveau d'activité autour d'un langage ou d'un framework particulier - s'il y a beaucoup d'activité de développeur, c'est généralement un bon signe que le langage / framework a tendance à gagner en popularité et sera viable pendant un certain temps . L'inverse indique qu'il y a moins d'excitation et que le support (via les forums de développeurs) peut être plus difficile à trouver.

Tant que votre langue / cadre de choix résout le problème que vous essayez de résoudre, vous ne devriez pas avoir à vous soucier de la pérennité, sauf si vous travaillez clairement avec une technologie mourante. La technologie ne cesse de changer - une chose que vous pouvez faire est de suivre les tendances de l'industrie. L'apprentissage de nouveaux langages / cadres de programmation, comme indiqué dans ce fil , peut vous aider à suivre les tendances et vous donne l'occasion d'évaluer en continu de nouveaux outils.

«Inessible au futur» concerne autant la volonté et l'entêtement que des préoccupations plus pragmatiques.

Un exemple extrême de est ce . Filtres Sparkle FONCTIONNE ENCORE un ordinateur IBM 402 de la fin des années 40 comme système de comptabilité. Il s'agit d'une machine qui est programmée à l'aide de fiches électriques plutôt que de "fichiers".

J'ai personnellement eu de l'expérience avec une entreprise qui maintient encore des machines MS-DOS à l'intérieur d'instruments spécialisés conçus pour fonctionner pendant des décennies. J'ai même mis au rebut un PDP opérationnel jusqu'en 1997.

Je dirais que si votre entreprise obtient une visite du musée de l'histoire de l'informatique, comme l'a fait Sparkle Filters, ce serait un signe que vous (ou vos ancêtres) avez réussi à "pérenniser" le système!

Je peux vous dire si une technologie particulière est à l'épreuve du temps - la réponse est presque certainement non, puisque vous n'avez pas fixé de calendrier à ce sujet.

Pour répondre à cette question, vous devrez ajouter plus de détails aux exigences. Par exemple:

• De quelle échelle de temps parlons-nous - 1 an, 3 ans, 5+ ans?
• Quel serait le coût de la cueillette de quelque chose qui n'existe pas dans 5 ans?
• Quels avantages tirerez-vous du choix d'une option moins «sûre» et les avantages l'emportent-ils sur les risques?

Le choix d'un langage / cadre / technologie fait vraiment partie de la gestion des risques dans le projet. Comme pour tous les risques, vous devrez prendre en compte un certain nombre de facteurs (j'essaie de rester bref), puis prendre des mesures pour le réduire à un niveau approprié à la situation en cours.

Comme pour la plupart des choses de la vie, l'activité qui comporte le plus faible risque n'est peut-être pas le meilleur choix.

En bref, dans quelle mesure êtes-vous prêt à vivre par rapport aux avantages que vous allez retirer de l'utilisation pendant la durée de vie prévue du projet.

Plus vous voulez regarder vers l'avenir, moins il y aura de certitude. Si vous êtes satisfait de ne vous soucier que des 2 prochaines années par exemple, votre choix sera beaucoup plus facile à faire (et vous laissera beaucoup plus d'options) que de choisir quelque chose qui doit être présent pendant les 10 prochaines années.

Il y a tellement de facteurs à cela que je dirais que c'est impossible. Parmi les choses qui pourraient mal se passer: -

• Mode. Les gens se désintéressent et tournent leur attention vers une nouvelle plateforme plus jolie. Perl détenait un quasi-monopole des applications Web vers 2000. C'est à peine mentionné maintenant.
• Part de marché des vendeurs. vers 2000, vous auriez bien que C ++ / Sun Solaris était bon jusqu'en l'an 3000.
• Shenanigans d'entreprise. Il y a quelques années, j'aurais choisi Java comme plate-forme à l'épreuve du temps. Avec ORACLE, le copyright de l'API, etc. Je pense que nous verrons une évolution vers un autre cadre de langage, je souhaite juste savoir lequel.
• Fin de la route. Je pense à des choses comme Visual Basic qui, après une longue et honorable histoire, ne peut plus être étirée pour s'adapter aux dernières réflexions en matière de développement logiciel.
• Le perdant gagne. PHP (que j'aime) ne gagnerait pas et n'a jamais remporté de concours de beauté parmi les développeurs, mais il est devenu le roi incontesté du Web. Quand j'ai écrit pour la première fois du php en 2004, je ne l'aurais jamais soutenu en tant que linga franca du développement web.
• Les vilains canetons. Javascript sans changer un seul morceau de syntaxe ou ajouter une seule API, est soudainement passé d'un langage de script hokey qu'une bannière ennuyeuse animée ajoute à la pièce maîtresse de WEB 2.0.

En fin de compte, peu importe. CodeIgniter travaille pour vous et offre ce que vous voulez. Rien de ce que vous ferez cessera de fonctionner car les articles de blog sont anciens ou le taux de publication a ralenti. Donc, mon conseil serait d'utiliser ce qui fonctionne maintenant et de faire face à l'avenir quand il arrivera.

Un framework PHP, Symfony, l'a parfaitement expliqué sur leur site .

10 critères pour choisir le bon cadre

Vous progressez et c'est une bonne chose! Vous savez déjà que vous allez utiliser un framework pour développer votre site ou votre application. Mais lequel? Voici une liste de contrôle que vous pouvez utiliser pour éviter de faire une erreur:

1.Popularité et taille de la communauté

Plus le cadre est connu et reconnu, plus il sera «vivant», évolutif et complet: nouvelles idées, nombre et qualité des plug-ins, etc.

2. philosophie

C'est l'essence même du cadre: c'est un critère fondamental pour s'assurer qu'il répondra à vos besoins. Un outil développé par des professionnels pour leurs propres besoins répondra évidemment aux demandes des autres professionnels.

3. durabilité

Avant de choisir un cadre, assurez-vous qu'il pourra vous suivre pendant toute la durée. Cela simplifie à la fois la maintenance et la mise à niveau de vos applications.

4.Soutien

Un autre critère à ne pas négliger est la facilité à trouver des réponses à vos questions et à obtenir de l'aide. Identifiez le support disponible: auprès de l'éditeur. D'une communauté (listes de diffusion, IRC, etc.)? Des sociétés de services (développement, support, formation)?

5.Technique

Pour éviter d'être piégé dans un labyrinthe, il est toujours préférable de choisir une solution interopérable; celui qui respecte les meilleures pratiques en termes de développement (modèles de conception)

6. sécurité

Toute application est potentiellement vulnérable. Pour minimiser les risques, il est toujours préférable de sélectionner un framework capable d'assurer des fonctions de sécurité (gestion XSS par exemple).

7. documentation

Il est absolument nécessaire d'évaluer la nature, le volume et la qualité de la littérature existante sur un cadre: un outil bien documenté est à la fois plus facile à utiliser et plus évolutif.

8.Licence

Les licences sont importantes simplement parce qu'elles peuvent avoir un impact significatif sur vos applications. Par exemple, une application développée en utilisant un framework sous licence GPL sera nécessairement soumise à la GPL. En revanche, ce n'est pas le cas pour un cadre sous licence MIT.

9.Disponibilité des ressources sur le marché

Peut-être voudriez-vous qu'une équipe technique vous entoure pendant la phase de développement ou à plus long terme, pour la maintenance et les mises à niveau. En d'autres termes, assurez-vous que les compétences requises pour l'outil que vous utilisez sont disponibles sur le marché libre.

10.Essayez!

Voilà la clé! Ne vous contentez pas de lire des critiques, des commentaires et des rumeurs, bonnes ou mauvaises, sur Internet. En le testant, vous pourrez vous faire votre propre opinion et vous assurer que vous êtes parfaitement à l'aise avec l'outil.

La clé est la patience. Patience, patience, patience. Il n'y a aucun moyen de prédire l'avenir avec certitude. (ai-je même dû écrire cela?) Mais si vous donnez à la nouvelle technologie quelques années et regardez comment elle est adoptée, vous aurez une bonne idée de savoir si elle prendra racine et convient aux projets à long terme / investissement en temps .

Donc, quand le NextNewThing (tm) arrive, n'hésitez pas à sauter dans le train ... tout simplement pas pour quelque chose d'important au cours des deux premières années.

La réponse de Mikeras est plutôt sympa. J'ajouterai que la pérennité est vraiment une sorte de sécurité ou de gestion des risques. Il vous oblige souvent à renoncer à certaines commodités et avantages coût / productivité maintenant pour éviter des problèmes plus tard. Je fais de la technologie presque évolutive depuis un bon moment maintenant. Il existe certains modèles qui peuvent aider. En voici quelques-uns.

1. Les données doivent être stockées dans un format ouvert facile à extraire ou à transformer ultérieurement. Les formats de fichiers impairs sont une grande technique de verrouillage et une zone de piège en général. De plus, préférez des approches plus simples telles que CSV, ASN.1 ou JSON plutôt que des conneries compliquées telles que XML ou, disons, le format Word 97;). L'idée est qu'il est assez simple de rassembler un analyseur vous-même et que l'analyseur de format bas niveau est réutilisable dans toutes vos applications.

2. Idéalement, les applications devraient avoir des interfaces indépendantes du fournisseur et de la technologie, ainsi qu'une description précise de ce qu'elles font. Vous devez concevoir des éléments où vous pouvez modifier ou jeter l'implémentation sans rien casser. De plus, passer à une nouvelle plate-forme est facile si votre méthode d'appel de procédures ou de traitement de données fonctionne sur plusieurs plates-formes. Ainsi, les interfaces sont la chose la plus importante pour être correcte. Plus la méthode d'implémentation de l'interface est simple, rapide et ouverte, mieux c'est.

3. La pile doit être entièrement open source et libre de modification. Les licences GPL, LGPL, BSD, MIT, etc. conviennent parfaitement à cet angle. L'idée est que, si la communauté commence à disparaître, alors la pile devra peut-être être déplacée vers un nouveau [matériel / OS / protocole / etc]. Et vous avez besoin du code pour cela.

4. La conception de la pile doit être extrêmement modulaire, chaque pièce étant compréhensible par une seule personne. Cela permet à un nouveau groupe de le récupérer et de le maintenir plus facilement. Ayant même les niveaux les plus bas du runtime, les bibliothèques et le compilateur bien pris en compte peuvent avoir un énorme gain s'ils doivent être portés. Souvent, une seule partie peut être portée et tout votre ancien code fonctionnera.

5. Votre application doit être conçue de manière modulaire qui tient compte des détails de la plate-forme pour minimiser les retouches dans ce domaine. Il aide à structurer les fonctions en blocs d'entrée / traitement / sortie lorsque cela est possible également. Cela peut faciliter une analyse de ce qui sera affecté par un port (et une analyse d'exactitude en général à la méthodologie de la salle blanche). La plate-forme d'approche la plus risquée consiste à utiliser les fonctionnalités de dénominateur commun les plus faibles prises en charge universellement avec une interface qui vous permet de les utiliser, ce qui réduit encore le portage. (J'ai dit que tu perdrais quelque chose ...)

6. La dactylographie dynamique, l'inférence de type ou d'autres approches de dactylographie flexibles sont utiles. Un port vers une nouvelle plate-forme peut modifier les définitions des types de base. Les langues qui font un typage fort en interne signifient que vous vous inquiétez moins de ce genre de choses.

7. Gardez le modèle de concurrence simple. Axé sur les événements, le message passant par des interfaces claires est portable pour ... pratiquement tout. Il y a aussi des coroutines. Vous voulez simplement éviter les routes sujettes à la fois aux erreurs et aux problèmes de portabilité.

8. Regardez les runtimes portables de Mozilla et Apache. Ils prennent en compte de nombreux problèmes spécifiques à la plate-forme avec certains choix d'interface et d'implémentation. Ils peuvent vous donner des informations sur ce qui vous inquiète et vous fournir de bonnes solutions à de nombreux problèmes.

Exemple parfait: Tcl. Je sais, beaucoup de gens le détestent et je l'utilise rarement moi-même. Pourtant, Tcl est un langage extrêmement facile à comprendre, à mettre en œuvre (12 règles principales) et à coder. Il est petit, assez rapide, s'intègre aux serveurs Web, s'intègre dans des applications natives, a été porté sur des tonnes de choses, possède certaines fonctionnalités de sécurité , et a été régulièrement mis à jour depuis les années 80 lors de sa fabrication. Vous ou moi pourrions implémenter un runtime TCL complet en un rien de temps pour le langage principal. Si nous devions porter la bibliothèque standard, ce serait plus facile que de porter .NET ou Java. Et il y a pas mal de code utile écrit pour cela. Et il a été utilisé dans la technologie Web dès l'engouement des "agents mobiles" que les applets Java visaient également. Par exemple, le cadre Web OpenACS remonte à 1998 avec un serveur plus ancien que cela.

Autres exemples: BASIC, COBOL et LISP (Scheme ou CL). Ces langues remontent toutes vers les années 50 ou 60. Ils sont assez simples pour faciliter la compréhension, la mise en œuvre et la traduction mécanique. Pourtant, vous pouvez créer des trucs utiles avec eux. COBOL gère toujours la plupart des traitements de transactions dans le monde, a été mis à jour plusieurs fois et fonctionne même sur .NET. Les anciennes applications QBasic / QuickBASIC fonctionnent toujours aujourd'hui avec des outils ouverts / gratuits sur les plates-formes modernes, ainsi que des possibilités de portage vers de meilleurs outils comme GAMBAS ou RealBASIC. Les codeurs LISP rendent naturellement leurs systèmes modulaires et fonctionnels, facilitant le portage. Il y a eu un flux constant d'implémentations depuis des décennies, ouvertes et commerciales.

Ainsi, les interfaces, l'ouverture, la simplicité, la modularité et l'architecture / conception / codage indépendant de la plate-forme. CELA vous procurera la pérennité dont vous avez besoin. La plupart du temps, de toute façon.