Semaphore : de nombreux nouveaux projets commerciaux sont développés dans des langages qui ne sont plus supportés
Quelles en sont les raisons ?

Le , par Michael Guilloux

199PARTAGES

11  0 
À quel moment passez-vous à une nouvelle version d'un langage ?
Semaphore CI est un fournisseur de solutions de Continous Integration & Delivery. Il est également connu pour ses publications régulières sur les versions de langages open source qui sont utilisées dans des projets commerciaux. Pour l’année 2017, Semaphore CI vient de publier une compilation de différents rapports qui montrent quelles versions des langages open source populaires comme Java, Go, Node.js, PHP, Python et Ruby sont utilisées dans les projets commerciaux, nouveaux ou existants. Les données sont basées sur des milliers de projets privés qui sont testés et déployés sur Semaphore.

Le constat est que parmi ces projets commerciaux, nombreux sont développés dans des versions de langage qui ne sont plus prises en charge. La réalité diffère toutefois d’un langage à l’autre. Quel est le donc le constat pour chacun de ces langages et qu’est-ce qui pourrait expliquer cela ?

Java

Java 7 qui n’est plus supporté est encore utilisé par 17 % dans des projets commerciaux Java. La plupart des projets Java sont toutefois basés sur Java 8, ce qui est une bonne nouvelle puisque cette version est encore supportée. Par contre, Java 9 a été publié en septembre 2017, mais il semble qu'il ne verra aucune adoption significative parmi les projets existants. Oracle a annoncé que Java 8 sera une version LTS supportée jusqu'en 2022, tandis que Java 9 ne va pas bénéficier d'un support à long terme. Ceci, avec la nouvelle fonctionnalité de modularité qui demande un certain temps pour s'y habituer, est probablement ce qui pousse la plupart des équipes à attendre la prochaine version à long terme, Java 18.9 LTS qui devrait arriver en septembre 2018.


Node.js

Beaucoup de choses sont arrivées au runtime Node.js ces dernières années. Après avoir eu une adoption précoce, il a vu sa croissance ralentie, été forké, avant d'arriver enfin à une consolidation avec un nouveau calendrier de diffusion. En conséquence, la réalité est que près d'un tiers de tous les projets sont basés sur une version obsolète de Node, alors que moins de 10 % utilisent une version publiée en 2017 (v8 ou v9). Node 9 a été publié cet automne, mais Semaphore ne note pas encore d'adoption significative. Il est ici important de noter que c'est seulement depuis le mois de mars qu'AWS Lambda prend en charge la version 6.10 de Node.js alors que la version 0.10 de Node.js a été dépréciée fin avril. Cela peut-il expliquer en partie l'utilisation de versions Node.js non prises en charge dans les projets commerciaux.


PHP

PHP figure parmi les dix premiers langages les plus utilisés depuis des années, et il est présent côté serveur pour la majorité des sites accessibles aujourd'hui. La plupart des projets PHP (37 %) utilisent cependant la version 5.6, dont la période de support actif s'est terminée le 19 janvier 2017. Cette version continuera à recevoir des mises à jour de sécurité jusqu'à la fin de 2018. Les versions 5.3, 5.4 et 5.5, qui ne sont plus supportées, sont également utilisées dans 34 % des projets PHP. D'après Semaphore CI, cela peut être dû au fait que le processus de mise à jour de 5.x à 7.x est complexe. Par exemple, de nombreuses erreurs fatales ont été converties en exceptions, il y a beaucoup de changements dans la gestion des variables et des entiers, etc.

La version 7.0 est utilisée dans 19 % de tous les projets PHP. Cette version a été publiée en décembre 2015, et sa période de support actif a également pris fin depuis le 3 décembre. Quant à la version 7.1 qui a été publiée en décembre 2016, jusqu'à présent seulement 9 % des projets PHP l'utilisent. PHP 7.2 ne figure pas encore dans les statistiques de Semaphore, ce qui est normal puisque cette version a été publiée il y a un mois seulement.



Python

