Lire tout ca :
http://en.wikipedia.org/wiki/List_of...t_philosophies
Lire tout ca :
http://en.wikipedia.org/wiki/List_of...t_philosophies
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
En ce qui concerne les maths, ça aide quand même beaucoup.. après ça dépend dans quel domaine on veut bosser.. Mais par exemple, our faire de la 3D, comprendre l'algèbre linéaire, ça aide beaucoup... Travailler sur des simulations physique, le calcul différentiel peut vous sauver... Et globalement, calculer avec précision la complexité d'un algorithme peut nécessiter un minimum de mathématiques...
Pour commencer, un peu d'humour (un brin réel) :
"Google is your second best friend..."
"developpez.net is your best friend !!"
Je suis étonné que ça n'ait pas été dit plus haut, mon second conseil serait que l'informatique est déterministe. A moins d'avoir trouvé un cas particulièrement rare dans une environnement et un bug réel dans un langage, généralement le programmeur a tort. Le comportement peut sembler archi-aléatoire et rendre des résultats totalement aberrants, c'est toujours une erreur de programmation. Ne pas se laisser décourager devant des comportement arbitraires est parfois difficiles. Certains bugs sont vraiment... mais vraiment... super frustrants.
Sinon, je conseille un langage moderne et orienté objet, de préférence web sur browser (afin d'éviter au début le contact avec les clients lourds, particulièrement difficile à réaliser selon les langages).
Sinon, RTFM
Plus facile, non. Mieux, je pense que oui. Après ça n'est pas la même chose, je suis d'accord que Python est mieux pour apprendre l'algorithmique (ne serait-ce parce qu'il force à indenter correctement son code), mais je ne considère pas le développement et l'algorithmique comme étant la même chose. Le second est essentiel pour le premier (à mon avis) mais je vois beaucoup, beaucoup d'étudiants (que ce soit en MSc ou en PhD) qui ont bouffé de l'algorithmique mais qui ne sont pas fichus d'implémenter quoi que ce soit.Je pense que C++ serait le dernier langage que je conseillerais (aller y a peut-être l'ASM aussi ^^ ). Dire à un débutant de se lancer avec cpp, c'est lui garantir une balle dans le pied...
Salut tout le monde,
je ne vais revenir sur ce que nos sages ont écrit plus haut.
Par contre, j'ajouterai :
- C'est vrai que de commencer par un langage de type VB est, je trouve, plus simple.
Cela permet d'acquérir une LOGIQUE de programmation et par la suite de pouvoir plus simplement passer à d'autres langages (la différence étant principalement au niveau de la syntaxe )
- Ne pas hésiter à demander aux personnes qui connaissent mais ne pas se contenter de recopier bêtement et au contraire chercher à comprendre le pouquoi du comment.
- Toujours commenter ses codes afin de pouvoir y revenir plus tard (si si.. ça peut servir )
- Et comme dit à plusieurs reprises.. le meilleur moyen d'aprendre reste la pratique, se retrouver confronter à une difficulté et chercher à la résoudre.. ça s'est formateur !
Bonne journée à tous.
Jordane
Disons que l'un ne va pas sans l'autre. Mon approche est que l'informatique est là pour résoudre un problème. Savoir analyser le problème, analyser la complexité, et mettre en place une solution algorithmique, c'est le coeur du métier pour moi...
En toute logique, le langage ne doit intervenir que tard dans le développement (mais je manque d'expérience du point de vue professionel pour affirmer ça..)...
Que des étudiants en PHD ne soit pas capable d'implémenter un algorithme qu'ils ont eux-même écrit dans un langage de leur choix me fait peur...
Pour moi quelqu'un qui se lance dans le développement se doit d'être curieux et capable de prendre du recul. Et surtout au début essayer de faire de refaire des algorithme de base(trie, algorithme recursif ...). Pour moi surtout quand on débute le meilleur outils du développeur reste la feuille et le stylo.
Un seul conseil à ajouter à ce qui a déjà été dit : on ne développe pas pour soi, mais pour un utilisateur. Il faut toujours garder à l'esprit les besoins de l'utilisateur, chaque ajout/modification de fonctionnalité doit pouvoir se justifier de son point de vue.
Je lui conseillerais de commencer par une bonne thérapie.
"Des variables globales tu te méfieras"
Pour m'être pris la tête pendant des mois après des cours mal fait de Java, dans lesquels toutes les variables étaient static... pour le coup lors d'un vrai projet ce fût la cata.
Je me considère comme débutant en développement donc si je pouvais me (et aux autres) donner un petit conseil ça serait d'être très organisé et ça passe par : un choix du langage (pour apprendre les bases), des concepts de base bien connus (création de l'objet, instanciation, constructeurs, méthodes, privé/public, fonction/procédures, etc. etc.), et surtout commenter son code au fur et à mesure de la ponte de celui-ci ! Ensuite bien utiliser toutes les fonctions de débug de son IDE pour réussir à faire du très propre en le moins de temps possible...
Et ensuite la pratique, rien de mieux pour toujours avoir le coup de patte.
J'ai commencé il y a un peu plus de 2 ans du VB.NET et je suis maintenant sur C#, je pense qu'il faut également jamais se dire qu'on sait faire, mais toujours avoir cette envie d'apprendre pour faire mieux
Un conseil qui ne vaux peut être que pour moi. Je suis un développeur autodidacte et quand je rencontre des difficultés à me sortir d'un problème je commence par le fameux "c'est un bug" (faut bien un coupable) puis je finis par trouver et là je me dis "mais quel c... je suis" Mais entre ces deux phases il y a le "lacher prise". Une pause qui peux durer jusqu'à 2 jours pendant laquelle je bosse sur autre chose mais qui me permet d'oublier mon problème et quand j'y retourne c'est limite si mon erreur ne me saute pas aux yeux. De plus la nuit porte conseil, une bonne nuit de sommeil et vous voilà frais comme un gardon avec un nouvel algo.
À l'inverse de Leonhart, je dirais à un débutant de ne surtout pas chercher à optimiser. Au contraire, chercher à détailler, (sur-)commenter, faire du code propre et beau plutôt que rapide et dépouillé.
Vouloir dès le départ se prendre la tête à gagner des micro-secondes c'est la garantie de stagner et de s'empêcher de progresser efficacement en restant bloqué sur des broutilles.
Enfin, je dirais que ce qui différencie un développeur expérimenté d'un débutant, c'est sa maîtrise de l'API. Pour amoindrir cette différence, savoir trouver la documentation, et savoir chercher dedans est vital (et apportera souvent énormément d'informations avec des exemples de code, si la doc est bien faite ).
Chercher, chercher, chercher, chercher et encore chercher. Jusqu'à ce qu'on trouve.
Lire, lire, lire, lire et encore lire. Jusqu'à ce qu'on ai compris.
Essayer, essayer, essayer, essayer, et encore essayer. Jusqu'à ce que sa marche.
Pas nécessairement dans cette ordre. Et ne pas avoir peur de poser des questions sur le forum de developpez.com, mais pas avant d'avoir fait les trois première étapes.
Bref avoir de la patience est, pour moi du moins, un pré-requis très important.
le premier conseil que j'ai eu en informatique était dans un livre d'initiation à la programmation sur Commodore 64 (oui je sais ça remonte )
il était indiqué "sachez que quoi que vous tapiez sur votre clavier, vous ne pourrez jamais endommager votre ordinateur...sauf à utiliser un marteau"
bon ce conseil n'est pas forcément aussi vrai sur un Windows Seven qu'il ne l'était sur cet écran :
mais si j'en suis là où j'en suis aujourd'hui, c'est grâce à cette petite phrase qui m'a donné tout pouvoir sur la machine
"Fais confiance aux mecs qui font les normes quand ils te disent de faire les choses d'une certaine manière, dans 99% des cas ca marche mieux comme ca sur le long terme."
Et surtout le plus important :
"Le papier et le crayon seront tes meilleurs amis et tu fera plus efficacement du bon boulot avec eux que collé a ton écran".
Ou, "ne pas confondre vitesse et precipitation."
Plus que le code en lui-même, il faut surtout s'entraîner à modéliser, à schématiser, à analyser.
La programmation orientée objet est parfaite dans se rôle !
Vous avez sans doute remarqué que plus on programme, plus on se met à analyser le monde qui nous entoure et à se dire qu'on pourrait nous aussi le recréer informatiquement ? Des fois, je me dis que la vie est peut-être même un pt1 programme ! Parenthèse terminée, j'ai rendez-vous chez mon psy.
Toujours suivre le modele conceptuel à la lettre. Ne rien inventer qui ne soit prevu par la conception du projet.
Un seul conseil : si ça ne fonctionne pas du premier coup, ça ne veut pas forcément dire que l'idée est mauvaise.
Partager