Bon alors voilà, j’ai un problème : JobProd m’a demandé de jouer les voyantes. En fait ce n’est pas vraiment ma spécialité, il y a plein de grands Mediums qui pourront vous aider sur le sujet, mais quand même, on me demande de prévoir ce qui pourrait changer dans le métier de développeur à l’avenir. Alors bon, si je me plante, pas taper d’accord ? 😉
Dans la suite de l’article nous allons voir les évolutions possibles… ou pas, du métier de développeur dans les prochaines années.
Débloque les + belles offres tech en 10 mins
1/ L’intégration continue
Depuis quelques années on voit fleurir dans les entreprises des serveurs d’intégration continue, autrement dit des logiciels qui scrutent régulièrement les gestionnaires de versions et lancent des builds. Dans certaines sociétés on peut observer d’ailleurs des télévisions qui affichent en permanence l’état des builds. Le souci est qu’en fait on utilise rarement l’intégration continue à son vrai potentiel.
En effet les systèmes d’intégration continue ne font que vérifier régulièrement le gestionnaire de version et lancer les instructions qui leur sont données si des changements sont détectés. Actuellement la principale tâche demandée est de vérifier que le code soumis compile, sans pour autant valider a minima son fonctionnement. Et pourtant il est parfaitement possible de mettre en place des tests automatisés pour justement faire cette tâche. Et plus ceux-ci sont poussés, plus les développeurs ont un feedback fréquent sur leur travail et peuvent l’améliorer en conséquence.
Malheureusement, pour que ceci puisse se réaliser, il faut à la fois que les directions mais également les développeurs prennent conscience de l’intérêt de la chose. C’est loin d’être le cas partout. Et ensuite il faut des investissements pour les mettre en place, car pour ce faire il faudra généralement des refactorings conséquents sur les applications existantes. Bref ceci ne se fera sûrement pas partout, mais on peut espérer qu’au moins sur les nouvelles applications la tendance se généralise d’ici peu.
2/ Des environnements de développement proches de la production
Actuellement dans de nombreux cas les applications Web au moins fonctionnent sur un environnement *n*x. Or les développeurs travaillent très fréquemment sous W—–s, parce que les organisations n’ont pas les compétences nécessaires pour maintenir des parcs de machines de développement sous *n*x. Il est également vrai que les sysadmins *n*x coûtent bien plus chers que ceux pour W—–s.
Malheureusement, le comportement des applications, même développées pour des technologies dites multiplateformes comme Java ou PHP, varie fortement. Ainsi comme sous beaucoup d’*n*x les systèmes de fichiers sont sensibles à la casse, ce qui n’est pas le cas sous W—–s, ça peut être une source d’erreurs et de comportements inexpliqués lors de la mise en production. Par ailleurs cela peut aussi avoir des impacts sur la performance, les systèmes d’exploitation hôtes ne réagissant pas pareil pour un même stimulus envoyé par les applications. Et c’est comme ça aussi qu’on se retrouve actuellement avec des codes indiquant « si je suis sous Windows alors, sinon« , ce qui ne devrait tout simplement pas existé dans une application visant une plateforme particulière.
3/ Le packaging des applications
De nombreux développeurs, mais également personnels encadrants, considèrent que le travail est fini du point de vue développement quand on a fait son commit. Là encore c’est une erreur, car en fait ce n’est que le début. En effet les applications doivent ensuite être testées, puis, autre étape critique, être correctement packagées.
On voit en effet encore trop souvent des fichiers .class livrés en vrac sur les serveurs de prod, et après des équipes qui passent des nuits blanches à tenter de faire fonctionner cette p#?-!~ d’application qui marche pourtant sur le poste du développeur. Bref l’intérêt du packaging est notamment de travailler sur des processus de déploiement complètement reproductibles, ce qui fait qu’on est capable de monter une machine en quelques minutes.
Alors certes il existe un terme à la mode pour ça, « devops », mais finalement ce n’est que du bon sens qui devrait être en application depuis des années et qui économiserait des arrachages de cheveux. Mais là encore cela nécessite d’investir un minimum, et ensuite de familiariser les équipes avec ces pratiques. La deuxième étape sera probablement plus simple à atteindre que la première dans un certain nombre d’organisations naviguant complètement à vue.
4/ La manière de travailler
Le terme « agile » est très à la mode, mais en fait dans de nombreuses organisations ça se résume à presser au maximum les gens pour qu’ils fassent en trois semaines ce qu’ils faisaient en six auparavant. Or l’agilité est au contraire faite pour améliorer le bien-être des équipes et par la suite la qualité des livrables.
Là encore pour que la prise de conscience se fasse il faudra probablement… de nombreux programmes sortant dans un état catastrophique. En effet la mise en place des bonnes pratiques agiles est avant tout un exercice de management, avec la collaboration des développeurs, mais il nécessite par dessus tout que les directions aient bien compris de quoi il s’agit. Or tant que l’image auprès de celles-ci est « on fait en trois semaines ce qu’on faisait en six » on ne pourra pas changer grand chose. Ce n’est que lorsque l’état de certains projet sera trop dégradé qu’on pourra espérer une remise en cause.
5/ La généralisation des technos du Web côté client
La mode est de plus en plus à créer des applications clientes reprenant largement les technologies du Web. En fait ça a commencé même avant Windows XP, dont certaines applications étaient basées sur la technologie HTA.
Il est vrai que ces technos ont de très bon côtés, notamment les possibilités de rendu qui sont bien supérieures à ce qui se fait de manière classique, maintenant elles en ont aussi de très mauvais, en particulier le fait que les moteurs HTML se comportent parfois vraiment de manière différente. De même les écosystèmes pour les tests automatisés ne sont pas encore très développés sur ces technos.
Mais il faut reconnaître que sous Windows avec les applications dites « universelles » de Windows 8+, sous KDE avec les plasmoïdes et sur les téléphones mobiles l’usage de Javascript s’est fortement généralisé. J’espère juste maintenant que le langage évoluera suffisamment pour que coder avec devienne vraiment agréable et ne ressemble plus à ceci. Cela dit il faut reconnaître que de nombreux progrès ont été faits récemment, espérons que ça continue.
La chose à retenir est que tout développeur qui se respecte, même ceux qui n’aiment pas Javascript et dont je fais partie (oui je suis vieux :-p ), doivent savoir manipuler un minimum ces technologies car elles représentent probablement l’avenir côté client.
6/ La fin des applications clientes autonomes
Bon là encore la démarche est lancée depuis longtemps, mais les applications qu’on a sur nos ordinateurs nécessitent de plus en plus souvent un accès à Internet pour fonctionner, ou du moins fonctionner à plein potentiel. Ca signifie que les développements se font et se feront aussi beaucoup côté serveur à l’avenir.
Ce point est plutôt positif car on peut espérer que ça permette un découpage propre entre d’un côté les interfaces homme-machine, côté client, et de l’autre les traitements métier côté serveur.
Le mot de la fin
Je me trompe peut-être, mais je pense sincèrement qu’un développeur voulant s’inscrire dans la durée devrait s’intéresser aux choses suivantes :
– Les (vraies…) méthodes Agile
– Le fonctionnement en mode devops
– Les technos du web, en particulier Javascript, HTML et CSS
– Deux technos différentes côté backend, par exemple Java et PHP, car on ne sait jamais, l’une peut toujours pérécliter et dans ce cas il faudra la remplacer par une autre.
Dans tous les cas ne vous focalisez pas sur la dernière mode en cours car il s’agira bien souvent d’un feu de paille qui sera oublié un an plus tard. Suivez au contraire les tendances de fond, quitte à sembler avoir deux ans de retard. Pour rappel dans le monde Java beaucoup d’organisations n’en sont pas encore à Java 7, donc elles se moquent un peu de savoir que Vert.x existe… Et d’autre part d’une mode à une autre on se rend souvent compte que les concepts sont les mêmes, à peine remis à jour. Il n’y a en fait guère que les frameworks Javascript pour lesquels cette consigne ne s’applique pas, et encore, l’important est de pouvoir vite apprivoiser les frameworks, pas forcément de les connaître.
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Soyez (vraiment…) agiles
- La démarche devops
- L’intégration continue
- 2014 sera Javascript ou ne sera pas
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
