Discussion :

[Michel Rotta]

Y'a jamais trop de commentaires.

¨Point trop n'en faut...

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
// Ouverture d'une boucle pour incrémenter un compteur de 1 a 100
//Initialisation de la variable à la valeur de 0 avant de commencer la boucle
$i = 0;
// début de la boucle avec un test pour vérifier is la valeur obtenue est la bonne
while ( $i < 101 )
{
   // On va ici incrémenter la variable $i de 1
   $i++
   // Maintenant on affiche un point à l'écran pour que l'utilisateur ne parte
   // pas ce faire un café, déjà qu'il n'en fout pas une de toute
   // la journée.
   echo '.'
}
// La boucle est terminée, le reste du code va continué, si du moins, 
// il n'y a pas un bug non traité qui traine ici au dessus.

[Faiche]

En fait, pour débuter, c'est simple :
1ère étape - comprendre les bases de l'algorithmie : différences entre les différents conteneurs (arbre, table de hachage, vecteur, liste chainée etc) et vagues notions de complexité (suffit de se sentir mal à l'aise devant 10 boucles imbriquées, pas besoin de faire les calculs)

2ème étape - choisir un langage qui possède au moins un framework de tests unitaires facile à utiliser et intégrable à l'éditeur de code.

3ème étape - comprendre le fonctionnement de ce langage : s'il est objet, comprendre l'objet, connaitre les mots clés principaux (genre for ou if, pas besoin de connaitre transient ou yield return), et comprendre le fonctionnement du framework de tests.

4ème étape - tester 100% du code. Oui oui 100%.
Oui, c'est pénible.
C'est pénible de tester un setter ou un getter, mais est ce qu'on a besoin réellement de ce setter ou de ce getter ?
C'est pénible de tester à 100% une fonction de 2000 lignes, mais est ce qu'on ne peut pas la découper en plusieurs petites fonctions ?
etc etc.. (Note : la seule partie du code qui peut ne pas être testée, c'est l'ihm. On ne vous en voudra pas)

Au fur et à mesure, pour éviter que ce soit pénible, il va falloir penser le code de manière à le rendre testable, et mettre en place des techniques de développement pour faciliter le test (TDD)
(Celui qui me dit que pour rendre moins pénible il suffit de moins tester, il est viré).

Une fois que vous êtes capable de programmer du code 100% testé, sans problème, vous vous ouvrez les portes, non pas des SSII pourries que vos camarades non testeur peupleront, mais des Google et compagnie.

[albesoft]

Bonjour,

L'informatique ? je suis tombé dedans quand j'étais petit... euh, pas tout à fait quand même mais l'informatique (ou du moins la micro, accessible aux autodidactes, l'était). C'était au début des années 80 !!!
Commencer en BASIC sur un TRS-80 avec 16Ko de RAM (oui ! 16K tout compris) avec des noms de variables sur 1 ou 2 caractères, faire la chasse à l'octet perdu... vous fait prendre de bonnes habitudes.

Ensuite, j'ai évolué (avec beaucoup de temps, de lecture, d'essais et de ré-essais... bref de pratique) vers des langages de plus en plus intéressants en parallèle avec l'évolution de la puissance des machines.
La vitesse des processeurs et la taille de la mémoire (vive en gigaoctets) ou externe (en téraoctets) ont complètement changé l'approche du développement.

Actuellement, après avoir été Programmeur Système puis Analyste, (j'ai participé activement à la mise en place et au développement d'applications nationales), je termine ma carrière comme enseignant dans une Ecole Nationale d'un grand ministère...

Préalable
Avant de vouloir donner des conseils techniques, il faut se préoccuper de l'esprit de la personne concernée. Plusieurs articles font mention de la motivation (++) et du plaisir que l'on doit éprouver à développer (++++) car développer c'est créer ! la programmation, comme la médecine dont je suis issu, est un art aussi bien qu'une science.
Il faut, pour réussir, avoir une "tournure d'esprit" qui soit logique (pas au sens matheux mais dans le sens commun du terme) c'est à dire :

• des capacités d'analyse (chercher à comprendre ce qu'on a en face de soi ou ce que doit faire le projet en cours),

• de diagnostic (pourquoi ça ne fonctionne pas comme je le voudrais?)

