Discussion :

[Michael Guilloux]

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

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

[marc.collin]

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...

[23JFK]

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).

[Saverok]

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.

[koyosama]

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.

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.

Si tu as fais cela, cela devrait enlever pas mal d'effort et un meilleur isolation, et tu peux contenir tes erreurs. Regarde comment les développeur wordpress font, c'est pas parfait c'est 40% de la perfection mais quand tu as un module ou thème qui merde, tu changes le module ou le thème.

Même des connections spécifique pour un système d'exploitation, tu ne devrais pas avoir ce problème.

[Luckyluke34]

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

[Saverok]

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.

[el_slapper]

Ç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.

Et du ministère qui demande des délais délirants à nos clients, qui nous le répercutent, bien obligés. Et on se fait tancer par le grand chef américain parce-qu'on a pas respecté la procédure. Ben oui, si on prend le temps de la respecter, le client doit payer des centaines de milliers d'euros de pénalités au ministère. Et nous le répercute ensuite.

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.

Sans compter les résistants, hostiles à toute forme de structuration du travail, parce qu'ils ont peur d'être fliqués(à tort ou à raison, suivant les cas)

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 [/QUOTE]

Oh, chochotte, tu ne fais même pas les tests en prod, et tu te plains? - bon, honnêtement, ça ne m'est pas arrivé souvent. Mais ça m'est arrivé.

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.

Oui, ça, c'est la misère. Après, ça dépend de l'appli. En hospitalier, il y a très peu de batches, et le peu qu'il y a peut être lancés au besoin depuis l'interface, donc ça ne me manque pas, ici. En bancaire, par contre, c'était la catastrophe.

[Marco46]

Ç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.

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.

[Dwalin_7]

On attend un peu pour que les autres essuient les plâtres, puis on teste afin de valider que notre code existant fonctionne toujours, et que les nouveautés sont intéressantes.
En général ça bloque sur un des deux points et c'est comme ça qu'on laisse passer les versions.

[phlaffez2]

21 réponses: ce sondge n'est pas pertinent. 21 réponses ne peuvent refléter la réalité