Malgré la sortie de Python 3 en 2008, plus de 70 % des projets commerciaux étaient encore basés sur la version 2.7 l'année dernière. Cette année, les résultats sont un peu meilleurs pour Python 3, mais pas beaucoup. Il faut noter que le support de Python 2.7 est encore maintenu de manière exceptionnelle jusqu'en 2020, en raison des difficultés de migrer de la branche 2.x vers Python 3.x. Il y a aussi le support de Python 2.7 par des fournisseurs. C'est le cas par exemple d'AWS Lambda qui prend en charge Python 3.6 et 2.7 depuis le mois d'avril.


Ruby

Il faut noter ici que plus de 85 % des projets Ruby utilisent la version 2.0 ou une version supérieure. D'après Semaphore, dans l'ensemble, il semble que dès que les équipes passent de 1.9.3 à 2.x, il devient plus facile de passer à des versions plus récentes.

Une chose importante à noter est que les versions 2.0 et 2.1 ont atteint leur fin de vie, ce qui fait que 33 % des projets Ruby utilisent des versions qui ne sont plus supportées. En outre, la fin de vie de Ruby 2.2 (utilisée dans 31,8 % des projets) est prévue pour le 31 mars 2018. Il est donc fortement recommandé de passer à des versions plus récentes, car les anciennes versions ne reçoivent aucune mise à jour de sécurité. Une autre chose que fait remarquer Semaphore ici est que Rails 5 ne supporte que Ruby 2.2.2 et les versions supérieures. Cela pourrait encore une fois indiquer que l'utilisation d'une version d'un langage dans les projets est en quelque sorte influencée par le support offert par les fournisseurs de technologie utilisant ce langage.


Go

La politique de publication de Go stipule que chaque version majeure de Go est supportée jusqu'à ce qu'il y ait deux nouvelles versions majeures. Ainsi, le graphique suivant montre que 60 % des projets Go commerciaux utilisent actuellement une version officiellement prise en charge (Go 1.7, 1.8 et 1.9).



Source : Semaphore

Et vous ?

Que pensez-vous de ces statistiques ?
Quand décidez-vous de passer à une version plus récente d'un langage ?
Avez-vous encore des projets développés dans des langages qui ne sont plus supportés ?
Si oui, de quels langages s'agit-il et pour quelles raisons ?

Voir aussi :

En 2017, Python 2.7 est plus utilisé (63,7 %) que la version 3.x dans les projets commerciaux, selon Semaphore CI

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 02/01/2018 à 10:46
Moi j'aurais mis "plateformes/runtimes plus supportés" et pas "langages plus supportés". Dire qu'un langage n'est plus supporté n'a pas grand sens.

La confusion est facile à faire en cette époque où même les créateurs font tout pour brouiller les cartes, mais la distinction est primordiale. L'écrasante majorité des versions de langage sont rétro compatibles. On casse rarement du code parce qu'on met à jour un runtime qui introduit une nouvelle version d'un langage. Au pire, des fonctions des bibliothèques de base (ou de bibliothèques tierces qu'on est obligé de mettre à jour) sont deprecated. On peut bénéficier de nouvelles primitives du langage qui sont introduites, mais on n'est jamais obligé de tout changer.

Langage
Bibliothèque
Framework
Runtime
Plateforme

Tous ces mots ont un sens, ce n'est pas pour qu'on les utilise à tort et à travers.

PS : Node.js n'est pas un langage
7  0 
Avatar de marc.collin
Membre éclairé https://www.developpez.com
Le 28/12/2017 à 16:56
Ces stats reflètent pas mal ce que j'ai plus voir depuis quelques années

Habituellement je teste la version la plus récente du langage assez tôt, cependant avant de l'utiliser dans un projet, je m'assure que la version du langage est bien supporté par les libraries, framework que j'utiliserais ainsi que l'environnement de développement.