• et de synthèse (maintenant que j'ai les matériaux, je peux commencer à construire) en expliquant pas à pas à la machine ce qu'elle doit faire.
  
  En fait, il n'y a rien de plus bête qu'un ordinateur, il fera exactement (et très rapidement) tout ce qu'on lui dit de faire mais seulement ce qu'on lui dit de faire. Et si on lui dit de faire une bêtise, il la fera (ou il tentera de la faire...).

Sa seule intelligence lui vient des programmes écrits par ses concepteurs...

Pour bien débuter :
Comme l'ont souligné également plusieurs articles, le crayon et le papier sont INDISPENSABLES avant de "se jeter sur le clavier"... Combien de fois ai-je vu des élèves lire rapidement l'énoncé d'un exercice ou d'un TP plus complexe et commencer à saisir du code, sans aucune réflexion d'ensemble préalable... et "se prendre la tête" à modifier cent fois leur code pour le faire correspondre à ce qu'ils n'avaient pas prévu...
10 minutes passées à crayonner un schéma, à prévoir l'architecture globale et à noter les choses à faire (je reste volontairement très vague et ne fais appel à aucune méthode ni langage) font gagner des heures de débogage.

Pourquoi faire simple quand on peut faire compliqué ? vieil adage hérité (malheureusement) de certaines pratiques d'optimisation (?) du code, particulièrement en C où il était de bon ton de créer des instructions ultra-complexes ou de regrouper tout un programme dans une unique boucle for.
L'optimisation ne doit pas être un obstacle à la maintenabilité. Vu la vitesse des processeurs actuels (et sauf à réaliser un programme qui doit fonctionner en temps réel bien sûr) qu'est-ce que quelques micro-secondes de plus en séparant un traitement en quelques instructions plus simples à relire et à comprendre, par rapport aux temps de réponse d'une page WEB (même avec le câble...) et surtout aux heures perdues lorsqu'on doit "remettre le nez" dans ce code (surtout si ce n'est pas vous qui l'avez écrit!)
Il faut donc favoriser la lisibilité.

Commentez votre code :
En évitant, évidemment, des commentaires superflus ou non pertinents...
Quelque soit le langage utilisé :

• commencez par écrire, en français (les pseudo-codes ne sont pas indispensables pour un débutant) ce que votre programme doit faire, mettez au clair la démarche employée (un peu d'algorithmique ne nuit pas...)

• Saisissez votre démarche sous forme de commentaires dans votre code source

• Insérez, entre les commentaires, les instructions du langage que vous avez choisi

Testez, testez, suivez pas à pas le déroulement du programme et les valeurs prises par les variables (il y a maintenant de très bons outils de débogage dans la quasi totalité des langage) et si vous n'avez pas d'outil à votre disposition, écrivez des messages dans un fichier de traçage...
Avantages :
1) votre programme a toutes les chances de fonctionner rapidement et sans erreur.
2) on n'a jamais le temps de revenir dans un source pour ajouter, après-coup, les commentaires nécessaires.
3) votre programme sera lisible, maintenable et évolutif !

Comment progresser ?
Avant d'inventer la roue, commencer par maîtriser (ou fabriquer) ses outils.
Pour cela, ne pas se lancer tout de suite dans des développements complexes, mais faire des "test-cases" qui, en quelques lignes, mettent en oeuvre la fonction ou l'instruction que l'on veut comprendre et savoir utiliser au mieux. Un des intervenants parlait d'un jeu de LEGO : c'est tout à fait ça !

La curiosité est un vilain défaut SAUF chez les informaticiens
Bien entendu, lisez beaucoup, apprenez, tenez-vous au courant des évolutions techniques et fonctionnelles des outils que vous utilisez, et n'oubliez pas de commencer par la documentation officielle (la non lecture des modes d'emploi est un défaut bien français...)

