Les 8 détails techniques que j’aurais aimé connaître avant de commencer mon premier job

Terminal commandes

Quand j’ai commencé mon premier travail en tant que développeuse, les premiers jours étaient particulièrement difficiles. Premièrement, c’était mon premier “vrai” travail, j’étais engagée en CDI et j’avais l’intention de faire bonne impression. Ensuite, il faut retenir tout un tas de trucs, comme le nom de ses collègues, comprendre comment l’entreprise fonctionne et tout l’environnement technique du métier. Et c’est là que j’ai remarqué un énorme manque par rapport à ce que j’appris dans des cours en ligne. Il me manquait tous les termes techniques utilisés en entreprise. Quand tu travailles, tu ne te rends plus compte, ce sont désormais des mots courants de ton vocabulaire. Mais les premiers jours ! Honnêtement j’avais l’impression qu’on me parlait une autre langue. Donc si toi aussi tu es en formation ou sur le point d’en terminer une, je te conseille d’avoir vu ces termes au moins une fois avant ton premier jour. Voici la liste des 10 aspects techniques que j’aurais aimé connaître avant de commencer mon premier emploi :

1. Comprendre Git

J’avais déjà suivi un cours théorique et j’avais déjà pushé quelques commits sur mon repo GitHub, mais j’étais seule sur ma branche master. C’est une fois que tu travailles à plusieurs que tu comprends réellement l’intérêt de Git. Mais rassure toi, au début tu n’auras pas à connaître toutes les commandes (il y en a ~ 150 selon la version que tu utilises, un petit git help -a te permettra de vérifier par toi même).

Commence par gérer Git en lançant les commandes directement via ton terminal, ce qui te permettra de comprendre exactement ce que tu fais. Puis, une fois que tu maitriseras mieux, tu pourras utiliser un outil pour gagner en rapidité. Il te permettra également, en un coup d’oeil, de voir directement l’état des branches actives sur le projet. Les outils c’est bien ça permet d’être plus efficace mais attention à ne pas devenir dépendant. En théorie, un développeur peut coder avec un terminal uniquement. Personnellement, j’utilise “Fork” qui me permet de voir facilement et rapidement où en est le projet et quelles ont été les modifications depuis le dernier push. Voici les quelques commandes de bases bien utiles quand on arrive sur un projet :

  • git add, git commit -m "message", git push : le tiercé gagnant
  • git pull
  • git reset [HEAD --hard]
  • git checkout [feature/branch]
  • git branch [feature/branch]
  • git checkout -b [feature/branch] : le combo
  • git status
  • git merge [master]
  • git stash : une de mes préférés

Pour savoir ce qu’elles font exactement, je te laisse lire la documentation :

La ressource officielle complète se trouve ici : git-scm.com, très complet et utile si tu recherches une commande très spécifique.

Sinon je te recommande cette fiche officielle de GitHub en français qui résume les principales commandes utilisées.

Si tu es plus visuel, tu peux utiliser ce site que j’ai trouvé très intéressant :

Git Cheatsheet Interactive

2. Savoir ce qu’est un IDE

Les premiers jours, on m’a demandé de choisir un IDE. Quand je me suis renseignée, j’ai vu que c’était un logiciel pour éditer du code. Alors je me suis dit, ok je n’ai qu’à télécharger “Sublime Text“, le logiciel sur lequel j’avais démarré mes premiers projets HTML/CSS/PHP. Je le trouvais agréable, simple et efficace. Mais ça c’était avant de découvrir ce qu’était vraiment un IDE. IDE pour “Integrated Devopment Environment” est un logiciel qui permet d’écrire du code (ça semble logique…), généralement adapté pour le langage utilisé, mais il permet aussi de tester l’exécution de son code, de débugger efficacement son code et intègre l’autocomplétion. Mais attention à ne pas se reposer trop sur cette fonction, Comme dit plus haut, il faut aussi comprendre pourquoi ce sont ces fonctions qui sont proposées lors de l’autocomplétion.

C’est surtout lors du débugging que le miracle s’opère 😍. Avant je faisais des print(‘ma variable’) pour pouvoir afficher le contenu d’une de mes variables, mais avec xdebug plus de print, il suffit simplement d’activer le mode debug et cela nous permet de voir le contenu des variables en exécutant simplement le script :

PHPStorm Debugging
Source: screenshot https://www.jetbrains.com/fr-fr/phpstorm/

