Discussion :

[psykokarl]

Mais du coup :
- on montre/apprend quand l'objet ?
- quand est-ce qu'on n'est plus débutant ?
- quand est-ce qu'on n'est plus assez débutant pour voir l'objet ?

Ce genre de discution pose toujours le "problème" de "il ne faut pas à tel moment", et en lisant les commentaires et expériences de chacun, on se rend compte que.. finalement c'est toujours un mauvais moment.
Du coup : c'est quand le bon moment !?

L'idéal serait d'introduire la POO parallèlement à des cours programmation procédurale structurée en soulignant les équivalences entre une structure procédurale et une structure en objet.

L'important est que le développeur comprenne que l'instanciation d'un objet n'est pas anodin. Il faut qu'il y ai une conscience intuitive de ce qui est caché. On sortirait en même temps de l'amalgame assez courante entre POO et programmation modulaire.

Il reste le problème des pointeurs qui reste relativement compliqué. Peut être la syntaxe en C est trop concise pour un apprentissage rapide. L'important est de différencier les concepts tels que:
- l'adresse;
- la zone mémoire allouer à cette adresse;
- les données stockée une zone mémoire.(données pouvant être elles même des adresses)

Cela pourrait être abordé assez vite, au cours du premier semestre si la finalité est de développé en objet.

[psykokarl]

La cible c'est d'avoir un emploi. La grande majorité de offre demeure sur des techno basé sur la POO (et du web). Alors effectivement pour des Bac Pro et des Bac+2 cela vaut mieux de commencer par un langage POO professionnel (Java par exemple) parce franchement pour un débutant celui qui a fait que du pascal durant sa vie scolaire son CV il passe en dessous des autres et pourtant j'ai bossé avec des mecs très compétent mais pendant en un moment ils ont ramés pour se remettre à niveau.

Tu peux voir les choses a court termes. Apprendre le minimum pour avoir ton job le plus rapidement possible et rester un minimum de temps au stade développeur.
Tu peux ne pas être gêner par le fait d'enchainer les formation de deux jours, multiplier dans le meilleur des cas le passage de certifs, dépenser une somme substantielle à chaque pour ajouter quelques lignes à ton CV.

C'est une probablement la meilleure manière de gérer sa carrière.
Cela dit, le milieu professionnel ce n'est pas la panacée. Il est plus question de faire du blé que de faire bien.
Alors attention à ne faire pas l'erreur de te croire meilleur que les autres en particulier vis à vis de ceux qui sont en dessous.

[Invité]

Tu peux voir les choses a court termes. Apprendre le minimum pour avoir ton job le plus rapidement possible et rester un minimum de temps au stade développeur.
Tu peux ne pas être gêner par le fait d'enchainer les formation de deux jours, multiplier dans le meilleur des cas le passage de certifs, dépenser une somme substantielle à chaque pour ajouter quelques lignes à ton CV.

C'est une probablement la meilleure manière de gérer sa carrière.

C'est une vision à très court terme, et une carrière, c'est long...

Le CV avec les techno à la mode, et les certifs qui vont avec, ça permet de se vendre en SSII en début de carrière, tant qu'on est très bas dans l'échelle salariale. Mais on est rapidement concurrencé par des petits nouveaux qui ont sur les CV des technos un peu plus à la mode, des certifs un peu plus récents, ... et qui coutent moins cher.

On peut ensuite espérer sortir du développement, et passer à la gestion de projet, mais c'est de plus en plus encombré (par les anciens développeurs, qui avaient des technos à la mode sur leur CV, et qui sont assez jeunes, dans l'ensemble).

Bref, les technos à la mode, je vois assez bien l'intérêt de la SSII, mais nettement moins celui du salarié. Enfin bon, je dis ça...


A mon avis, une meilleure façon de gérer sa carrière à moyen terme, c'est de peu à peu se spécialiser, et faire son trou sur un domaine dans lequel l'évolution est possible, et qu'on aime assez pour pouvoir y rester. Bref, le début de carrière, c'est plus un moment où l'on devrait essayer d'acquérir les bases qui permettront d'évoluer, plutôt que de tenter à monter vite dans des voies déjà très encombrées.

Francois

[Pierre Fauconnier]

[HS]

Tu peux voir les choses a court termes. Apprendre le minimum pour avoir ton job le plus rapidement possible et rester un minimum de temps au stade développeur.[...]

Comme si c'était dégradant d'être développeur et qu'il fallait au plus vite se débarrasser de cette tare