Le choix du langage :
Le premier langage que vous allez utiliser dépend de votre parcours : secondaire, Fac, IUT... et, à moins d'en avoir été rebuté, il influencera vos préférences.
Faut-il commencer tout de suite par un langage orienté objet ?
Pas évident car, dans le coeur de vos classes, vous devrez programmer de façon structurée et claire... La POO est une surcouche dont le niveau d'abstraction n'est pas indispensable au début. (Pensez au LEGO : on construit d'abord des modèles simples avant de s'attaquer à des interactions entre modèles évolués)
Faut-il choisir un langage "de bas niveau" ?C, C++, c# et dans une moindre mesure JAVA
S'il est vrai que la prise en compte des allocations d'espaces mémoires et d'un typage fort des variables permet de mieux comprendre le fonctionnement interne de la machine, est-ce réellement indispensable dès le début ? Après tout, vous conduisez votre voiture sans être un dépanneur expert ni un constructeur de véhicules !
Les langages "évolués" accessibles (Basic pourquoi pas, mais maintenant PHP) le sont justement parce qu'ils libèrent le programmeur d'un grand nombre de contingences en leur permettant de se concentrer sur le fonctionnement lui-même et non sur son environnement technique.
Il sera toujours temps, si le sujet vous passionne ou si les besoins fonctionnels du projet le nécessitent, de se tourner vers un langage plus contraignant.

Conclusion :
Désolé d'avoir été si long, mais résumer en quelques lignes 30 années de pratique intensive (pro et perso) n'est pas chose facile.
Persévérez, soyez curieux, toujours à l'affût des évolutions, regardez le code des autres pour vous en inspirer (mais évitez le copier-coller bête et méchant, il ne correspondra que très rarement à votre projet personnalisé).
Prenez dès le début de bonnes habitudes (arborescence de votre projet ou de votre site, commentaires judicieux, indentation...)
et puis... pratiquez, pratiquez encore...

Bon courage et beaucoup de plaisir !!!

[alain78]

Bien sûr pour bien apprendre il faut beaucoup développer. Des petites applications pour commencer puis des applications de plus en plus complexes.

N'oublions pas aussi que nous ne sommes jamais seul et que face à une difficulté, il y a très certainement quelqu'un dans la communauté qui a déja rencontré (et résolu) cette difficulté. Donc ne pas hésiter à communiquer avec d'autres développeurs. Attention à ne pas toujours compter que sur les autres. Il faut s'investir dans son propre apprentissage.

En fin dernier conseil, être toujours curieurx et rechercher l'optimisation de son code, de la structure de l'application sans jamais se décourager.

[YobsDebutant]

Bonjour à tous,
Ce que j'aurais aimé entendre à mes débuts, c'est "le développement est un moyen d'arriver à un but, pas un but"...
Comme on développe rarement pour une seule personne (soi même), avant de choisir le langage, la plateforme, il faut avoir une idée claire de ce à quoi on doit arriver (et autant que possible que cette idée soit la même que les utilisateurs ciblés par le développement).
Si je me fie à mon expérience, quand on a un problème, dans 1% des cas c'est parce que le logiciel a été mal programmé, dans 99% des cas c'est parce qu'il a été mal pensé...

[Nebulix]

D'accord à 100%

lisez beaucoup, apprenez, tenez-vous au courant

MAIS ne vous engagez dans de nouvelles techniques que si elles sont TRES utiles, ce qui est à la mode aujourd'hui sera démodé demain et inutilisable après demain. Ce qui est utilisé depuis 30 ans sera encore utile dans 30 ans

[Invité]

Penser par traitements et non par conditionnements !

[Invité]

Mes conseils :
1) Ne pas chercher à avoir un code optimisé, mais lisible.
2) Bosser sur un projet
3) A double tranchant :
Choisir un langage bas niveau, compilé, en console, et avoir de bonnes bases en Algo, et comprendre un peu comment son ordi fonctionne / Ou alors un langage haut niveau, avec des résultats rapides, c'est encourageant. Par exemple faire du graphique, c'est quand même plus simpa que de la console !
4) Prendre le temps de bien choisir son premier langage, se renseigner avant !
5) Avoir un langage qui permet de faire de la POO. La POO c'est le présent et l'avenir en même temps


Edit : Oups, désolé pour le poste x2, j'avais déjà posté dans la catégorie, mais je croyais que suite à la maintenance, mon message n'avais pas été enregistré ...

[Paul TOTH]

(zap)
Faut-il choisir un langage "de bas niveau" ?C, C++, c# et dans une moindre mesure JAVA
S'il est vrai que la prise en compte des allocations d'espaces mémoires et d'un typage fort des variables permet de mieux comprendre le fonctionnement interne de la machine, est-ce réellement indispensable dès le début ? Après tout, vous conduisez votre voiture sans être un dépanneur expert ni un constructeur de véhicules !
(zap)

