90 lines
3.7 KiB
Markdown
90 lines
3.7 KiB
Markdown
# Les pieds dans le code
|
|
|
|
Pour mettre les pieds dans le code, une manière qui me semble bien fonctionner,
|
|
c'est une alternance d'exercices et de projets.
|
|
|
|
## Choix d'un langage de prédilection
|
|
|
|
Il me semble important, au moment d'apprendre à programmer, de choisir un
|
|
langage de prédilection. Et cependant, je tiens à ce que l'apprentissage se
|
|
fasse sur la programmation, et non sur la syntaxe. Pour la syntaxe, des site
|
|
commr [Learn X in Y minutes](https://learnxinyminutes.com/) sont bien
|
|
suffisant. Et il y a aussi le code que d'autres ont fait sur le projet.
|
|
|
|
Apprenre à programmer signnifie donc être en capacité de lire du code, de
|
|
comprendre ce code. Pour y arriver il me semble qu'il faut :
|
|
|
|
- savoir reconnaitre les mots clefs du langages, les litéraux, et les éléments
|
|
choisi par l'équipe de développement
|
|
- savoir visualiser les structures (boucle, condition, fonction, bloc cohérent
|
|
de code, ...)
|
|
- avoir une représentation mental de l'état de la mémoire
|
|
|
|
|
|
Pour choisir son langage, le plus intéressant serait de regarder où vous voulez
|
|
aller travailler ensuite et choisir les piles technologiques qui correspondent
|
|
à celles utiliser par l'équipe que vous voulez rejoindre. Ça me semblele
|
|
meilleur choix.
|
|
|
|
Vous pouvez aussi choisir un langage plutôt qu'un autre parce qu'une personne
|
|
proche va pouvoir vous aider dans votre apprentissage.
|
|
|
|
|
|
## Exercices
|
|
|
|
Permettant de prendre le temps de la répétition, de ralentir, de travailler sur
|
|
du petit. Les exercices permettent de travailler les reflexes.
|
|
|
|
Tout les sujets de Katas sont des bon exercices pour moi. Il en existe d'autres
|
|
également. Voici une petite liste de source possible
|
|
|
|
- [Coding dojo](codingdojo.org/)
|
|
- [cyber dojo](https://www.cyber-dojo.org/)
|
|
- [exercism.io](https://exercism.io/)
|
|
- [Projet Euler](https://projecteuler.net/)
|
|
- [codewars](https://www.codewars.com/)
|
|
- [Sphere Online Judge](https://www.spoj.com/)
|
|
- [les exercices de
|
|
recrutement](https://github.com/Rookie-Club/entretiens-test-technique)
|
|
|
|
Le principe, c'est de se donner une heure et une page blanche.
|
|
|
|
Au début, vous allez avoir l'impression de faire toujours la même chose, c'est
|
|
que les premiers pas ne sont pas encore des automatismes. Et puis, viendra le
|
|
moment où vous irez plus loin, parce que certains automatisme seront là. Vous
|
|
entrainerez de nouveaux gestes.
|
|
|
|
|
|
## Projets
|
|
|
|
Pour mettre en perspective ce qui a été découvert, appris durant les exercices.
|
|
|
|
Il y a plusieurs étapes d'apprentissage autour du projet. Le fait de retrouver
|
|
les gestes acquis durant les exercices arrivent dans un second temps.
|
|
|
|
|
|
Apprendre à:
|
|
|
|
- naviguer dans un projet
|
|
- lire le readme
|
|
- installer un projet avec ces dépendances
|
|
- peut-être faire une première proposition de modification ou de création d'une
|
|
documentation d'installation (fichier README ou INSTALL, ou autre)
|
|
- executer les tests s'il y en a
|
|
- executer le projet
|
|
- peut-être (encore) faire une proposition de modification ou de création d'une
|
|
documentation lié à l'environnement de dev (comment executer les tests ?
|
|
Comment contribuer ? comment lancer le serveur en environnement de dev ?).
|
|
Parfois trouvé dans les fichier CONTRIBUTING ou autres
|
|
- choisir un bug parmi la liste (ce qui est aussi valable, c'est de prendre LE
|
|
bug qu'on arrive à comprendre)
|
|
- reproduire le bug en question
|
|
- chercher une solution
|
|
- la mettre en place en respectant les standards du projet (ou faire une
|
|
proposition qui dépasse les standard du projet. Par exemple, ajouter un test
|
|
alors qu'il n'y en avait pas, c'est plutôt chouette :))
|
|
- faire une demande de modification.
|
|
|
|
_demande de modification_ c'est les pull request sur github, les merge request
|
|
sur gitlab, et peut-être un autre nom ailleur.
|