“Être développeurs jQuery” a-t-il un véritable sens? Quelle est la différence entre un développeur, un développeur javascript et un développeur jQuery? Quand faut-il se présenter comme l’un ou l’autre de ces profils?

Un développeur jQuery

Mettre en avant l’expérience qu’on peut avoir sur un peut être une bonne idée dans certains cas. Déjà, ce mot-clef tapera dans l’oeil (et dans le RSS/la veille automatisée) des recruteurs. Si un client demande “un développeur sachant faire du jQuery (parce que c’est ce que le manager des codeurs a retenu)”, alors son “cabinet d’audit/conseil” (ouais, une SSII quoi… bref, une boîte d’intérim pour codeur) cherchera des développeurs avec ce “langage” dans leur CV. Du coup, oui, cela peut être intéressant pour le candidat de mettre cette expérience en avant.

Mettre en avant son expérience jQuery peut être utile pour se faire recruter.

Les problèmes de cette sur-spécialisation

L’oubli du langage de base

En fait, le véritable problème de ce genre de qualificatif réside surtout dans la confusion qui peut être faite par le développeur qui l’emploie: jQuery (ou Symfony, ou CodeIgniter, ou WordPress etc) ne sont pas des langages. Ce sont des frameworks (voire des bibliothèques de fonctions). Donc, tant qu’on demandera à ce développeur de faire des choses via ce framework, tout se passera bien. Mais si on veut prendre du recul, là, le développeur sera coincé à moins d’être aussi un “développeur javascript” en plus d’être un “développeur jQuery”).

La veille technologique

Et c’est sans compter l’autre problème de cet oubli du langage de base: à force d’être trop focalisé sur jQuery, le développeur peut en oublier la veille technologique au niveau du langage. Bon, soyons francs, c’est parfois le bout du monde si le développeur fait une veille technologique sur jQuery, mais la faire uniquement sur le framework n’est pas une bonne chose; Le développeur jQuery risque en effet de passer à côté de toutes les autres API récentes du javascript, comme querySelector ou les Media Queries event, qui simplifieraient énormément son travail. Ainsi, s’il s’enferme dans son jQuery, le développeur javascript risque de rendre son travail de plus en plus lourd et compliqué, alors que le framework était initialement là pour le simplifier.

Un framework peut simplifier la tâche à un instant T, mais il peut la rendre plus complexe le jour où le langage aura rattrapé son retard, et proposera directement la feature que le développeur souhaitait faire.

Prenez-vous environ une journée par semaine, pour faire uniquement de la veille technologique: explorez les nouvelles fonctions de votre framework, découvrez les nouvelles API et syntaxes de vos langages de base, et cherchez les avancées (et les classiques) en matière d’algorithmie.

Un développeur est un ingénieur

Pour moi, un développeur est avant tout un ingénieur, c’est à dire quelqu’un qui se verra présenter un besoin (d’un client ou d’un service interne d’une boite, ou bien son propre besoin dans le cadre des créateurs de jeux indépendants) et qui devra y répondre, soit directement par lui-même, soit en s’appuyant sur une sous-traitance (en matière informatique, “sur l’existant”, par exemple un framework). Du coup, le qualificatif “jQuery” devient gênant. C’est comme si un ingénieur des ponts et chaussées se prévalait d’être “ingénieur vissage cruciforme”. jQuery n’est qu’une façon de répondre à certains besoins. Trop mettre cette “spécialité” en avant risque alors de vous enfermer dedans. Cela peut être une bonne chose si un client a ce besoin spécifique, dont vous seul êtes spécialiste, mais dans le reste des cas cela vous desservira (et ce sera très souvent ces cas-là que vous rencontrerez, surtout sur une fausse spécialisation comme “jQuery”).

Vous êtes d’abord un ingénieur, et vous devez donc analyser les besoins puis y répondre de la meilleure façon: une sur-spécialisation (façon “développeur jQuery”) peut vite vous handicaper en vous coupant des autres pistes.

Êtes-vous dans le bon langage?

Enfin, si le développeur est avant tout un véritable ingénieur, il doit se poser la question suivante: pourquoi ai-je besoin de tel framework pour faire telle chose dans le langage que j’ai choisi? Parfois, le langage propose directement ce dont le développeur a besoin (par exemple, querySelector qui remplace avantageusement la fonction $(), sujette à de très nombreuses injections puisqu’elle sert aussi à interpréter directement du code HTML) et il n’est donc pas utile de recourir à un framework. Mais si le langage ne propose pas directement ce que le développeur souhaite faire?

L’usage d’un framework est-il justifié par la seule phrase “Le langage de base ne le permet pas directement”?