Etre développeur, c'est un métier. Si tu veux être autre chose que développeur, n'apprends pas les matières qui sont celles du développeur. A quoi cela sert-il à un resp de projet d'avoir des certifs sur les dernières versions des derniers trucs à la mode?
[/HS]


Moi, je pense qu'il faut apprendre les deux en même temps, et qu'un cerveau normalement constitué est capable de "n'être distrait" ni par l'un ni par l'autre. On n'est pas à la maternelle, me semble-t-il.

Je me méfie toujours de ces gurus qui savent, qui dictent, qui dogmatisent. La vérité et la réalité sont bien souvent éloignées de leurs prédictions et de leur façon de voir.

[Paul TOTH]

[HS]



Comme si c'était dégradant d'être développeur et qu'il fallait au plus vite se débarrasser de cette tare

Etre développeur, c'est un métier. Si tu veux être autre chose que développeur, n'apprends pas les matières qui sont celles du développeur. A quoi cela sert-il à un resp de projet d'avoir des certifs sur les dernières versions des derniers trucs à la mode?
[/HS]

je pense que ceux qui s'intéressent à l'objet pur vont naturellement s'écarter de la technique (qui est décevante) pour aller vers la gestion de projet, ou d'autres métiers.

le "codeur" s'intéresse à la problématique technique, et ne vise pas forcément cette évolution.

évidemment ce sont des tendances et chacun possède son libre arbitre

Moi, je pense qu'il faut apprendre les deux en même temps, et qu'un cerveau normalement constitué est capable de "n'être distrait" ni par l'un ni par l'autre. On n'est pas à la maternelle, me semble-t-il.

Je me méfie toujours de ces gurus qui savent, qui dictent, qui dogmatisent. La vérité et la réalité sont bien souvent éloignées de leurs prédiction et de leur façon de voir.

il ne faut pas oublier que tout cela n'avait rien d'évident quand on a commencé. Je me souviens de mon prof de fac qui râlait quand on oubliais un point-virgule dans un programme Pascal en disant que c'était pourtant "évident" ! avec du recul je pense surtout que c'était mal expliqué avec des règles aussi con que "mettez un ; systématiquement en début de ligne pour être certain de ne pas l'oublier" !!!

[Katyucha]

[HS]
Comme si c'était dégradant d'être développeur et qu'il fallait au plus vite se débarrasser de cette tare

Tu n'es pas au courant ? le vrai métier, c'est chef de projet, c'est le must, la fin en soi, le graal, l'anti accord absolu !!
</ironie>

Pour revenir au sujet, je fais jamais d'objet, je pige rien à l'objet... Et pourtant mon code est lisible (ca dépasse rarement les 100 lignes ok..)
Par contre, faire lire un code objet à quelqu'un qui débute, c'est sur, tu le perds directement !

[magnus2005]

Pour répondra à psychokarl :
1 : En général un bon développeur == un développeur expérimenté donc celui qui a passé le plus de temps dans le métier. Ce qui est vrai pour tous les métiers intellectuel à mon avis.

2 : pour être un développeur expérimenté il faut commencé par être développeur débutant. donc avoir un emploi et c'est la que l'on apprendra largement plus.
Pour moi l'importance dans la formation initiale c'est apprendre à apprendre et de maitriser le grand concept. Je pense que faire la POO permet de plus simplement atteindre cet objectif. Faire du procédurale en premier n'a rien de mortelle mais force de constaté que l’appréhension et la conception d'une architecture est différente entre les gens qui ont été formé en premier la POO et ceux qui ont été formé par le procédurale cela sans jugement de sur la qualité de l'archi d'une application.
Chacun a toujours des arguments valable à faire valoir.

3 : Oui je suis supérieur hiérarchique mais je ne suis pas un développeur supérieur pour autant. Il ne semble pas avoir écrit cela.


4 :

le milieu professionnel ce n'est pas la panacée

J'ai la chance de faire un métier qui me passionne et j'ai une certitude c'est dans le milieu professionnel qu'on apprend le plus. En plus j'aime ce travail car nous pouvons rendre des services énormes pour tous nos clients et ils nous disent Merci.

il ne faut pas oublier que tout cela n'avait rien d'évident quand on a commencé.

