Discussion :

[Idelways]

Quel conseil donneriez-vous à un débutant en développement ?
Et lequel auriez-vous aimé recevoir quand vous avez commencé à programmer ?


Le développement est un métier riche et passionnant, mais aussi dur et souvent difficile d'accès.

S'il n'est pas correctement orienté lors de ses études par des enseignants passionnés ou s'il est autodidacte par un parrain compétent, le débutant peut vite se perdre, se lasser et changer de cap vers d'autres métiers de l'informatique, jugés moins « prise de tête ».

Bryan Woods, un développeur américain a posté sur son blog quelques excellents conseils aux débutants. En fait, des conseils qu'il s'adresserait à lui même s'il pouvait remonter le temps.

Le premier conseil qu'il donne, c'est de ne pas sous-estimer le développement et d'admettre une bonne fois pour toute que c'est un métier difficile, qui nécessite beaucoup d'efforts et de détermination afin d'être cerné et maîtrisé.

Sans quoi, à la rencontre de chaque nouveau concept qui semble étrange, difficile ou non-intuitif, le débutant remettra en question son intelligence et sa capacité à cerner le domaine.

"Pas grave, le développement c'est dur" est beaucoup moins négatif que "je suis nul" ou "le développement c'est pas mon truc".

Le deuxième conseil que donne Woods est de bien choisir le premier langage à apprendre. Car ce choix est capital dans la mesure où il conditionne la base du développeur pour comprendre tous les autres langages.

De même qu'on ne peut "avoir des pensées" que dans sa langue maternelle, il n'y a selon Woods aucune raison pour que ce ne soit pas le cas avec les langages informatiques.

Un autre conseil : la meilleure manière d'apprendre le développement est de ... développer.

Apprendre par la pratique permet de mémoriser rapidement les concepts du développement et les spécificités des langages. Ce qui permet d'apprendre à s'exprimer mieux et de plus en plus vite avec la machine.

Sans pratique au quotidien, tout le reste est inutile.

En revanche, ne pas être fort en math n'est, selon Woods pas un problème. Il admet avoir été surpris à ses débuts, de constater à quel point les math sont si peu présentes dans ses développements quotidiens.

Finalement, il donne un dernier conseil aux débutants, peut-être le plus important : celui d'apprendre à apprécier l'apprentissage du développement, car ils ne finiront jamais d'apprendre.

Et vous ? Quel conseil donneriez-vous à un débutant ?

Et quel conseil auriez-vous aimé que l'on vous donne quand vous avez commencé à programmer ?

Source : le Blog de Bryan Woods

En collaboration avec Gordon Fowler

[Bryce de Mouriès]

Inutile de réinventer la roue !

[Jidefix]

J'aurai dit exactement le contraire de Bryce

Justement je lui conseillerai de ne pas vouloir aller trop vite et de bien comprendre les principes de base, tels que la syntaxe, l'algorithmique basique, la gestion des variables, la compilation...
Combien j'ai vu de développeurs se lancer dans le développement d'applis J2EE sans être à l'aise avec les concepts objets ou même avec la syntaxe java ("ça veut dire quoi static? c'est quoi la différence entre une classe et une instance?")!

Sans aller jusqu'à réinventer la roue, comprendre comment elle roule et ce qui la rend efficace, c'est quand même important!

[yop828]

Inutile de réinventer la roue !

Oui et non : quand on débute c'est interessant de comprendre de refaire comment la roue fonctionne...

Reste humble et intéresses toi

+1

Une des premières choses à faire aussi est d'écrire sur une feuille ce que notre application doit faire et ne pas perdre de vue ce papier. Et bien sûr le mettre à jour en fonction du reste à faire
Surtout ne pas se lancer dans le développement tant que l'on n'as pas les idées claires

100 % d'accord : il ne faut pas hésiter à poser les problèmes et à les subdiviser en plus simples (diviser pour régner inside). Cela permet de savoir ou on va et ou on en est

Pour ma part j'ai vraiment commencé la programmation par le pascal et le C en 98. J'avais commencé à apprendre le Java de manière personnelle comme cela mais à l'époque en 97 il y avait bcp moins de doc que maintenant et avec le recul je pense que cela faisait trop de concepts a apprendre d'un seul coup mais c'est un avis perso...

[SurferIX]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
if(monexpression == true) // deviens if(monexpression)

function bool isValid(object monObjet)
{
   if(monObjet.toString().Equals("test"))
      return true;
   else
      return false;
}
//deviens
function bool isValid(object monObjet)
{
   if(monObjet.toString().Equals("test"))
      return true;
   //pas besoin de else puisque de toute façon
   //si c'est vrai on sort de la fonction
   return false;
}

Bonne chance à tous

Je ne cherche à agresser personne, mais si on suit ce conseil, on peut se retrouver avec du code ainsi en php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$f = fopen('monfichier');
if ($f) {
  // traitement
}
else {
  // erreur
}