Non. En fait, pour bien comprendre le problème, il vous faut tourner la question dans l’autre sens: pourquoi le langage de base ne propose pas ce dont j’ai besoin directement? De base, je vous déconseille les langages, les frameworks, les serveurs “tout juste sortis” (moins d’un an, et encore, moins de 5 ans serait même mieux) car ils n’ont pas encore assez d’usure pour être véritablement utilisables dans des projets non-expérimentaux). Pour les autres, ceux qui ont du vécu, la question de savoir pourquoi ils ne remplissent pas directement votre besoin est intéressante, et elle débouche sur deux réponses possibles.

Vous n’avez pas choisi un langage adapté à votre besoin

Dans ce premier cas, votre besoin n’est pas ce à quoi le langage répond de base (et vous devez donc utiliser un framework pour qu’il y réponde). C’est le cas, par exemple, si vous voulez faire du temps réel avec la stack PHP/MySQL: ces deux langages ne sont pas étudiés pour cela, faut de notion évènementielle (au mieux, vous ferez de l’attente active avec ces outils, et ce ne sera donc franchement pas la meilleure solution). Dans pareil cas, la solution est sans appel: changez de langage (ou supprimez le besoin sous-jacent). N’allez surtout pas “patcher” un langage inadapté pour tenter de lui tordre le cou et faire ce pour quoi il n’est pas prévu (les perfs, la qualité du code, la fiabilité, le plaisir de coder, tout cela en serait grandement affecté).

Egalement, un langage peut ne pas intégrer une feature car celle-ci amène énormément d’autres problèmes derrière, qui ne sont pas justifiés. Par exemple, le temps réel dans un jeu n’est pas implémentable simplement en PHP+MySQL (à l’heure actuelle). Une des raisons de cette difficulté réside dans le fait qu’un temps réel nécessite une implémentation orientée “évènement” (interruption) qui n’est pas du tout dans l’optique de PHP (un langage de template à la base, ne l’oublions pas!). Du coup, ce genre de feature n’est pas simple à implémenter dans ce langage. En revanche, PHP est parfaitement adapté pour transformer des tableaux de données (sorties d’un MySQL par exemple) en une page HTML (il a été taillé pour cela).

Vous avez raté un morceau du langage

L’autre possibilité réside dans le fait que vous avez peut-être manqué un aspect du langage qui existe, qui répondrait à votre besoin, mais dont vous n’avez pas connaissance. Dans un pareil cas, votre framework va alors faire une redondance néfaste avec ces features de base, car vous allez perdre les autres développeurs qui connaissaient cette feature du langage, et vous risquez des effets collatéraux désastreux. Pour éviter ce genre de problème, renseignez-vous sur vos langages. Utilisez les ressources de ce blog pour essayer de découvrir de nouvelles API javascript qui répondent à votre besoin, de nouveaux sélecteurs CSS qui feraient le taff, ou des méthodes PHP/MySQL qui permettent de créer votre jeu facilement.

Vérifiez que vos langages de base ne permettent pas déjà de faire la feature que vous avez en tête: peut-être n’êtes vous pas au courant des dernières nouveautés de ces langages?!

L’exemple de L’Île du Coeur

Un exemple récent sur JeuWeb illustre ces difficultés à cerner un besoin et la complexité de l’équilibre entre ce besoin, l’algorithmie pour y répondre, et le langage qui l’implémentera. Un mauvais algorithme (une mauvaise vision de la façon de répondre au besoin) peut déboucher sur une mauvaise implémentation (c’est à dire, qui ne répond pas exactement au besoin: certains points du besoin ne sont pas résolu, mais aussi des effets collatéraux apparaissent). Il vous faudra donc concilier les trois pour obtenir un besoin pertinent, une réponse algorithmique exacte et une implémentation simple et claire.

Conclusion

En conclusion, n’oubliez pas que vous devez avant tout répondre à un besoin (l’informatique n’est qu’un outil et non une finalité de votre jeu web). Oubliez les fonctionnalités inutiles, et assurez-vous que celles qui sont utiles soient adaptées aux langages que vous utilisez (ou alors, adaptez ces langages à votre feature).
Prenez aussi du recul: votre analyse du besoin doit déboucher sur un bon algorithme, adapté à votre langage.
Enfin, un framework est un énorme ajout de complexité. Si vous ajoutez un framework à votre projet, considérez que vous l’avez vous-même codé. Cela vous donnera une idée de la montagne de complexité que certaines features introduisent parfois dans un jeu web. Si une feature complexifie trop votre code pour un apport négligeable à votre jeu web, alors oubliez-la.