C'est vrai que c'est loin. La je me base surtout sur nos recrutements récents et le point de vue que j'ai aujourd’hui.
Quand je faisais du C++ je pensais que les pointeurs s’était important et que Java se compliquait la vie mais avec le temps j'ai compris que les concepts intégré dans Java était la pour corrigé à certain souci du C++. Java (comme C#) n'est pas "omnipotent" comme le C++ mais il est plus adapté pour faire de la qualité.

[ManusDei]

si tu veux des développeurs capables d'intégrer une équipe suivant des normes de développement strictes, avec un langage full objet du type Java, et des frameworks MVC ... tu commences par UML loin des ordinateurs, tu fais de la théories et tu les amènes petite à petit au code qui n'est alors qu'une projection sur la machine de la théorie enseignée avant.

Ouais enfin, si t'attend trop longtemps pour passer sur du code, tu perdras tes étudiants en cours de route, et tu pourras reprendre les cours d'UML (presque à zéro) quand ils découvriront le Java ou autre POO.

Edit : Ce qui m'est arrivé (ainsi qu'à ma promo) sur tout un tas de cours, dont l'UML

[MiaowZedong]

J'ai la chance de faire un métier qui me passionne et j'ai une certitude c'est dans le milieu professionnel qu'on apprend le plus.

T'apprends beaucoup dans le milieu pro, mais je ne pense pas que t'apprenes à coder en "pissant" du Java full objet pour utiliser la logique préfabriquée d'un framework à la mode ou en débuggant les oublis bêtes du code de ton prédecesseur.

Quand je regarde mes collègues experimentés, ils savent plein de choses du genre "ce serait bien, mais si tu fais ça et que tu tombes sur un os tu plantes le projet, alors évite" mais ils oublient la différence entre un algo en temps constant et un algo en temps logarithmique

C'est vrai que c'est loin. La je me base surtout sur nos recrutements récents et le point de vue que j'ai aujourd’hui.
Quand je faisais du C++ je pensais que les pointeurs s’était important et que Java se compliquait la vie mais avec le temps j'ai compris que les concepts intégré dans Java était la pour corrigé à certain souci du C++. Java (comme C#) n'est pas "omnipotent" comme le C++ mais il est plus adapté pour faire de la qualité.

Ça dépend de ce que t'entends par qualité....ça permet surtout de faire travailler en groupe des gens qui ne comprennent pas le hardware sur lequel ils bossent.

[psykokarl]

Comme si c'était dégradant d'être développeur et qu'il fallait au plus vite se débarrasser de cette tare

C’était un sarcasme.
Je ne suis pas de ceux qui le pensent mais je ne suis pas sur d'être dans la majorité.

1 : En général un bon développeur == un développeur expérimenté donc celui qui a passé le plus de temps dans le métier. Ce qui est vrai pour tous les métiers intellectuel à mon avis.

Généralement en effet.
Mais dans le développement comme dans bien d'autres métiers il y a plusieurs axes de progressions. Ceux qui feront progresser au niveau de la hiérarchie ne seront pas forcément ceux qui te feront progresser au niveau technique.
Pour le reste je te laisse à ta définition d'un bon développeur car c'est une définition subjective. Un bon développeur est le développeur qui répond le mieux à des attentes données en fonction de circonstances données.

2 : pour être un développeur expérimenté il faut commencé par être développeur débutant. donc avoir un emploi et c'est la que l'on apprendra largement plus.
Pour moi l'importance dans la formation initiale c'est apprendre à apprendre et de maitriser le grand concept. Je pense que faire la POO permet de plus simplement atteindre cet objectif. Faire du procédurale en premier n'a rien de mortelle mais force de constaté que l’appréhension et la conception d'une architecture est différente entre les gens qui ont été formé en premier la POO et ceux qui ont été formé par le procédurale cela sans jugement de sur la qualité de l'archi d'une application.
Chacun a toujours des arguments valable à faire valoir.

Personnellement le milieux professionnel m'aura appris à travailler en équipe, améliorer ma communication, travailler efficacement (plus vite). Niveau technique ce n'est tout à fait ça. Sauf si on se limite au cas concrets.

Après il faut pouvoir être force de proposition de temps à autre. A ces moment la il et intéressant de ne pas être formé dans le moule du prêt à l'emploi pour un instant t-1.
Au bout du compte l'important reste la finalité du projet. La souplesse au niveau de la conception d'un architecture est forcement un avantage et le pattern appris en école n'est pas forcément la meilleure solution.