Or, il peut arriver (cas improbable mais possible), que fopen renvoie un handle entier = zéro. Donc, avec le code précédent, il y aurait une erreur alors que le fichier est correctement ouvert.
Donc moi je donne (et en tant que chef de projet, je force tout le monde) à faire des comparaisons entières, donc exactement l'opposé de ton conseil, à savoir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$f = fopen('monfichier');
if ($f!==false) {
  // traitement
}
else {
  // on est 100% sûr que c'est une erreur
}

Encore une fois je ne dis pas ça pour agresser, c'est juste dans un but constructif et positif

Inutile de réinventer la roue !

Ce que je dis n'engage que moi, et je ne cherche pas à agresser les gens, mais je ne suis pas tout à fait d'accord.

Il y a deux cas possibles :
- "oui" : ne jamais réinventer la roue dans le cadre d'un gros projet en entreprise ;
- "non", chercher à réinventer la roue pour soi, en étant conscient qu'on la réinvente pour apprendre à gérer certains problèmes particuliers qu'on n'arrive pas à imaginer (ex. : développer en C la gestion d'un arbre binaire équilibré).

Je ne veux pas répéter sous un autre forme d'autres conseils, donc je vais en donner deux que je n'ai pas encore vu... Mes deux conseils qui suivent vont tout de même dans le sens de "Inutile de réinventer la roue !"

J'ai fait une longue traduction d'un article de Joel Spolsky ici, et mon premier conseil serait :
C'est toujours plus dur de lire du code que de l'écrire.

Mon second conseil serait : toujours garder en tête qu'un bon développeur produit du bon code, un excellent développeur sait utiliser de l'excellent code.

[Leonhart]

• "La perfection est atteinte non pas quand il n'y a plus rien à rajouter, mais quand il n'y a plus rien à enlever'

Autrement dit, toujours cherché à optimiser son code. Au début, c'est long et très difficile.
Mais plus on pratique, plus cela devient automatique, et plus nos premiers algorithmes sont bons !

[gKsam]

Penser fainéant : Le but c'est de réaliser une tâche en faisant le moins chose possible.

• "La perfection est atteinte non pas quand il n'y a plus rien à rajouter, mais quand il n'y a plus rien à enlever'

Réinventer la roue : tout du moins au début. j'y suis passé (mon prof de java me le disait tout le temps) arrêtez de réinventer la roue. Mais, au moins, je pense maîtriser les bases.

Penser DRY (Don't Repeat Yourself)

Qaund ça devient trop compliqué : "ben tu tes gourré"

Quand c'est trop long : "ben c'est pas bon" (une méthode de plus d'un écran par exemple)

Ne jamais se décourager. JAMAIS

[popo]

Il y en a beaucoup qui disent ne pas réinventer la roue.
Quand on est débutant il est nécessaire de réinventer la roue !!!

Au risque de me répéter : La réécriture ne sert qu'à mémoriser, pas à comprendre. La lecture du code et son analyse (en mode debug, pas à pas, ou autre) permettent de voir comment ça fonctionne.

Il y a deux cas possibles :
- "oui" : ne jamais réinventer la roue dans le cadre d'un gros projet en entreprise ;
- "non", chercher à réinventer la roue pour soi, en étant conscient qu'on la réinvente pour apprendre à gérer certains problèmes particuliers qu'on n'arrive pas à imaginer (ex. : développer en C la gestion d'un arbre binaire équilibré).

Il existe sur le net des tonnes de tutoriels qui sont là pour aider le développeur débutant à comprendre ce genre de problèmes particuliers et généralement (puisque se sont des tutoriels) il sont documentés (parfois à excès). Encore une fois la lecture permet de comprendre, la réécriture permet de mémoriser...

Réinventer la roue : tout du moins au début. j'y suis passé (mon prof de java me le disait tout le temps) arrêtez de réinventer la roue. Mais, au moins, je pense maîtriser les bases.

J'avais fais à peu près la même remarque à mon prof. Il m'a répondu que si je suis capable de réinventer la roue, c'est parce que je maîtrise déjà, le concept.
Il est essentiel de réécrire du code pour le mémoriser et être capable de le refaire s'il n'est pas existant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
function bool isValid(object monObjet)
{
   if(monObjet.toString().Equals("test"))
      return true;
   //pas besoin de else puisque de toute façon
   //si c'est vrai on sort de la fonction
   return false;
}

Attention, ce n'est pas vrai dans tous les langages. En Delphi si tu fais ça, tu vas toujours renvoyer False.

Pour ma part j'ai pris l'habitude d'initialiser la valeur de retour par défaut dès le début de la fonction.

[Paul TOTH]

Attention, ce n'est pas vrai dans tous les langages. En Delphi si tu fais ça, tu vas toujours renvoyer False.

les dernières version de Delphi proposent un Exit(value) mais sinon c'est le couple "begin Result := Value; Exit; end;" qu'il faut utiliser voilà tout

[Nebulix]

les dernières version de Delphi proposent un Exit(value) mais sinon c'est le couple "begin Result := Value; Exit; end;" qu'il faut utiliser voilà tout

