Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Sondage : quels sont les conseils pour débuter en tant que développeur de logiciels ?
Partagez votre expérience

Le , par Bill Fassinou

259PARTAGES

10  0 
Sondage : quels sont les conseils pour débuter en tant que développeur de logiciels ?
Existe-t-il une méthode universelle ou une méthode pratique pour réussir ses débuts en tant que développeur de logiciels ? Beaucoup de bouquins vont dans sens, mais chaque développeur finit par se faire son propre avis après quelques années d’expérience dans le domaine de l’ingénierie. En fait, il en vient à dresser une liste de quelques habitudes qui, d'après lui, permettent de grandir plus vite et de manière ciblée, et qu’il aurait aimé connaître dès ses premiers pas en tant développeur professionnel de logiciels. Voici une liste de règles recueillies dans la communauté.

Lire au moins deux livres par an sur le génie logiciel

Il y a un très grand nombre de livres de génie logiciel, et ce, dans un nombre très élevé de langages de programmation. Selon les personnes à l’origine de cette recommandation, chaque fois qu’ils ont donné de leur temps pour lire lentement et complètement un livre conseillé sur l'ingénierie logicielle, cela les a fait progresser. Il ne s’agit pas en effet de lire des bouquins pour se constituer un palmarès. Mais ils conseillent qu’en lisant, il faille prendre des notes, discuter des chapitres, griffonner des paragraphes, essayer des choses, et si possible revenir en arrière pour relire certaines choses.

Dans le choix des livres, il faut éviter les livres datés et surtout, vous devez rechercher des livres qui vont plus loin que ce que vous savez maintenant. Il peut s'agir d'un bouquin sur une technologie spécifique ou sur les pratiques du génie logiciel. Ils déconseillent aussi de lire des livres via des blogues, des vidéos, etc. Selon eux, ces canaux sont juste complémentaires aux livres. Ils sont des formats courts qui parcourent la surface, contrairement à un livre qui va en profondeur. D’après eux, les livres sont des connaissances approfondies et bien organisées. Enfin, il y a une dernière étape.

Elle consiste à rédiger des critiques sur un livre une fois que vous avez fini de le lire. Cela vous aide à développer votre sens critique, mais aussi vous permet de trouver d’autres alternatives à la résolution d’un problème, qui peuvent parfois se révéler meilleures que les conseils du livre. Notez bien, il ne faut pas être ambitieux, un seul livre tous les six mois suffit.

Apprendre le langage que vous utilisez au bureau en profondeur, vraiment en profondeur

Pour ceux qui recommandent cette approche, plusieurs développeurs n’ont qu’une maîtrise partielle des langages qu’ils prétendent connaître ou ne les connaissent qu’en surface, ce qui n’est pas un avantage. D’après eux, connaître en profondeur le langage que l’on utilise au travail est l’une des meilleures décisions qu’un ingénieur peut prendre afin de donner un élan décisif à sa carrière. En outre, ils recommandent aussi de ne pas hésiter à plonger dans les langages très populaires, notamment ceux qui reviennent tous les ans dans le top 3 des index.

Sur cette position qu’ils adoptent, ils estiment que, plus en connaissez et plus vous êtes à même de juger de leurs forces et de leurs faiblesses. De même, plus vous connaissez de langage et plus vous pouvez en choisir facilement de nouveaux et migrer plus facilement d’un langage à un autre.


S'associer plus souvent à d’autres développeurs

Le jumelage est-il aujourd’hui démodé ? Ceux-ci pensent que c’est le cas. Selon ces derniers, le jumelage contribue pourtant à donner naissance à de grands programmeurs. D’après eux, c’est cette approche qui donne lieu aux plus grands sauts professionnels, ajoutant que ces sauts se révèlent parfois plus significatifs que la lecture de n’importe quel livre. Ainsi, quand vous exposez vos idées sur un problème ou lorsque vous exposez votre code, requérez des commentaires, etc., vous apprenez beaucoup et vous devenez beaucoup plus performant avec le temps.

Écrire des tests unitaires et les exécuter en CI

Cette quatrième approche recommande d’écrire des tests unitaires et de les exécuter en CI (continuous integration - intégration continue). D’après ceux-ci, les tests unitaires permettent de sauver votre équipe d’ingénieurs et évitent que vous introduisiez dans votre code des erreurs graves, qui pourraient coûter cher à votre organisation. Ils permettraient également de se préparer à des changements majeurs à l’avenir.

S'habituer au refactoring et maîtriser ses outils

Le refactoring ou le réusinage de code est une technique disciplinée de restructuration d'un code existant, qui consiste à modifier sa structure interne sans changer son comportement externe. Le but est de faire une série de petites transformations qui préservent le comportement. Chaque transformation (refactoring) fait peu de choses, mais une séquence de ces transformations peut produire une restructuration importante. Comme chaque refactoring est petit, il est moins probable qu'il se produise des erreurs. Le système continue à fonctionner après chaque remaniement.

Cela réduit les risques qu'un système soit gravement endommagé pendant la restructuration. Selon cette recommandation, s’habituer au refactoring vous aide à devenir un expert dans la réduction de la taille du code, dans l’amélioration des performances d’un système, y compris sa vitesse… Cela permet également de savoir extraire une méthode d'un code, renommer une variable, passer à une constante... Enfin, maîtriser les outils du refactoring consiste à avoir une parfaite connaissance de ses EDI et les extensions servant au refactoring que vous avez ajouté à ces derniers.

Chercher à avoir beaucoup d’expérience

L’on estime qu’une bonne ingénierie logicielle est le résultat de beaucoup d’expériences, vous devez donc en obtenir assez. La plupart des ingénieurs ont tendance à se laisser influencer par les séniors, car ces derniers ont l’air de tout savoir ou d’avoir réponse à tout. Selon cette recommandation, l’on peut remédier à cela en étudiant les profondeurs de plusieurs langages, en travaillant avec les autres ingénieurs, en recherchant des opportunités de travailler sur différents piles, domaines et projets stimulants. Il ne faut pas non plus avoir peur de changer d’équipe à mi-chemin d’un projet.

En outre, ils recommandent aussi de se porter volontaire pour travailler sur de nouveaux projets et essayer de nouvelles technologies.

Enseigner ce que vous apprenez

Cette recommandation suit le dicton qui dit que : « la meilleure façon d’apprendre une chose est de l’enseigner ». L’approche consiste à parler de ce que vous apprenez ou ce sur quoi vous travaillez, en public devant d'autres ingénieurs et développeurs. La prise de parole en public vous oblige à correctement vous préparer, ce qui vous amène à étudier en profondeur les rouages de votre sujet de présentation. Cette approche est également connue sous le nom de “Learn in public”, et fonctionnerait très bien. Cela vous transforme en bon enseignant et mentor.

Et vous ?

Selon vous, quels sont les conseils pour débuter en tant que développeur de logiciels ?

Voir aussi

Sondage : l'échéance des tâches oblige-t-elle les ingénieurs IT à faire des heures supplémentaires gratuitement ? Partagez votre avis sur le sujet

Sondage : quelles sont les pires erreurs à éviter dans le cadre d'un entretien d'embauche dans la filière informatique ? Partagez vos avis

Sondage : quels sont les langages de programmation que vous détestez le plus en 2019 ? Pourquoi ? Partagez vos avis

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 28/09/2020 à 20:01
Des conseils un peu en bazar, tout de même. Certains sont fonction des habitudes de chacun (livre vs. recherches internet), d'autres sont spécifiques à un contexte (bureau vs. perso), méthodes (refacto, tests), généralités (expérimenter, enseigner).

Seuls conseils généraux à prodiguer : pratiquez et trouvez ce qui vous plaît !

Pratiquer permet d'une part de renforcer l'expérience et donc gagner en rapidité, et d'autre part de découvrir de nouvelles choses et donc d'augmenter les chances de trouver des choses qui plaisent. Une fois qu'on a trouvé ce qui nous plaît il faut se focaliser dessus et pratiquer, encore et toujours, en essayant de se mettre dans une situation qui permette de le faire et d'obtenir des retours constructifs sur ce qu'on fait. Dès lors qu'on a la motivation pour s'améliorer, la situation qui le permet, et qu'on pratique dans ce sens, le reste vient tout seul.