je suis surpris de cette remarque quand on voit ton parcours. je pense que comprendre la machine éclaire bien mieux le programmeur que n'importe quel HOWTO. C'est d'ailleurs le principal reproche que je fais à Linux, plein de HOWTO et peu ou pas de WHY !

Le typage des variables rend leur usage certain, alors qu'un simple addition sur deux variables non typées peu produire des effets surprenants (concaténation ou addition ?)

De même ce n'est pas parce que le langage est doté d'un garbage collector que le programme ne manipule pas de la mémoire. D'ailleurs le cycle de vie d'un objet managé et bien plus complexe que celui d'un objet non managé et demande - à mon sens - plus de connaissance que les principes bêtes et méchants d'allocation et libération de ressources

Pour reprendre ta comparaison avec la voiture, il n'est pas nécessaire de connaître le détail d'une boite de vitesse pour conduire, mais de savoir que l'essence fait tourner le moteur et le moteur fait tourner les roues ça permet de savoir de quoi on parle Ignorer ce qu'est une allocation mémoire (même managée) c'est ne pas savoir qu'il y a un moteur sous le capot.

[Ricardo_Tubbs]

Un conseil que j'ai déjà donné à des collègues débutants : va consulter le site developpez.com, c'est une mine d'info !!

[ludojojo]

Un conseil tout simple, respecter les normes de développement qui correspondent à la technologie et commenter son code au maximum.
Tout simplement par ce qu'il y à deux choses très énervantes !

• Dans le travail en équipe il est très énervant de perdre du temps par ce que l'on cherche à comprendre ce que l'autre à fait (personne ne code pareil...)
• Perdre du temps sur un morceau de code que l'on à écrit il y a 6 mois ou 1 an et dont on ne comprend plus toutes les subtilités...

Un petit plus, penser à la place de l'utilisateur, trop d'application que ce soit web ou non, garde un esprit développeur et ça se sent. Une application doit être simple à utiliser ! (enfin le plus simple possible...)

[tchamp]

Je ne suis pas du tout d’accord avec lui sur ce point:
« on ne peut "avoir des pensées" que dans sa langue maternelle »

C’est justement les nouvelles possibilités de penser qui rendent intéressant l’apprentissage de nouveau langages — de programmation du moins — à condition qu’ils soient suffisemment différents de ceux qu’on connait.

[NEfanda]

Bonjour,
Avant de choisir le métier de Développeur, il faut se poser certaines questions:

• Est-ce que j'aime apprendre et découvrir de nouvelles choses en permanence?
• Suis -je rigoureux et logique?
• Suis-je prêt à passer des heures devant un problème et à chercher des solutions?
• Aii-je un goût pour la recherche?

Ensuite, quand on a choisi ce métier, je faut savoir rester humble devant un développement. En effet, même un développement simple peut parfois poser des problèmes. Dans ce cas, il faut essayer de ne pas se décourager et être persévérant.
Enfin, Développeur est un métier passionnant où l'on a toujours l'impression de découvrir de nouvelles choses. C'est un métier de chercheur, premier métier, qui m'a passionnée.
A bientot
Nicole EFANDA

[captainKirk]

S'il y a des langages à apprendre en priorité, pour moi c'est l'algorithmique et UML, ce sont les bases. Ensuite l'algorithme et le diagramme peuvent aisément être transposés dans n'importe quel langage (objet quand meme pour UML ), c'est juste la syntaxe qui change.

Il ne faut pas avoir peur de se lancer dans plusieurs langages différents, un un peu comme pour les langues, plus on en connait, plus il est facile d'en apprendre de nouvelles car on trouve des similitudes.

Enfin, je dirais qu'il ne faut surtout pas négliger la phase d'analyse. Trop souvent on se lance dans le code directement sans trop savoir où on va, il en résulte généralement un code illisible, mal structuré, pas maintenable ni évolutif. On voit aussi souvent des développeurs qui ne mettent aucun commentaire dans leur code en pensant qu'ainsi ils se rendent "indispensables" pour leur employeur. Il faut garder à l'esprit que personne, aussi compétent soit-il, n'est irremplaçable. Si on doit reprendre un code non commenté par exemple un an après son développement, ca devient très fastidieux s'il n'y a aucun commentaire et que le code est mal structuré, car en un an il s'en passe des choses et on a largement le temps d'oublier ce qu'on avait fait...