Et les suivantes encore autre chose ?
Comment trouver la manière qui restera "robuste" malgré les "évolutions" ?
Et je crains que Delphi ne soit pas ce qu'il y a de pire dans le genre ...

[DotNET74]

Personnellement,

Cela fait longtemps que je développe en tant que passionné bien que j'ai pu mettre en oeuvre ces compétences de manière professionnelle et je suis passé de VB6 à la plate forme .NET assez facilement.

Après une pause de 2 ans je me remets dedans et là je tombe sur Silverlight, MVVM et WPF. Et je galère beaucoup car j'ai l'impression de ne plus rien comprendre à ces technologies.

J'ai l'impression de revenir en arrière car il y a beaucoup de code à écrire avec ces technos.

Les différentes aides qu'on trouve sur le net ne m'aide pas car ce sont bien souvent des morceaux de codes qui sont présentés et cela ne permet pas de créer une solution complète.....

Tout ça pour dire que rien n'est jamais acquis dans ce domaine

[seeme]

Personnellement, je pense qu'il faut au contraire chercher à réinventer la roue. Ce n'est qu'une fois qu'on a compris comment ça fonctionne qu'on peut aller plus loin.

Un conseil que j'essaye de suivre, est de ne JAMAIS copier/coller du code qui n'est pas de son cru, et de le retapper en entier. Exemple, pleins de gens autour de moi ne savent pas comment ouvrir un fichier en C, et se contente de copier/Coller à chaque fois...

Ca aide à mémoriser et surtout à comprendre.

[TIFéç]

Simple et efficace : google est ton ami (et il sait tout!)

[Fooshi]

Ce qui est important en tout cas c'est de ne pas commencer trop dur car on ne pourra jamais comprendre tous les principes d'un seul coup. Pour un développeur débutant le mieux c'est de commencer a faire des applis an Basic, Visual Basic, VBA pour commencer a comprendre les principes de la programmation puis de s'attaquer au C/C++, Java pour mieux comprendre les principes de pointeurs, gestion de la mémoire, évènements etc ... en tous cas c'est comme ca que j'ai commencé et ca a plutôt bien marché.
Et puis il faut toujours développer et encore développer, des projets perso par exemple sur différentes techno ca rapportent toujours sur un CV !
Et puis ne pas baisser les bras, on peut être bloqué pendant plusieurs jours sur un problème mais lorsque ca marche quel bonheur !

[michel.di]

En revanche, ne pas être fort en math n'est, selon Woods pas un problème. Il admet avoir été surpris à ses débuts, de constater à quel point les math sont si peu présentes dans ses développements quotidiens.

ça je trouve que ça dépend du développement à réaliser. J'ai bossé sur la géolocalisation sur Android et faut quand même avoir quelques bases

Autre conseil : Prendre tout de suite les bons réflexes et les normes de développement car après c'est dur de les changer

[Code62]

Mon premier "conseil" porte sur le fait qu'en général on passe beaucoup plus de temps à relire du code (le sien ou celui des autres) qu'à l'écrire, et qu'il est donc capital de l'écrire proprement (aération; nommage explicite des variables, fonctions, ...; commentaires pertinents aux endroits appropriés; ...)

[Invité]

Moi le premier conseil que je donnerai est le suivant :
toujours réfléchir en inscrivant ses idées au clair en utilisant du papier et un crayon pour ne pas se lancer tête baisser dans le code.

Après tout on n'est qu'un débutant on n'a pas assez d'expérience pour aller plus vite !!

[eclesia]

1 - Ne pas faire confiance aux blogs, la majorité sont entretenus par des amateurs, il n'y a en general qu'une ou deux personnes sur chaque api qui offre du code de qualité dans leur blogs. Savoir les différencier requiere de ne plus etre un débutant, alors oubliez les blogs et concentrez vous sur les documentations officielles.

2 - Ne pas déifier les patrons de conception (design pattern). Si vous ne comprenez pas la logique qui est derriere alors utilisez votre cerveau et oubliez le pattern. un pattern mal utilisé est dangereux.

3 - Google n'est pas votre amis, les classements sont fait en partie avec la "popularité" (somme de différents parametres : nombre de liens, de visites, ...).
C'est donc bien souvent des liens souvent visités ou surclassés qui sortent en premier et non nécessairement les plus intéressants.
Pensez a faire vos recherches avec d'autres moteurs. Ou encore les moteurs qui croisent les resultats tel que IxQuick/StartPage
donnent des resultats bien moins influencé par les tendances du moment.

4 - vous etes arrivez la pour les jeux videos ? la déillusion vous attend.

[phryos]

Reste humble et intéresses toi, on finit toujours pas trouver son maitre

[slim_java]

Salut,

Quel conseil donneriez-vous à un débutant ?

Apprendre par la pratique permet de mémoriser rapidement les concepts du développement et les spécificités des langages.

J'ajoute aussi que la lecture (doc, blog, article, livre...) est la base de tout en informatique.

Aussi, une inscription sur un forum d'entraide comme DVP.com a sa valeur ajoutée