Dans la liste, les deux seuls que j'appuie clairement sont donc avoir de l'expérience et enseigner ce qu'on apprend (plus généralement présenter sa façon de faire). Peu importe le contexte, pratiquer et partager ses connaissances permet de se forger. S'associer à d'autres dévs va dans le même sens que l'enseignement, mais ça peut se faire de bien des manières (pair/group programming au bureau, contributions aux projets open source, projets persos avec des connaissances) et il y a des tas de raisons pour que ça ne marche pas (personnes laxistes, tendance à suivre l'avis du groupe, etc.). Il ne faut pas s'associer à des développeurs en vue d'obtenir des connaissances (ça arrive souvent mais pas forcément tout seul), mais plutôt dans l'objectif de proposer des solutions nous-même qui pourront être challengés par les autres. A contrario, l'expérimenté profitera plus de ce genre de pratique en laissant les autres proposer des solutions et les challenger en posant les questions qui vont bien.

Lire des livres, c'est bien quand on a ce qu'il faut pour en avoir et pour en lire. Mais l'important est surtout de savoir chercher l'information, et internet suffit bien. C'est d'ailleurs le plus à même de recommander des livres le cas échéant, mais sinon partir d'une page Wikipédia et parcourir les liens, y compris les liens externes amenant à des sites spécialisés, ça aide déjà beaucoup. Les livres sont une source d'information parmi d'autres, complémentaires.

Apprendre le langage en profondeur, à prendre avec des pincettes. Je n'utilise pas qu'un seul langage dans mon boulot, et je ne vais certainement pas tous les creuser à 100%. Par contre, quand on cherche à résoudre un problème, il est important de réfléchir par soi-même à comment on le résoudrait avec ce qu'on connaît déjà (et à accepter qu'on n'en sait rien si c'est le cas), puis chercher (e.g. demander aux collègues, internet) comment d'autres l'ont résolu dans le langage qui nous intéresse. Il faut ensuite mettre en pratique ce qu'on a trouvé pour confirmer que ça fait bien ce qu'on a lu, jouer avec pour confirmer qu'on a bien compris comment ça fonctionne, et prendre la solution qui satisfait le mieux notre besoin parmi ce qu'on a trouvé.

Cette notion de challenger ce qu'on a compris et ce qu'on a fait est à la base de l'amélioration. C'est en confrontant nos connaissances à des cas pratiques qu'on les confirme ou les corrige, augmentant ainsi leur quantité et leur qualité, et donc notre expertise. Les tests unitaires partagent ce point : il s'agit de confirmer qu'on a bien fait ce qui est attendu. Les préserver dans une CI permettra de ne pas régresser.

S'habituer au refactoring fait partie de l'amélioration continue. Il est important d'avoir à l'esprit qu'on fait rarement (jamais ?) bien du premier (deuxième, troisième...) coup. Les méthodes agiles ne sont pas populaires pour rien : dans un domaine où on découvre les besoins au fur et à mesure, il faut (i) faire au mieux avec les infos du moment et (ii) revenir dessus quand c'est nécessaire. Le refactoring est cette étape intermédiaire qui permet de préparer (ii), sans quoi le jour où on revient dessus on ne comprend plus rien et il faut tout refaire.

Donc conclusion : pratiquez et trouvez ce qui vous plaît !
10  0 
Avatar de VBurel
Membre habitué https://www.developpez.com
Le 02/10/2020 à 12:41
pour les débutants mon conseil, c'est de pratiquer en s'amusant, sur un objectif concret: un programme ou un service que vous utiliserez vraiment.
Le reste viendra tout seul.

Et surtout n'attendez personne, n'attendez pas de faire des études ou d'avoir un diplome, n'attendez pas de savoir ceci ou cela,
n'attendez pas que qqn vienne vous dire que c'est bien ou mal ... juste faites le.
7  0 
Avatar de scandinave
Membre éclairé https://www.developpez.com
Le 29/09/2020 à 10:25
Personnellement, les trois plus gros problèmes à résoudre que je constate chez la majorité des dev juniors sont :

  • Apprendre à prendre son temps : Trop souvent, le Dev va vouloir répondre à un problème en copiant la première solution trouvée sur le net et passer à autre chose. De la même manière, je vois souvent des dev ne pas lire les stackstrace et juste copier-coller les solutions StackOverflow en boucle en espérant que cela va fonctionner. Chaque solution demande d'être comprise et testée pour être implémentée correctement. Et cela est formateur. Coper-coller du code, n'apporte rien. Il faut donc prendre le temps de lire en détail la documentation du langage/framework pour comprendre comment il marche et quelles sont ses fonctionnalités.
  • Apprendre à définir ou va quoi : Je vois trop souvent des problèmes parce que les rôles des composants/classes ne sont pas respectés. La vue qui fait des appels BDD, un couplage fort entre chaque composant, etc. Savoir qui fait quoi et comment séparer les composants en réduisant les adhérences est pour moi fondamental. Pour cela Uncle Bob en parle très bien.
  • Maitriser son environnement de dev : Je vois trop de développeurs utilisant leurs IDE comme un bloc note ou ne maitrisant pas git, ne sachant pas la différence entre un rebase ou un merge. Dans le premier cas, c'est une perte de temps. Dans l'autre, un manque d'autonomie pour le travail en équipe.


Une fois cela maitrisé, le Dev est à mon sens quelqu’un d'autonome sur qui je peux me baser pour travailler. Le reste viendra tout seul avec l'expérience. Mais si le dev ne maitrise pas cela rapidement ( ~1-2 ans max ), sa carrière va en prendre un sacré coup.
6  1 
Avatar de Mrsky
Membre expérimenté https://www.developpez.com
Le 29/09/2020 à 13:55
Créer un programme et le maintenir pendant au moins quelques mois en l'améliorant me semble être un bon conseil pour débuter, et peu importe le programme que ce soit un driver d'imprimante ou un front web. L'idée c'est de découvrir le cycle de vie d'un programme par l'expérience : design, architecture, implémentation, versions, tests, etc.

Devoir mettre à jour un programme met en lumière l'utilité des tests et de l'importance d'un code bien organisé et pas inutilement complexe. Quel débutant n'est pas tombé dans le piège d'une solution élégante et super dynamique qui gère tous les cas, sauf celui qui doit être implémenté dans 6 mois parce qu'on y avait pas pensé, et qu'il faut changer une grosse partie du code ?
3  0 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 04/10/2020 à 20:18
Le plus important, comprendre que l on ne confiera jamais un probleme neuf a un junior, donc des solutions existent déjà. Le bon dev, quelque soit son niveau cva estimer plusieurs solutions et choisir celle qui est la plus pertinente.

Un dev à qui on demande d ouvrir un serveur ftp et qui commence à le coder n à pas sa place dans mon équipe. Qu il y arrive ou pas.
Celui qui me développe depuis 0 des lib python de base non plus.

Bref, ayons tous dans notre métier l humilité de reconnaître que 99% des problèmes ont été résolu pas des gens plus intelligent que nous et essayons de comprendre les solutions possible et comment les départager. Sans prétendre faire mieux.
3  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 05/10/2020 à 19:52
Citation Envoyé par pmithrandir Voir le message
J'ai bien dit, lib de base.

[...]

De mon coté, peu m'importe que les mecs de mon équipe comprennent 100% du code des lib que l'on utilise. De toute manière, personne dan la boite ne maintiendra le code qu'ils auront pondu 5 ans plus tot...
Si ton conseil est de faire du code jetable sur lequel personne ne reviendra, fallait le dire tout de suite. Du coup je comprends mieux le focus.

Sinon, les libs de base changent selon le contexte et le temps. Dans une boîte, on sera parti sur tel langage avec telles libs, dans une autre le même langage mais avec d'autres libs, et tu auras l'air bien con à maîtriser cette troisième lib que tu pensais être une lib de base mais qui n'intéresse pas les boîtes qui t'embauchent.

Je suis pas convaincu qu'un débutant ait pour premier objectif de se faire un panel de libs. En tout cas, ceux qui passent leur temps à se mettre à jour sur les nouvelles lib qui font la hype ont moins de temps pour maîtriser les bases du dév (commun à tous les projets), ce que je trouve bien dommage.

Citation Envoyé par MarieKisSlaJoue Voir le message
Sinon j’ai répondu autre, pour moi le seul premier conseil et de ne pas rejoindre une SSII.
Pourtant, si on tombe bien, c'est un bon moyen de s'assurer un job de technique sans tomber dans le travers de l'"upgrade" en chef de projet. Quand tu as fini ta mission, tu passes à une autre, ce qui te permet de toucher à diverses technos, dans différents contextes, et donc de pratiquer beaucoup plus.