Une étude (d'IBM si je me souviens bien), avait montré que le coût d'un projet croît de manière exponentielle plus on découvre un problème tard dans la phase de développement. Grosso modo, si on passe un peu plus de temps sur l'analyse pour identifier les éventuels problèmes qui pourraient se poser dès le démarrage du projet, ca a certes un coût, mais qui sera très inférieur au coût qu'engendrerait le déploiement d'un logiciel qui comporterait de gros bugs suite à une analyse insuffisante. Dans ce cas de figure, il peut ensuite s'écouler des semaines, voire des mois avant de parvenir enfin à stabiliser l'application. Trop peu de développeurs sont conscient de ce fait et cèdent trop souvent à la pression de leur hiérarchie qui veut rapidement voir des résultats concrets.

[AbdouAllah]

Bonjour à tous;
- Je dirai à tout débutant "il faut lire, et puis lire, et encore lire ..."

- Pour les francophones que nous sommes un avis personnelle; il faut absolument apprendre la langue de Shakespeare;

c'est vraiment indispensable pour qui veut voir toutes les portes du développement ouvertes.
- Pour cella une méthode que je pratique, pour réserver mon temps au vif du sujet "le développement";

c'est de lire des livres en anglais sur mon sujet préféré (bien sur tout ce qui a attrait à la programmation) sur lequel je possède une bonne base, pour acquérir la terminologie sans s'encombrer avec le superflu de la langue.

çà permet vraiment de ne pas s'enlacer avec l'apprentissage de la langue, et d'avoir de l'appétit en mangeant tout doucement;

d'une pierre deux coups

- Un autre conseil c'est d'avoir toujours un stylo et du papier à côté de soi pour décortiquer les concepts et dessiner des pointeurs, des listes, des couches .... ça permet voire claire et du coup facilite la mémorisation, un schéma bien fait vaut mieux que milles explications.

[Excellion]

Fais autre chose...

[scotnplutn]

Bonjour,

Mon constat est que bien souvent un langage de programmation nécessite des compétences technique variés, une culture et beaucoup de logique.

Compétences techniques car en générale il faut connaître (voir maîtriser) plus d'un langage.

La culture : un peu de lecture ne fait pas de mal et permet de se rendre compte des techno du moment et à venir (revues spécialisées, Google, livres,...).

La logique, pas seulement dans le but de développer de bons algorithme, mais surtout avoir une vue d'ensemble de son projet, savoir ou l'on va et comment y aller (je dirais même l'analyse).

Et surtout, en dernier point, ne pas sous-estimer ses compétences, beaucoup se dénigrent en se disant par exemple je ne sais faire que du php, html, css... alors qu'avec ces acquis, il peuvent déjà trouver un job et intégrer la grande et magnifique famille des développeur !

[boulet_sensei]

Ne jamais baisser les bras ! Au départ, beaucoup de notions, concepts peuvent sembler incompréhensibles et cela est normal. On n' apprend pas un métier en une journée, encore moins dans le secteur informatique. Tout viendra avec le temps, soyez patient.

D'après moi un bon programmeur est un programmeur curieux qui cherche constamment à connaître de nouvelles choses, comprendre à 100 pourcent les outils qu'il utilise. Sans cette curiosité, on ne progresse pas.

Enfin, certains métiers se font par nécessité. Dans le domaine de l'informatique, je pense qu'il faut le faire par passion. Si on n' est pas passionné, c'est peine perdue d'après moi.

Ceci est l'avis d'un humble programmeur java/php -- en plein apprentissage de python !

[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.

[zaventem]

Enfin pour finir, pensez toujours à optimiser votre code, deux exemples simples

De mon point de vue, c'est justement le genre le genre d'optimisation que j'interdis à mes développeurs
Pensez avant tout à ce que votre code soit lisible rapidement, par n'importe qui. N'optimisez pas pour vous faire plaisir mais uniquement si cela apporte une réelle valeur ajoutée.

Code :

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

1
2
if(monexpression == true) // deviens if(monexpression)

A ne faire que si le nom de la condition est extrêmement clair et ne changera pas en cas de refactoring

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
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;
}

A nouveau, on perd en lisibilité sans que cela apporte quoi que ce soit de plus au niveau du code. Par contre, pourquoi ne pas écrire

Code :

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

1
2
3
4
5
function bool isValid(object monObjet)
{
   return monObjet.toString().Equals("test"));
}