J'utilise encore java 8, car il y a encore trop de problème avec java 9 concernant spring, netbeans, spring boot...
6  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 29/12/2017 à 10:13
Je suis assez en phase avec @marc.collin
Ce n'est pas parce qu'une nouvelle release du langage sort que l'ensemble de l'écosystème suit immédiatement (IDE, serveurs d'applications, frameworks, api, librairies, analyseurs de code, etc.).
Faut attendre quelques semaines / mois pour que l'ensemble de l'écosystème de dev et d'exécution se mettent à niveau et se stabilisent.

De plus, c'est vrai dans l'IT mais pas uniquement, il ne faut jamais se jeter immédiatement sur les nouveautés car y a forcément quelques bugs qui sont passés à la trappe lors des contrôles qualités (et rarement des petites choses).
On peut être sûr qu'on va avoir au moins 1 à 5 patchs correctifs dans les 2 mois qui suivent la publication de la nouvelle release.
Alors autant attendre un peu que ça se stabilise un peu.

Pour finir, comme l'a très bien dit @23JFK, faut aussi que les développeurs se forment ou soient formés (pour les chanceux dont l'entreprise payent des formations).
De même que les organismes de formations aient le temps de se mettre à jour...
Ainsi que les éditeurs qui publient des livrent sur le sujet pour compléter / expliciter les releases notes officielles parfois obscures.
6  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 02/01/2018 à 13:19
Citation Envoyé par koyosama Voir le message
Tu peux eviter cela en testant sur des nouvelles environnement si tu as fais le découpage de ton application et suivant les principes de développement modernes (je dirais ricains car ils sont pas vraiment moderne). C'est l'avantage du container, changer de langage à la volée ou revenir en arrière sur tel environnement.

Et si le projet est bien fait, tu dois avoir 4 niveaux de tests : test unitaires, test d'acceptance, test de performance et test de bout en bout. Et cela devrait couvrir les 70% de facteurs que tu as.
Sans compter qu'avec un approache 12factors, changer de language c'est comme changer de chaussette. Bien sûre Java 9 a tout pété, mais tu peux t'appuyer sur tests unitaires pour faire la modification aussitôts. Même grahique cela a un impact minim. J'ai vu des équipe qui sont passé de telles languages à telles langauges sur dexu ans car ils ont découpé correctement leur coder.
Ça, c'est la théorie et elle est parfaitement valide dans le monde merveilleux de la théorie où tout est possible car on a le budget, les ressources, le planning et les clients / utilisateurs qui suivent tous ensemble en harmonie.

Personnellement, en 12 ans de carrière pro, je ne l'ai jamais vu en place dans son intégralité.
En général, on fait le minimum syndical de la démarche qualité et de l'intégration continue car on n'a ni le budget, ni le planning pour.

