Cet article s’adresse avant tout à toi, ô petit bizuth qui viens de passer ton bac et qui veut devenir dév. Et puis à toi aussi, ô ex-bizuth qui n’a pas encore eu son joli morceau de papier décoré diplôme d’informatique. Enfin bref il s’agit de vous présenter la réalité du métier de dév’ par rapport à ce qu’on vous montre à l’école.
Débloque les + belles offres tech en 10 mins
Alors évidemment, comme vous pouvez vous en douter, la réalité du métier de développeur est bien différente de ce qu’on vous enseigne. On va présenter deux cas :
– Soit vous travaillez sur un projet déjà existant (le plus probable).
– Soit vous travaillez sur un nouveau projet.
Dans les deux cas une constante : vos interlocuteurs, des gens bien pensants, ne comprendront rien à ce que vous faites, et comme ils pensent que c’est facile ils mettront une pression folle sur les délais… A la limite du « il faut le faire pour hier ». Et ça, forcément ça joue sur le métier. Sachez que généralement la méthode RACHE prévaut pour bien des choses… hélas. 🙁
Et donc pour ces gens bien pensants (et les actionnaires qu’il y a derrière…) un projet est considéré comme réussi s’il sort dans les temps, peu importe qu’il soit totalement buggé. Ca vaut particulièrement pour les projets au forfait, où en fait les entreprises font leur gras sur les contrats de maintenance. Un exemple typique de ce que tout ça engendre est le projet Chorus de l’Etat.
Vous travaillez sur un projet déjà existant
Vous commencerez très probablement à travailler sur un projet déjà existant. Il s’agit d’une bonne école pour voir ce qu’il faut faire et surtout ce qu’il ne faut pas faire. En effet, à force de rustines et de machins codés en vitesse parce qu’il faut absolument tenir la deadline de demain, le code ressemble souvent à ceci :
En fait là où c’est positif, c’est que vous apprendrez comme ça surtout quelles sont les choses à éviter. On pourra entre autres citer :
– L’héritage à outrance
– Les méthodes et fonctions de plusieurs centaines voire milliers de lignes
– L’absence complète de documentation et de spécification
– Pas de tests
Enfin bon bref, la foire, en grande partie en raison d’un manque de discipline et de la politique du « faut tenir avant tout les délais ». Le bon côté dans tout ça est que c’est très formateur et ça vous permettra de vous améliorer, non pas en raison des exemples que vous trouverez, il y en a rarement, mais surtout des exemples de ce qu’il ne faut pas faire, et c’est au moins aussi important.
Vous me direz : « mais alors, pourquoi ne refait-on pas ces projets à zéro ? ». La raison est double : premièrement ça coûte trop cher, et deuxièmement on doit garder la compatibilité avec l’existant, ce qui est très coûteux. Par ailleurs il y a le risque de régression. On pourra citer dans ce domaine le fameux Windows Vista, qui a été recodé de zéro et est sorti trop tôt, avec les résultats qu’on sait…
Vous travaillez sur un nouveau projet
Il y a peu de chances que vous ayez la chance de travailler sur un nouveau projet. En effet, pour ça il faut avoir un peu de bouteille pour ne pas répéter certaines erreurs. Néanmoins c’est probablement le truc le plus intéressant que vous pourrez faire dans votre vie de développeur, car il faut alors tout mettre en place :
- Choix de la techno à utiliser, même si c’est souvent imposé.
- Choix et mise en place des outils, notamment chaîne de compilation, serveur d’intégration continue, et ainsi de suite.
- Choix de l’architecture.
- Modélisation de l’application par rapport aux demandes métier.
Pour être honnête, ça ne m’est arrivé que deux fois jusqu’à présent. Bon une alternative à ça est un refactoring majeur d’applicatiion. Ca vous permettra au moins de refaire le design de celle-ci de fond en comble, voire parfois de changer la base technique de votre application, par exemple pour passer de PHP à Java.
Si on vous laisse assez de temps, ça vous permettra de fortement monter en compétence et vous offrira une certaine fierté d’avoir fait ce que vous avez fait. Par contre il faut que d’emblée vous vous imposiez, et que vous imposiez à vos collaborateurs une discipline pour éviter de tomber dans les travers des projets existants. On pourra garantir cette discipline par exemple en mettant en place des politiques d’analyse automatique de code avant commit, ou encore en faisant planter les serveurs d’intégration continue en cas de warning dans le code ou de test qui ne passe pas.
Mais par dessus tout, il ne faudra pas hésiter à vous comporter en vrai chien de garde sur le code, quitte à surveiller les commits. Dans l’idéal ce rôle de chien de garde doit être tournant entre les différentes personnes de l’équipe de façon à entretenir de la rigueur. C’est en effet à ce prix que votre application tiendra dans la durée, et ressemblera à ceci :
… en bref…
Le métier de développeur requiert une grande rigueur et une grande discipline. Par ailleurs, contrairement à ce qu’on pourrait penser, c’est un métier très complexe, mais qui n’est pas reconnu dans les pays latins, ce qui explique pourquoi de nombreux dévs traversent l’océan. (Perso je me contenterais de traverser le Rhin mais c’est une autre histoire…)
Toujours est-il que le plus dur est de faire appliquer cette discipline. Essayez de le faire tout au long de votre vie de développeur, vous ne le regretterez pas.
Quant à ce que vous avez appris à l’école, dans la réalité… vous pourrez en oublier 90% et ne retenir que le fait qu’on vous a appris à apprendre. Et ça, ne l’oubliez pas, c’est comme ça que vous tirerez votre épingle du jeu. Commencez dès maintenant en faisant par exemple l’effort d’installer un vrai système en multiboot sur votre ordinateur perso (voire carrément de dégager W—–s 😉 ).
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Un java-iste essaie de vous faire aimer son langage fétiche
- Choisir sa techno en fonction du salaire, une bonne idée ?
- Comment un manager peut-il (bien) challenger un développeur ?
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.
