14 mots et expressions pour parler comme un développeur web

Savez-vous décrypter le langage des développeurs web ? Retour sur quelques mots et expressions qui vous seront bien utiles pour comprendre le jargon des devs.

Si comme moi vous avez un lien avec le digital, vous avez certainement déjà entendu des conversations entre développeurs. Quand j’ai rejoint le milieu du digital/web, j’ai été parachutée dans un open space dont 95 % des occupants étaient des développeurs web. Et je ne comprenais rien, mais absolument rien, à ce qu’ils disaient (c’est encore le cas parfois … 😄) !

Je n’intervenais pas sur leurs projets et pourtant je trouvais ça hyper frustrant de ne pas les comprendre.

Alors je me mets à la place du client ou du chef de projet, qui n’a pas forcément de background technique, et qui se retrouve au milieu d’une conversation technique avec un développeur …

Voici un petit aperçu de ce langage bien mystérieux qu’on entend dans un open space rempli de développeurs... 

Tous les développeurs n'ont pas le même métier ... 

Commençons par le commencement : savez-vous faire la différence entre le front et le back ?

Je vous invite d'ailleurs à lire cet article sur le métier de développeur, publié par LA développeuse du groupe (oui, elles sont rares !).

Le front-end

C’est la face émergée du code, ce que voit l’utilisateur à l’écran et avec quoi il peut interagir : boutons, curseurs, menus, polices, animations … Le développeur front-end fait en sorte que le design de l’application soit en corrélation avec ce qu’a prévu le web designer en amont.

Il utilise des langages de programmation côté client (HTML, CSS, Javascript…).

Ses rôles :

• Demander des informations aux développeurs back-end et les afficher pour l'utilisateur ;
• Gérer les actions des utilisateurs ;
• Transmettre les informations/demandes au back-end.
  
  

Le back-end

C'est la face immergée des applications et sites web. Elle est invisible pour les visiteurs mais elle est absolument essentielle : c’est même le cœur de l’application. Sans back-end votre application s’apparenterait à une coquille vide !

Le développeur back-end utilise des langages de programmation côté serveur (PHP, Ruby, SQL…).

Ses rôles :

• Collecter des informations sur la base de données, les mettre en forme et les envoyer aux développeurs front-end ;
• Récupérer les informations envoyées par les développeurs front-end afin de les sauvegarder en base de données.

On parle aussi de développeur full-stack. C’est le petit génie celui-là ! Du front, du back, il sait tout faire …

Un petit conseil : ne faites surtout pas de comparaison entre les devs back et front, ça pourrait les vexer ! J’ai entendu dire que les développeurs front ne sont pas de vrais développeurs … (dixit un dev back 😋) Et côté back on ne sait pas coder sans créer de bugs (Guess what : dixit un dev front).

Git, leur outil favori !

Git ? Branche ? Pull ? Push ? Merge ? PR ? Prod ? Pré-prod ? et j’en passe … C’est le quotidien des développeurs : j’ai l’impression qu’ils ne parlent que de ça ! On pourrait y consacrer tout un paragraphe ! Ça tombe bien, c’est ce qu’on a fait !

Git est un système, open source, de gestion du code et des versions de celui-ci. C’est un outil collaboratif mais qu’on peut très bien utiliser même si on travaille seul sur un projet.

la branche Master

Si les développeurs travaillent à plusieurs sur un projet, ils ont une branche « master », la branche principale. Elle centralise le code « propre », prêt à être déployé sur les serveurs.

En général, c'est la branche qui est mise en ligne sur les environnements de « pré-production » (ou pré-prod pour les intimes), afin que les chefs de projet fassent leurs tests et vérifient que tout fonctionne bien. Une fois les tests validés, on déploie en production (« en prod ») pour les utilisateurs finaux.

MERGE SUR MASTER

Si on veut coder une nouvelle fonctionnalité, on crée une nouvelle branche qui part de « master ». On teste ensuite ce qui est fait sur cette nouvelle branche. Une fois que c’est validé, on « merge sur master » : on met cette nouvelle fonctionnalité à disposition de tous sur la branche principale. À ce moment-là, le développeur est tellement content d’avoir fait quelque chose qui fonctionne qu’il le crie dans l’open space « Ça y est, j’ai merge ! ».

Git push / Git pull

Quand on Git push, on met à disposition le code qu’on a développé sur sa propre machine sur une branche Git pour que tout le monde puisse y avoir accès si besoin. A l’inverse, on peut aussi récupérer un bout de code sur une autre branche : on fait alors un « git pull ».

D’ailleurs, parlons de « machine » : c’est un mot qu’on aime bien dans ce milieu. On pourrait croire qu’on est hyper modernes et tout ça, mais on parle quand même de son PC/Mac comme d’une machine ! C’est aussi certainement comme ça qu’on appelait le Minitel, jadis… (pour les plus jeunes : le Minitel, c’est ça).

« JE POUSSE MA BRANCHE !  »

Ça y est, la journée est finie, le code est propre et fonctionnel, je « pousse ma branche ».  En général il faut éviter de pousser directement sur master : on ne plaisante pas avec la branche principale ! Il faut préférer faire sa branche à soi et pousser son travail de la journée dessus, qu'il soit fini ou non, afin de le sauvegarder (ailleurs que sur sa « machine » au cas où elle prendrait feu dans la nuit…).

« J’ai poussé ma branche sur master », est parfois suivi de : « Mais b****l, qu’est-ce que t’as foutu ? ».

PR / PULL-REQUEST

Une fois que tout le code qu’il avait à faire est prêt, deux options s’offrent au développeur :

• Merger son code directement : je vous rappelle qu’il s’agit d’envoyer son code directement sur la branche principale. Il faut être vraiment sûr de son coup si on fait ça ! Le mieux est encore de ne pas choisir cette option 😅 ;
• Faire une pull-request (la fameuse PR !) : pour faire simple, elle permet de soumettre son code à quelqu’un d’autre (votre lead dev par exemple) afin qu’il le vérifie et le teste sur son propre PC. Si tout est bon, il valide la PR et vous donne son accord pour merger le code sur master.

Langage, framework, librairie

Je me suis vite rendue compte que je les confondais tous...

Je me disais : « Mais c'est pas la même chose tout ça ? Et React alors, c'est quoi ? Un langage de programmation ou un framework ? C'est peut-être une librairie... 🤔 ».

LANGAGE DE PROGRAMMATION

Souvenez-vous que les ordinateurs (les machines !) ne comprennent que les 0 et 1 : ce n’est pas simple de communiquer avec eux…

Les langages de programmation sont des langages informatiques qui permettent d’écrire des instructions qu’un ordinateur est en mesure de comprendre, interpréter et appliquer.

Cette suite d’instructions (les lignes de code) compose le programme (logiciel) que le développeur doit créer.

Il existe pléthore de langages de programmation. Les plus connus sont le JavaScript, Java, Python, C#, PHP, C, C++, Ruby... En général, un développeur maîtrise un ou deux langages de programmation. Je dis bien "en général" : certains n'en maîtrisent aucun 😜(elle était facile, celle-là !).

Le choix du langage dépend du type de projets : vous ne choisirez pas le même langage si vous développez un site internet ou une application mobile ou encore un jeu vidéo (on ne part pas en voyage en Espagne avec un dictionnaire Russe...).

FRAMEWORK / LIBRARY (ou LIBRAIRIE)

Je les aborde ensemble car le principe est assez similaire : on pourrait dire que le framework est une sorte de grosse librairie. Les deux ont pour but de faire gagner du temps et faciliter le travail de développement et/ou d'intégration. 

FRAMEWORK

Le framework est un ensemble d’outils configurés pour structurer le code, une sorte de patron, pour établir l'architecture du logiciel. Il n’est donc pas nécessaire de recopier les mêmes données au démarrage d’un nouveau projet puisqu’elles sont standardisées selon le langage de programmation utilisé sur le projet. 

Chaque langage de programmation a donc des frameworks différents puisque son modèle d'architecture lui est propre. C’est un peu la même chose avec nos langues à nous au final : en français pour faire comprendre qu’il s’agit d’une question on utilise « ? » mais en espagnol on utilise « ¿? ».

Quelques exemples de framework les plus connus : Symfony ou Laravel (pour Php), AngularJS ou VueJS (pour JavaScript), Django (pour Python) et bien d’autres…

LIBRAIRIE

La librairie, quant à elle, est une sorte de recueil de code prêt à l’emploi, pour coder rapidement des fonctionnalités, des modules, pour le logiciel. Pourquoi s’embêter à re-coder quelque chose qui existe déjà ailleurs ? 

Des exemples ? Bootstrap permet de ne pas re-développer la gestion du responsive, le design adaptatif entre mobile/desktop/tablette, à chaque fois. On a aussi Swiper pour faire un carrousel d'images sans avoir à taper toutes les lignes de code. Vous avez peut-être entendu parler de jQuery (une libraire Javascript) ?

Vous en voulez plus ?

"Vide ton cache"

Si le développeur effectue une modification dans le code il doit mettre à jour le cache/vider le cache sinon la modification n’apparaîtra pas... Parfois c'est simplement aussi bête que ça mais il faut quand même 15 minutes pour s'en rendre compte !

DB

La DB c'est la data base, autrement dit : la base de données ! Je ne vous apprends rien : dans des bases de données, on stocke des données !

Les bases de données se chargent elles-mêmes de créer, mettre à jour, supprimer, rechercher des données à la demande de l'utilisateur.

Vous entendez peut-être parler de SQL ou MySQL ? Ils permettent de créer des bases et des tables, interroger les bases, les mettre à jour, gérer les droits d'utilisateurs de la base ...

La différence entre ces deux-là ? MySQL est une version de SQL, une implémentation gratuite utilisable avec PHP notamment. SQL est aussi le langage de nombreux autres logiciels de base de données (PostgreSQL, Oracle...).

WEBSERVICE

Un webservice est un protocole qui permet à des applications de dialoguer à distance via Internet et d'échanger des données. Un logiciel peut alors appeler les fonctions d'un autre application. Les webservices communiquent par des requêtes HTTP et sont souvent invisibles pour l'utilisateur final !

CI / INTÉGRATION CONTINUE

CI et intégration continue, c'est la même chose. On dit « CI » pour Continuous Integration, soit « intégration continue » en français. Il s'agit simplement (enfin, c'est simple quand on a juste à l'écrire dans un article de blog...) d'intégrer les modifications apportées au code de manière continue afin de détecter les erreurs immédiatement et les corriger. On développe ainsi plus rapidement car on évite les mauvaises surprises. Sans intégration continue, on peut laisser passer une erreur commise plusieurs semaines ou mois auparavant. Corriger ces erreurs a posteriori serait d'autant plus compliqué et chronophage.

Si vous avez lu cet article jusqu'au bout, vous êtes désormais armé(e) pour cohabiter avec une équipe de développeurs 😉! Vous vous doutez bien qu'on aborde ici qu'une petite partie du langage des devs et qu'on vous épargne les notions très techniques. Mais pourquoi pas dans un prochain article...

Source illustrations : Commitstrip.com, le blog qui raconte la vie des cod

eurs !