J'ai la chance de faire un métier qui me passionne et j'ai une certitude c'est dans le milieu professionnel qu'on apprend le plus. En plus j'aime ce travail car nous pouvons rendre des services énormes pour tous nos clients et ils nous disent Merci.

Le milieu professionnel c'est beaucoup de marketing. Les partenaires éventuels y vendent leurs solutions. Les solutions les plus en vogue ne sont pas forcément les meilleures. Généralement il faut se méfier des effets de mode et des annonces publicitaire.
Au passage votre phrase me fait penser à celle d'un publicitaire . Pour ma part je suis plus pragmatique. Je m'adapte au modèle économique de l'entreprise dans laquelle je bosse.

[Myna bayi]

[Jay13mhsc]

Le couteau sert à tuer des gens... mais, ça serait dommage de prohiber son utilisation...
Ya pas que la POO qui compte.
Ya aussi YAGNI, DRY, KISS, SOLID, SoC, IoC....

[Ble4Ch]

Bonjour,

Je suis loin d'être développeur, je suis amateur à ce niveau, non pas pour en faire mon métier (en tout cas c'est pas prévu lol), mais plus par curiosité.

Donc je pense que mon avis, qui n'est qu'un avis, pourrait intéresser, ou pas

Tout ça pour dire que j'ai commencé en C (avec les pointeurs, les tableaux double entrées etc..), puis un peu de pratique sur HTML/PHP avant de grapiller 2-3 notions en C++ d'un prof de dev à qui j'avais posé quelques questions sur cet objet...

Ben franchement, à moins de connaître un minimum la "logique de programmation", savoir découper ses programmes en fonctions etc... On est très vite largué en objet ! En tout cas je l'ai été.
Pourquoi ? Car en plus de toutes les difficultés de prog, s'ajoute également la notion d'objets et de classes qui, si le reste n'est pas acquis, nous fait une belle ratatouille dans la tête

Bon après je n'ai jamais tenté la prog objet, mais je pense néanmoins qu'elle n'est pas adaptée aux débutants sans un minimum de pratique avant...
D'ailleurs d'une manière générale, je trouve que la meilleure pédagogie qui soit est le découpage des informations.. Mais c'est un autre débat^^

[theooos]

Je suis en ce moment étudiant à l'IUT info de Lyon et pour rassurer certains professionnels avertis... Nous commençons bien notre rencontre avec le monde du développement par du C et C++ tout en mettant l'accent sur des bases solides. l'Utilisation des pointeurs et de l'adressage sont des exercices quotidiens. Nous suivons pendant de nombreuses heures hebdomadaires des cours d'Algo ou nous manipulons tableaux, structures, chaines de caractère....
La jeunesse ne prend pas toujours les raccourcis et heureusement, nous respectons nos pères qui ont des choses à nous transmettre.

Bien Amicalement

[deuz59]

Pour l'apprentissage purement technique, la POO est une façon de programmer à apprendre parmis d'autres, pas forcément en premier lieu.

Perso débuté sur du Turbo Pascal avant de passer au C, plus permissif et ensuite POO, programmation fonctionnel, etc... je trouve ça pas mal comme progression d'apprentissage technique

Maintenant on ne fait pas de l'info pour faire de l'info. Le côté solution/problème est réducteur, professionnellement la partie technique doit être un choix secondaire et tant qu'on peut s'en passer, on ne devrait pas y réfléchir.
L'objectif est donc davantage de raisonner fonctionnel et l'idéal serait au final une architecture qui colle au plus prêt de ce fonctionnel, ne serait que pour la maintenabilité. Dès lors, la POO répond souvent très bien à cette problématique et on peut avoir un code dont la structure est reflet des specs. Au final si traduire en POO certains nouveaux concepts pour les introduire à l'existant s'avère trop compliqué et conduit à une solution à l'alambiqué, il y a de forte chance que c'est parce que les specs ne sont pas cohérentes. Une bonne modélisation POO du code peut donc le faire devenir garant des specs.

La question est davantage tourner sur 'comment on présente la POO' à 'quand on l'apprend'...mais en effet, apprise trop tôt, elle devient vite un but et non un moyen

[iznogoudmc]

Pour moi ce type de raisonnement est biaisé dès le départ. Si tant de langages et de paradigmes différents existent, c'est bien parque qu'on emploie pas les mêmes outils ni méthodes pour construire un porte-avions qu'un Airbus A380, ou qu'une centrale nucléaire ou un meuble Ikéa !