Il y a deux grandes écoles pour le choix de l’IDE. Ceux de l’entreprise JetBrains (spécifique pour PHP, Python, Web, Java… payants) et VisualCodeStudio (gratuit). Personnellement, j’utilise PHPStorm (pour PHP) et PyCharm (Python), mais c’est une question d’habitude.

3. Agile / Scrum

Mon deuxième jour a commencé avec un daily à 9h et un sprint planning à 14h. Je peux te dire que j’ai pas trop compris ce qui était en train de se passer, ni l’intérêt de certaines tâches… Si tu travailles avec des méthodes agiles, il faut au moins connaitre les concepts.

Tu verras des termes comme Scrum Master, Retro, Backlog, Sprint planning, PO (product owner). Mais surtout, il est important de ne pas confondre Agile et Scrum => Agile =! Scrum. Une équipe travaille de façon agile en utilisant une méthode scrum.

Agile représente la manière de gérer un projet, c’est un ensemble de méthodes et pratiques basées sur les valeurs et les principes du Manifeste Agile, qui repose entre autre sur la collaboration, l’autonomie et des équipes pluri-disciplinaires.

Scrum est un framework qui est utilisé pour implémenter la méthode Agile de développement et de gestion de projet. Il y a donc plusieurs autres méthodes pour travailler de manière Agile, il n’est pas nécessaire d’utiliser Scrum. Pour ça, tu peux suivre les deux cours d’Openclassrooms qui sont très bien pour démarrer :

Et encore un petit schéma pour avoir une vue d’ensemble :

Schema Explicatif Scrum
Source: https://blog.myagilepartner.fr/

4. Utiliser le terminal et comprendre l’arborescence des dossiers

Dès tes premiers jours, il te faudra naviguer facilement à l’intérieur de ton terminal, surtout que tu vas devoir installer pas mal de choses avant de commencer à réellement travailler. Les commandes dépendront de ton système d’exploitation (Windows vs MacOs / Linux). 

  • Voici les commandes qui sont les plus utilisées (MacOs / Linux) : Commandes Unix
  • Voici les commandes qui sont les plus utilisées (Windows)  : Commandes Windows

Conseil : la commande history est très utile pour voir les anciennes commandes que tu as exécutées, surtout quand on ne souvient plus comment résoudre un problème auquel on a déjà été confronté 😄

En ce qui concerne l’arborescence des dossiers, il faut faire la distinction entre :

  • ~ : ce caractère est un alias pour le répertoire HOME de l’utilisateur (/Users/<utilisateur> pour MacOS, /home/<utilisateur> pour Linux et <root>\Users\<utilisateur> pour Windows)
  • / : ce caractère représente la racine de ton disque dur si tu es sur ta machine, sinon de ton environnement (si tu es dans une machine virtuelle)
  • Chemin relatif : absence de caractère initial, il récupère le dossier/fichier à partir du répertoire courant, c’est-à-dire depuis là où on se trouve actuellement (ex. repo/projects)
  • Chemin absolu : caractère en préfixe du chemin, il récupère le dossier/fichier en partant de la racine, c’est-à-dire qu’on peut l’utiliser depuis n’importe quel répertoire (ex. ~/repo/projects)
Terminal commandes

D’ailleurs comme c’est un outil que j’utilise quotidiennement, je l’ai un peu amélioré pour le rendre plus lisible (j’utilise iTerm pour MacOs). Si ça t’intéresse, je pourrais faire un tutoriel pour personnaliser le terminal 🙂

5. Les permissions sur les dossiers/fichiers

Les permissions peuvent être très utiles, surtout dès que vous devez gérer certains dossiers/fichiers sur des serveurs Linux. Les permissions seront représentées en octal avec un chiffre pour chaque droit (lire, écrire ou exécuter) selon la catégorie à laquelle appartient l’utilisateur. Il peut être : 

  • u (user, utilisateur) représente la catégorie “propriétaire”
  • g (group, groupe) représente la catégorie “groupe propriétaire”
  • o (others, autres) représente la catégorie “reste du monde”
  • a (all, tous) représente l’ensemble des trois catégories

Et ils sont représentés sous la forme :

[rwx][rwx][rwx]
[---][---][---]

[ u ][ g ][ o ]

Par exemple, sur un fichier on a : 

rwx------     todolist.pdf

Dans ce cas, seul la catégorie “user” pourra lire, écrire et exécuter le fichier todolist.pdf.