Je viens tout juste de récupérer une application en plus à mon périmètre et je déprime sévère car il n'y a que 2 env. : la recette et la prod.
Les développeurs travaillent en local mais connectés à la BDD de recette
Mieux encore, il n'y a aucun flux qui tournent en recette donc on est obligé de faire un dump de prod vers la recette pour actualiser la BDD et conserver un jeu de données cohérents en recette...
La misère totale.
Des env. de travail pourri, j'en ai connu quelques uns mais là, on a franchi un nouveau palier.
Le pire, c'est que je ne suis même pas dans une petite PME mais au sein d'un grand compte et que les autres applications dont j'ai la charge sont tout de même mieux lotis.
5  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 04/01/2018 à 9:20
Citation Envoyé par Derek Corgan Voir le message
Les programmes développés (lorsqu'ils parviennent en production) ont une durée de vie nettement supérieure à celle estimée par leurs auteurs et je suis bien placé pour le savoir. De plus les auteurs n'assument que rarement la maintenance de leur bébé (car tâche non valorisée).
Je ne suis pas d'accord avec le fait que les développeurs n'assument pas la maintenance de leurs programmes car il s'agit d'une tâche non valorisée car en général, les équipes de Projet et de RUN sont distinctes.
En tant que Chef de projet et RA, j'impose une rotation entre la maintenance et le RUN, non pas par punition mais pour que chacun ait conscience des problématiques de chacun.
De plus, les développeurs sont nettement plus en contact avec les utilisateurs côté maintenance et cela est souvent sources de nombreuses idées pour améliorer significativement (et souvent à moindre coût) l'utilisabilité, l'ergonomie et donc l'adhérence de la solution par les utilisateurs.
Mais bon, cela demande une certaine organisation et beaucoup de mes collègues ne s'en donne pas la peine

Ensuite, en France surtout, les développements sont essentiellement réalisés par des prestataires et donc, lorsqu'un bug est identifié des années plus tard, ce n'est pas que le dev ne veut pas s'en occuper mais c'est que bien souvent, il a tout simplement changé de mission (que ce soit pour la même entreprise ou ailleurs).
Le tout, sans compter sur les évolutions professionnelles qui font que les personnes évoluent au sein de leur entreprise (et change d'équipe) ou d'entreprise (assez fréquent dans l'info en France).

Bref, rien à voir avec le fait d'assumer ou pas ses bugs ou encore de juger cela ingrat.
En tout cas, je ne l'ai jamais perçu ainsi.

Citation Envoyé par Derek Corgan Voir le message
Un bug peut survenir des années après le développement (car test mal effectué lors du développement initial).
Je te trouve particulièrement sévère.
Les causes peuvent être multiples (cas d'utilisation non prévu, évolution des librairies, etc.) et tout rejeter sur le développeur est simpliste et non justifié.
Un développeur est rarement seul.
Si il y a faute, elle est collective.
Je ne pourrais jamais bosser dans une ambiance où lorsqu'un problème survient, le premier réflexe est de chercher un coupable sur qui rejeter la faute pour s'en laver les mains (que la personne soit encore présente dans l'équipe ou partie depuis longtemps).
5  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 05/01/2018 à 16:15
Citation Envoyé par Saverok Voir le message
Ça, c'est la théorie et elle est parfaitement valide dans le monde merveilleux de la théorie où tout est possible car on a le budget, les ressources, le planning et les clients / utilisateurs qui suivent tous ensemble en harmonie.
Pour pas mal de boites ce n'est pas de la théorie c'est du réel. Des boites comme blablacar, doctolib, les-furets.com ont des pipeline de CI/CD qui permettent une mise en prod par jour voire plus du fait d'une stratégie de test appropriée. Je cite ces boites parce qu'elles se mettent en avant sur ces sujets dans des meetups / conférences ou via linkedin. Il doit y en avoir beaucoup d'autres.

Ce n'est pas tellement une question de budget, c'est une question de compétence et de conscience des coûts. Le problème initial remonte au client qui n'évalue ses coûts qu'à très court terme, il veut une feature, on lui donne le nombre de J/H nécessaire au dev, il multiplie par le TJM et il a son coût. Or ce calcul est une vue de l'esprit. Le client croit avoir le coût mais il n'a qu'une vision biaisée et court-termiste. Il paiera 5 fois le prix en bout de ligne mais il ne s'en rendra jamais compte car le reste des coûts sera invisible par rapport à sa manière de compter.

Une boite qui produit son propre service / logiciel / SI et qui maîtrise tout de bout en bout peut avoir cette vision. Ce n'est donc pas un hasard si les organisations qui s'adressent à des SS2I obtiennent de la merde, c'est normal elles achètent de la merde. Quand on achète un plat de lasagne à 2 euros 50 il ne faut pas s'étonner d'avoir de la viande de cheval à la place du bœuf.

Et c'est essentiellement de la faute de ces organisations, les SS2I ne font que répondre à une demande.

IMHO tout part de là. Les dirigeants de ces organisations sont incultes. Ils voudraient exister à l'ère de l'information sans informaticiens et c'est idiot.

Citation Envoyé par Saverok Voir le message

Personnellement, en 12 ans de carrière pro, je ne l'ai jamais vu en place dans son intégralité.
En général, on fait le minimum syndical de la démarche qualité et de l'intégration continue car on n'a ni le budget, ni le planning pour.
Moi en 12 ans j'ai déjà vu des trucs très propres dans des petites structures comme dans des grosses et des trucs ultra dégueux dans des petites comme dans des grosses. Et ce n'est jamais une question de budget, j'ai vu des budgets hallucinants engloutis pour produire une douzaine d'écrans juste parce que les décideurs sont des ignorants.

Après c'est certain que c'est rarissime de voir du propre et bien fait quand on est presta, c'est par nature incompatible.
5  0 
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 28/12/2017 à 18:34
Pourquoi ? D'une part par le manque de maîtrise pour le programmeur qui doit se taper la p'tite doc de 1000 pages (C++ toise les 1600 pages) en anglais qui accompagne chaque révision (les traductions arrivant une à deux années après... quand elles arrivent), Et d'autre part l’absence de recule quant à la fiabilité du nouveau bordel (c'est pas comme si l'industrie IT n'avait jamais connu de gros foirages lors de release/beta).
3  0 
Avatar de wolinn
Membre éprouvé https://www.developpez.com
Le 03/01/2018 à 11:06
Pour le C++, je passerai directement du C++ 11 au 17, sans avoir installé de compilateur pour la version intermédiaire 14, dont les apports étaient assez mineurs.
Par ailleurs, j'ai encore du code en C++ 98, qui a donc 20 ans, mais je ne réécris que lorsque cela apporte vraiment quelque chose au niveau des performances.
=> j'apprécie bien un langage préservant la compatibilité sur 15, 20 ans, et plus, j'ai autre chose à faire qu'à réécrire toutes mes librairies à chaque nouvelle version lorsqu'il n'y a pas de gains réels.
3  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 05/01/2018 à 17:30
Citation Envoyé par Marco46 Voir le message
Pour pas mal de boites ce n'est pas de la théorie c'est du réel. Des boites comme blablacar, doctolib, les-furets.com ont des pipeline de CI/CD qui permettent une mise en prod par jour voire plus du fait d'une stratégie de test appropriée. Je cite ces boites parce qu'elles se mettent en avant sur ces sujets dans des meetups / conférences ou via linkedin. Il doit y en avoir beaucoup d'autres.
Toutes les entreprises que tu cites sont des entreprises assez jeune (voir très jeune) qui ont été développé par et pour le web.
Autrement dit, elles ont l'informatique dans leur ADN.
Dans chacune de ces boîtes, tu as au moins un informaticien de métier qui fait parti du CODIR (si ce n'est pas l'un des fondateurs).

Dans les boîtes par lesquelles je suis passé (en presta ou en interne), c'est totalement différent car, pour commencer, elles ont plus de 50 ans (157 ans pour mon entreprise actuelle).
Bref, l'informatique n'est pas au coeurs de leur business d'origine.
Même si aujourd'hui le web devient extrêmement important, les métiers ne le voient tjrs pas comme une ressource / moyen / levier pour générer du business.
L'informatique n'est vu que comme un coût ou au mieux, comme un moyen de réduire les coûts tout en augmentant la productivité.
Mais absolument pas comme un axe business.

Du coup, normal que les investissements info soient effectués uniquement avec une vue court terme ce qui se paye cher par la suite et fait le beurre des SSII.

Vue la jeunesse du web, je pense que les entreprises incultes en info (avec les conséquences que l'on connaît) sont bien plus nombreuses que celles qui s'en sont pleinement investies.
3  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 08/01/2018 à 14:25
Citation Envoyé par Marco46 Voir le message
(.../...)Le software comme tu dis n'est pas une industrie. Le hardware oui mais pas le software. Un processus industriel c'est la production en série d'un même item, la production d'un logiciel en série ça s'appelle un copier coller d'un binaire. Le plus important dans la création d'un logiciel c'est le personnel qui écrit ce logiciel. C'est là que se situe toute la valeur. Or sous-traiter une compétence c'est la perdre. C'est donc une erreur majeure de sous-traiter l'écriture de ses logiciels, c'est une perte de contrôle totale sur le processus, on est même plus en mesure de contrôler ce qui est livré puisqu'on a sous-traité la compétence.
Avec une nuance : c'est une erreur si c'est ton cœur de métier. Si tu est un hôpital, c'est une erreur de faire toi même ton propre logiciel de gestion de la cafétéria. Mais si tu t'appelles Starbucks, c'est une erreur de ne pas le faire.

Mais d'accord sur le principe : la production logicielle(qui inclut l'exploitation, pas seulement la duplication) n'est pas aussi difficile que la conception, spécialement si on compare à l'industrie. L'inverse est vrai aussi, cf les soucis de Elon Musk pour produire en masse la Tesla. Il n'a pas ce genre de problèmes avec ses fusées, les cadences sont suffisamment lentes. En automobile, essayer de passer de 300 voitures mois à 3000 a suffi à le planter pour un bon moment.
3  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web