Connaitre le procédural, les pointeurs, la gestion de la mémoire est un atout précieux dans l'embarqué, le système, la recherche de performances. Et pourtant en POO on peut aussi obtenir d'excellents résultats dans ces domaines.
Utiliser la POO est un gage de sécurité et d’efficacité sur de gros projets qui ont une longue durée de vie.... pourtant en procédural on peut le faire aussi sans problème.
Et il y a toutes les étapes intermédiaires.

Je pense qu'il serait bon de commencer par apprendre les notions sur les pointeurs, la gestion de la mémoire, l'optimisation, le procédural, la POO, etc. etc. etc..... puis de donner le choix !

[Nebulix]

Enfin !
J'ai toujours trouvé que la POO était une complexité totalement inutile. Je me sens moins seul.
Est-ce le début d'une prise de conscience générale ?

[Golgotha]

Du coup : c'est quand le bon moment !?

A mon avis, il faut aller dans le sens historique de la programmation, c'est à dire que, comme dans la plupart des métiers, on commence par apprendre les bases.

La programmation a son histoire, quoique je ne sais pas ou en est l'historiographie de cette discipline, mais pour moi la logique voudrait qu'on apprenne tout d'abord comment fonctionne le processeur, la mémoire, puis ensuite commencer à travailler sur les langages : l'assembleur, pour faire un premier lien entre la machine, la mémoire et le langage de base. Il n'est pas nécessaire de rentrer dans le détail bien sûr, mais de comprendre les concepts, être capable de comprendre comment la machine fonctionne à bas niveau, ensuite on passe au langage C, passage tellement important, puisque ça a été et ça reste un langage important, comme la machine à vapeur, le langage C à fait évoluer la programmation, il faut comprendre ce langage. A ce stade vous êtes comme une maison qui se construit avec de bonne fondation, bien posé. Le prochain niveau pour moi ça reste le langage C++, évolution naturel du langage C, qui apporte la programmation orienté objet, la boucle est bouclée... la maison est construite. A partir de là, n'importe quel langage est à votre porté.

Voilà mon point de vue, classique et lent, mais bon, "ya' pas de secret" comme ont dit

[deuz59]

C’était un sarcasme.
La souplesse au niveau de la conception d'un architecture est forcement un avantage et le pattern appris en école n'est pas forcément la meilleure solution.

Le pattern doit servir à la souplesse de la conception, à la traduction des concepts et specs fonctionnels (métier). Il est notamment utile pour certaines factorisation de code.

Dire que ce n'est pas forcément la meilleure solution n'est pas juste.
Le design pattern, comme tout autre outil de codage (ex POO : héritage, interfaces...), n'est jamais une solution, juste un moyen. D'abord tu cherches à modéliser au plus prêt des specs, ensuite tu utilises un pattern ou autre si c'est adapté pour le faire. Si on prend comme autre exemple le recours à des API externes, trop souvent c'est vu comme une solution au lieu d'un moyen. Exemple : je dois intégrer un flux de données => le mauvais réflexe est souvent de se dire tout de suite "Je vais utiliser la bibliothèque java.io" au lieu d'aller dans le sens "Je dois intégrer un flux, je commence par devoir ouvrir ce flux, ensuite je dois le lire (décodage, validation.... je passe les détails) avant de le l'intégrer pour finalement le fermer" avec cette analyse on peut déjà coder sans implémenter....la décision de choisir "java.io" pour l'ouverture du flux ne se fait qu'en dernier lieu si on estime que c'est adapté pour répondre à cette fonctionnalité (moyen et non but).
Au final, organisation par couches d'abstractions, la plus basse doit être unitaire et c'est elle qui comporte l'implémentation finale (outre la lisibilité/maintenabilité de code, cela facilite également la rédaction de tests unitaires, ainsi que le changement de choix d'implémentation sans toucher à la logique métier, limitant les risques de régression). Pas besoin donc de réfléchir trop tôt au pattern, API, etc. à utiliser.

Après rien ne nous empêche de faire une version naïve qui fonctionne, tant qu'on se repose ensuite les bonne questions pour réorganiser le code.

[deuz59]

Enfin !
J'ai toujours trouvé que la POO était une complexité totalement inutile. Je me sens moins seul.
Est-ce le début d'une prise de conscience générale ?

Les méthodo/process de l'aérospatiale sont très complexes également....dès lors que tu dois représenter/modéliser/maintenir un système complexe, faut pas s'attendre pouvoir le faire avec des instructions élémentaires