Voici un petit récapitulatif très pratique : 

  • 0 : - - - (aucun droit)
  • 1 : - - x (exécution)
  • 2 : - w - (écriture)
  • 3 : - w x (écriture et exécution)
  • 4 : r - - (lecture seule)
  • 5 : r - x (lecture et exécution)
  • 6 : r w - (lecture et écriture)
  • 7 : r w x (lecture, écriture et exécution)

Dans notre exemple, pour ajouter davantage de permission à la catégorie “group”, il faudra ajouter : 

Pour “user”, on veut rwx donc : 4+2+1 = 7
Pour “group”, on veut rwx, donc : 4+2+1 = 7
Pour “others”, on veut donc : 0+0+0 = 0

Et il suffira de changer la permission avec (sudo) chmod 770 pour donner tout les droits aux catégories “user” et “group”

Ressource : cette documentation, spécialisée pour Linux te permettra de comprendre et gérer les permissions sur un serveur.

6. Le déploiement

Connaitre le jargon de la gestion de projets en entreprise est capital :

  • Déploiement : c’est le fait de migrer et d’ajouter des modifications vers un un nouvel environnement 
  • Sync (synchroniser) : c’est le fait de récupérer tout le contenu (fichiers, bases de données et fichiers) d’un un environnement vers un autre environnement.
  • PROD (production) : c’est le site live, celui qui est actuellement utilisé par des utilisateurs. En général, la production suit la branche master donc ne commit pas des changements non validés sur cette branche. Tout ce qui est sur master est en général propre et fonctionnel.
  • TEST, STAGE, DEV : le nom peut changer selon les équipes. C’est l’environnement où le client et toi pouvez tester les nouvelles implémentations dans des conditions se rapprochant au maximum de la production. Normalement, pour chaque implémentation, tu devras créer une branche dédiée et la merger sur l’environnement test pour que le client puisse vérifier que tout fonctionne.
  • LOCAL : c’est l’environnement que tu as sur ta machine.

7. Les environnements de développement

C’est toujours bien d’avoir une idée des environnements dans lesquels tu développes avec ton équipe. Personnellement, j’ai commencé à utiliser Vagrant puis nous sommes migrés nos projets sur Docker. Voici un schéma qui permet de voir la différence entre container et machine virtuelle :  Edit media Image

Différences Virtual Machine vs Conteneur
Source: https://www.alibabacloud.com/

Comme tu peux le voir l’avantage d’un conteneur c’est qu’il utilise le système d’exploitation de ta machine pour exécuter ses applications, il est donc beaucoup plus léger et performant. En effet, une machine virtuelle est comme un serveur physique indépendant, il a besoin de son système d’exploitation, d’un processeur central (CPU), mémoire vive, disque de stockage, carte réseau… Elle consomment donc pas mal de ressources simplement pour fonctionner. 

Les conteneurs, quant à eux, permettent de séparer les applications en plusieurs services qui communiquent entre eux (par exemple, pour un simple projet web, on aura un service pour Apache et un service pour MariaDB). Chaque application se trouve dans son propre conteneur, ce qui permet de faire des modifications ou les arrêter sans que ça impacte les autres applications. 

8. Le principe de clés SSH

Dans cette partie, tu n’as pas besoin de connaître en détail chaque utilisation des clés SSH. Mais il y en a au moins deux que tu utiliseras chaque jours : pour communiquer avec Git et avec les serveurs. C’est un peu comme des mots de passe mais avec une authentification beaucoup plus forte. Généralement, on parle de clés asymétriques car on travaille avec une paire de clés (qui se trouvent en local sous ~/.ssh) :

  • la clé publique (id_rsa) : quiest connue de tous et est mises à disposition sur Git ou sur un serveur
  • lclé privée (id_rsa.pub) : celle-ci t’appartient personnellement et ne doit jamais être diffusée.

Ces deux clés sont liées et se reconnaissent entre elles. 

Dans les paramètres de GitHub (SSH et GPG Keys), tu peux ajouter ta clé publique qui te permettra d’être authentifié à chaque connexion vers ton compte GitHub. Idem, lors de la connexion à un serveur (c’est généralement le sysadmin qui ajoutera ta clé publique directement dans le serveur).

Ressource officielle Git : git-scm.com

Maintenant tout ce qui est listé me semble évident mais au début j’avais l’impression qu’il me manquait certains détails pour démarrer en entreprise. Peut-être que cet article pourra aider d’autres futurs développeurs à ne pas se sentir sous l’eau dès le premier jour. ​

Si vous avez aimé l'article, n'hésitez pas à le partager :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *