Fait le bon choix.
Version imprimable
Fait le bon choix.
A tous les débutants :
1) Commencez par le début sans brûler les étapes.
2) Une fois le langage maîtrisé soyez créatif. Je crois que c'est le plus compliqué. Réfléchissez au projet et à son organisation puis écrivez le code en utilisant l'algorithmique.
3) Patience, courage et persévérence sont les maîtres mots !!!
4) Bien programmez nécessite beaucoup de temps et il absolument le faire avec le plus grand plaisir exactement comme lorsque vous allez au cinéma voir un bon film ou allez à la plage.
5) Rien n'est impossible il faut du temps une sacré dose de travail !!
ne serais-tu pas tout blanc / tout noir ?!Citation:
Envoyé par pmithrandir
je pense qu'un débutant doit déjà essayé de comprendre la logique de programmation, quelque soit le langage...et ne pas écrire des choses comme "IF A NOT = B ..." mais "IF NOT (A = B)" ou comprend ce que peux vouloir dire "X = X + 1" qui est un non sens mathématique !
après il y a une question de gout
Code:
2
Code:
2
Code:
2
3
4
5
6
7
8
9
le problème de Java (pour un débutant) à mon sens est qu'il nécessite l'apprentissage du framework en plus du langage.Citation:
Envoyé par pmithrandir
Aucun conseil mais bienvenue au club...
quand au conseil que j' aurais aimé recevoir fin des années 70, "achètes toi une canne à pêche petit" et vas pêcher... Je plaisante bien sur.
Un conseil : prendre du plaisir à développer, sinon lâcher l'affaire et/ou changer de technologie.
Oui et non : quand on débute c'est interessant de comprendre de refaire comment la roue fonctionne...Citation:
Envoyé par Bryce de Mouriès
+1Citation:
Envoyé par phryos
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 estCitation:
Envoyé par isma4
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...
Bonjour,
ça dépend, je m'explique, je suis plus à l'aise à analyser qu'à inventer des concepts (c'est à dire que je peux facilement découvrir des erreurs et les corriger plus qu'inventer des concept, c'est comme un photographe et un peintre ce n'est pas pareil) donc pour un analyste je conseille plutôt de lire le code des autres, alors que pour un développeur je conseille plutôt de bcp s'exercer sur des projets différents
Encore un conseil (mais qui vient, peut-être, d'un développeur qui vient du systèmes et réseaux), il faut comprendre le(s) système(s) d'exploitation(s) sur le(s) quel on bosse.
Surtout si on travail sur des systèmes client serveur (en le web en est un), le fait de comprendre le fonctionnement (au moins partiellement) du système qui tourne sur le serveur et sur le(s) poste(s) de travail(s) est important et peu permettre d'optimiser son code.
Faut pas décourager le débutant non plus.Citation:
Envoyé par metagoto
Moi je dit qu'il faut pratiquer tout en apprenant.
Cela motivera le débutant et l'amènera à progresser
Bonjour,
La première des choses, à mon avis, c'est de bien maitriser l'algorithmique.
Ensuite, je lui conseillerais d'étudier/pratiquer un langage objet (ou au moins, de maitriser le concept d'encapsulation).
Ensuite, je pense que c'est histoire de bonnes pratiques.
Un conseil général : Evolutivité, maintenabilité, ré-utilisabilité !
Je conseillerais à un débutant de faire des recherches sur ces trois mots et de voir comment il pourrait les appliquer dans son développement.
Je lui conseillerais des bouquins à lire le soir avant de se coucher ^^
Petit conseil qui me passe par la tête :
L'abstraction : si j'ai une classe BMW, ne pas faire de super-classe Voiture tout de suite "au cas où". Mais plutôt attendre d'avoir implémenté une 2eme entité (2CH par ex) pour faire l'abstraction.
Ne pas commencer par un gros projet, mais par des petits sans grande importance.
Je reprend l'adage de l'architecte :
- Ma première application, je la fais pour mon ennemis,
- La deuxième est pour mon amis,
- La troisième est pour moi.
Ce qui n'implique pas de s'arrêter à 3 !
1) Comme cité ci-dessus, ne pas avoir les yeux plus gros que le ventre : commencer par des petites applications.
2) Etre patient et persévérant : ne pas baisser les bras à la première difficulté rencontrée.
3) Chercher d'abord par soi-même (docs, google...). Trouver par soi-même est valorisant. Demander de l'aide qu'en dernier recours.
Je pense que pour debuter, c# est un bon langage. Et pourtant je n'aime pas microsoft. Je crois que c'est un bon langage car:
. Il permet de faire marcher tres vite et tres facilement un programme, ce qui est encourageant et motivant pour un debutant.
. Il implemente en natif la majorite des D.P., ce qui permet, en les manipulant, de se familiariser avec (meme si je suis d'accord que les D.P. c'est pas le saint graal, je crois tout de meme que c'est bien de s'y frotter pour commencer a penser son code avec un peu de recul)
. Il est globalement bien fait et assez peu permissif (ce qui permet d'eviter de prendre trop de mauvaises habitudes, chose plus risquee si on commence avec des langages tres permissifs comme C ou python par exemple).
Ensuite, il faut a un moment ou un autre passer par un langage plus bas niveau (C, C++, et pourquoi pas Cobol ou Fortran: nous parlons d'apprentissage ici, pas de production) et de l'assembleur afin de comprendre un peu ce qui se passe entre l'OS et le compilateur.
Enfin, mais c'est pour moi optionnel (ca depend de ce qu'on veut faire), s'insteresser aux systemes d'exploitation eux-meme, afin de comprendre precisemment ce que fait le code que l'on ecrit. Mais la je n'ai pas de conseils a donner vu que c'est un domaine ou je suis tres mauvais.
Pour moi, être développeur, c'est être curieux de tout.:ccool:
Poser et se poser mille questions pour ne pas être à côté de la plaque.:aie:
Que ce soit au niveau technique, évolution du langage ou même sur le cahier des charges ou autre.
C'est vrai, qu'il faut souvent se remettre en question:calim2:, mais c'est ça qu est passionnant :mrgreen:
quand ça ne marche pas, il faut se lever, faire un tour se changer les idées et revenir ensuite. Cela ne sert à rien de s'obstiner.
La solution sera évidente au retour. Et sinon : Google est ton ami. :)
Ce n'est pas ce qu'on appelle réinventer la roue ! Réinventer la roue signifie réécrire du code déjà existant et qui fonctionne très bien,ou plus généralement faire quelque chose devenu inutile.Citation:
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?")!
C'est écrire une fonction TakeLeft qui fait exactement la même chose que le LeftStr de Delphi.
Il ne faut pas oublier que derrière un produit se cache un client et que le temps qu'un développeur passe à refaire du code existant, est du temp perdu sur l'échéance de livraison du produit au client.
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.Citation:
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.
Le conseil que je donnerai aux débutant est d'essayer d'acquérir de la méthode (je pense à quelques règles simples à suivre mais qui faciliterons la relecture et la comprehension du code par d'autre programmeur)
- Mettre des commentaires (attention à ne pas tomber dans l'exces non plus)
- Indenter son code.
- Nommer ses variables de manière correcte (ne pas appeller nom et prénom sous le nom St1 et St2 par exemple). C'est malheureusement du vécu !
- Placer toute portions de code qui doit être réutilisé dans une fonction ou une procédure.
- Penser général avant de penser spécifique (et plus particulièrement pour l'Objet)
- Faire une pause (ou autre chose) lorsqu'on butte sur un problème. La plupart du temps la solution nous saute aux yeux avec un peu de recul.
- Simplifier le plus possible les choses. J'entends par là qu'une procédure est sensé faire une chose et une seule. Si pour y arriver, il faut passer par plusieurs autres choses, il faut les sortir de la procédure principale et les appeler.
- Une chose primordiale selon moi, même si ce n'est pas toujours facile, c'est de dissocier les données, le traitement et l'affichage. Cela aide à la réutilisation et évite d'avoir à réinventer la roue parce qu'on lit un fichier CSV à la place d'une base de données où parce qu'un champ ne s'appelle pas parail dans une autre fiche !
et sûrement plein d'autres petite choses auxquelles je n'ai pas pensé sur le moment...
Moi je dirais comme Popo, réinventer la roue ça ne sert à rien dès l'instant que l'efficacité est prouvée.
Par contre, rien n'empêche la personne de découvrir comment cela a été fait comme le rappelle Bryce et le souligne Popo.
Moi ce que je dirai c'est qu'il faut avant tout se poser les questions avant le développement et pas après. On perd peut-être du temps avant de commencer à code mais rien que de poser les différentes étapes peut permettre de s'organiser plus facilement par la suite.
Je pense aussi qu'il est nécessaire de bien séparer les choses et ne pas hésiter non plus à sortir du code dans des fichiers. Lorsque l'on utilise une fonction qui fait du remplissage de DropDownList (ASP.Net), ComboBox (VB), ... il faut bien voir si elle ne sera pas utiliser ailleurs sinon sortir la fonction et du coup, on économise l'écriture d'une fonction, d'une connexion, d'une requête, ....
Il est également important comme le dit Popo d'être clair dans son code. Aujourd'hui par la magie des éditeurs, il y a Intellisense dans la plupart qui permet aux développeurs d'être un peu plus "exotique" sur les noms de variables, je pense qu'il ne faut pas s'en priver. De même pour les fonctions ;)
Pour ceux qui ne connaissent pas encore le procédé (moi je l'ai étudié à l'Université :P) intéressez vous aux Patrons de Conception, sachez que la séparation Modèle Vue Contrôleur dont parle Popo
c'est le patron de conception MVC, il en existe d'autres bien entendu, le Singleton, la Fabrique, ...Citation:
Une chose primordiale selon moi, même si ce n'est pas toujours facile, c'est de dissocier les données, le traitement et l'affichage. Cela aide à la réutilisation et évite d'avoir à réinventer la roue parce qu'on lit un fichier CSV à la place d'une base de données où parce qu'un champ ne s'appelle pas parail dans une autre fiche !
Ce sont des modèles à mettre en place mais qui peuvent être remanier au besoin.
Enfin pour finir, pensez toujours à optimiser votre code, deux exemples simples
Bonne chance à tous ;)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19if(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; }
apprendre a programmer ben deja savoir si c'est a but proffessionel ou juste pour la connaissance ..
et comme disais axel kahn transformer la masse d'information en connaissance c'est pas donnée a tout le monde ... c'est pas facile
j'ai perdu enormement de temps a chercher a droite a gauche des infos ..
deja le tout debut, c'est lire l'anglais lire l'anglais .. parcque sans anglais t'est mort :aie:
le travail de mémorisation étant essentiel je dirais commencer par un bon tuto d'un language un bon tuto d'algo et dés qu'on tombe sur un code interressant utilisé la technique de ninja scrool (hum technique interessante je m'en reservirais) et PAS se disperser un objetcif a la fois... et commencer par le traditionnel pac-man (sans librairie) ou par le archi traditionnel master-mind ...
et expliqué a sont boss Pourquoi il est important de faire du Csharp (avec la petit boulle jaune qui bouge ) !!!:aie:
voila aprés si c'est vraiment pour comprendre donc la ou commence le réel plaisir ... comment la memoire fonctionne et tout les concepts the art of assembly ...royal . les anglo saxon on 100 ans d'avance .
du coup j'ai pas fini mon pac-man :mouarf: et la master mind ...
Deux petites choses simples :
Préfère aux noms de variables trop courts des noms long mais compréhensibles.
Et....
Y'a jamais trop de commentaires.
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 !!!
Cela permet de mieux comprendre comment fonctionne un ordinateur.
Avant de commencer à apprendre un langage il faut se poser la question suivante pour mieux comprendre : "Qu'est-ce qu'un ordinateur ?"
Faites des recherches là dessus pour avoir les bases minimums du fonctionnement d'un ordinateur. Quand vous aurez compris cela l'utilisation de tel ou tel langage sera plus facile. Le choix du langage est avant tout une question de goût puisqu'il en existe plusieurs dizaines.
Une chose est sûr il faut choisir un langage qui est le plus proche de l'être humain c'est à dire un langage objet. Les langages non-objet dit procédurale sont une véritable gageure lorsqu'il s'agit de développer de gros projets. Si ce sont des "drivers" alors utiliser soit l' ,"ASM" ou le "C".
Par exemple quand j'ai commencer à écrire des programmes j'utilisais "Visual Basic" mais arriver à un moment je me posais plein de questions du genre "Mais qu'est-ce qui se passe derriere tout ce qu j'écris ?". Par la suite j'ai abondonné ce langage et puis j'ai trouver "MASM32" un langage assembleur. C'est ce dernier qui m'a permis de comprendre exactement comment fonctionnait un ordinateur. Après cela je suis passé au C++ parce que programmez en "ASM" ce n'est pas possible pour de gros projet pour les "drivers" ok mais c'est tout.
Grosso modo un ordinateur c'est quoi ? :
Une machine electronique qui traite une information. Pour que le microprocesseur de cette machine puisse travailler, toute l'information à traiter par ce dernier doit-être logée en mémoire.
Micropocesseur : JePrendsInformation->JeTraite->EtJeDonneLeResultat.
Ce n'est que ça !
Bien sûr ce cycle se répète à l'infini !