Et puis ça n'existe plus les SSII. On parle d'ESN maintenant.
3  0 
Avatar de VBurel
Membre habitué https://www.developpez.com
Le 06/10/2020 à 7:43
Citation Envoyé par Pierre Fauconnier Voir le message
il me semble que l'on mélange deux trucs qui n'ont pas grand chose en commun: Développeur de logiciels et programmeur.
Pourrait-on définir ce qu'est "un développeur de logiciels"?
ouaip, Le développeur est un peu à la filaire informatique ce que l'auteur est à la filaire du livre.

Le développeur n’a pas besoin d’être expert en langage ou autres technologie à la mode pour créer et développer des logiciels ou des services IT. De même qu’un auteur n’a pas besoin d’être expert en grammaire ou technique d’impression pour imaginer et écrire des histoires.

Ce qui demande de l’expérience et un savoir faire solide, c’est ce qu’on appelle « l’industrialisation », c’est à dire l’écriture d’un code source qui a vocation à être optimal sur plusieurs axes (charge CPU, fiabilité, portabilité, consommation électrique etc..) et être validé le plus rapidement possible (le code validé coute d’ailleurs de plus en plus cher aujourd’hui). Mais quand on commence à industrialiser, le développement proprement dit est terminé.

Dans les années 90, Le développeurs pouvait être capable de tout faire : le prototype, le pré-produit, et le produit. Aujourd’hui c’est un profile assez rare du fait que toute les phases de construction d’un logiciel se sont complexifiés, de la conception à la mise en ligne / en prod, et du fait que les attentes utilisateurs sont bien plus difficiles à satisfaire qu’il y a 20 ans.
3  0 
Avatar de Mrsky
Membre expérimenté https://www.developpez.com
Le 28/09/2020 à 22:55
Les sites web il faut savoir faire le tri, il y a énormément d'articles type medium ou quora ou les mecs te font un historique de l'informatique pour conclure un truc bateau et en effet c'est une perte de temps. Par contre il y a des pépites, personnellement j'ai énormément appris en lisant le blog de Martin Fowler que je recommande chaudement (pour les anglophones).
2  0 
Avatar de epsilon68
Membre éprouvé https://www.developpez.com
Le 04/10/2020 à 15:17
pour moi, seulement 2 conseils :
- aimer ce qu'on fait
- comprendre en profondeur chaque ligne qu'on ecrit
2  0 
Avatar de MarieKisSlaJoue
Membre expert https://www.developpez.com
Le 06/10/2020 à 8:58
Citation Envoyé par Matthieu Vergne Voir le message
Pourtant, si on tombe bien, c'est un bon moyen de s'assurer un job de technique sans tomber dans le travers de l'"upgrade" en chef de projet. Quand tu as fini ta mission, tu passes à une autre, ce qui te permet de toucher à diverses technos, dans différents contextes, et donc de pratiquer beaucoup plus.

Et puis ça n'existe plus les SSII. On parle d'ESN maintenant.
Si on tombe bien, là est tout le problème, pour 1 bonne c'est 10 pourris. On peut toucher un plein de techno hors SSII. D'ailleurs il n'est pas dans l'intérêt d'une SSII de te laisser toucher à des technos que tu ne connais pas, car ils sont là pour vendre des experts, or on ne peut pas être expert sans avoir pratiqué de façon récurrente une techno.
Le seul endroit ou on peut être expert en quelque chose en ayant juste eux trois jour de formation et lu une doc.... c'est en SSII, mais on l'est juste au moment de la facturation.

Il aurait des tas de chose à reprocher encore au SSII qui montre que ce n'est pas un bon endroit pour évoluer et devenir meilleurs, au pif, les SSII on la facheusse tendance de recruter n'importe qui, même le plus mauvais. Car au mieux il sera quand même placé sur un truc pourri mais sera facturé, au pire il ne passera pas la période d'essai.

Or pour un junior, être entouré de vrai expert et bon développeur est important, les SSII ne sont pas là pour attirer et garder les bons développeurs.

Bref, les SSII devraient tous simplement disparaître du paysage informatique, ça serait mieux pour le monde de l'IT en général.

Et bien sûr je continue de dire SSII, car je n'ai aucune considération pour ces structures et que changer de nom, ne change pas le fond.
2  0