Discussion :

[Paul TOTH]

Mais j'ai quand même un doute... Mon expérience, c'est que l'objet, sur les sujets où il fonctionne, nécessite souvent un investissement plus lourd (donc des délais plus longs) mais permet une meilleure évolution du code (par l'encapsulation et les hiérarchies de classe). Inversement, on peut produire très vite, en objet, du code très sale et parfaitement non maintenable (en multipliant les classes et les liens forts).

j'ai travaillé sur de gros projets objets et de gros projets procéduraux tous les deux vieux de plus de 10 ans, ça donne le même bazar toute une partie du code mal adaptée aux nouveaux besoins est devenu imbuvable, sans documentation avec plus personne qui ose y toucher de peur que l'existant ne fonctionne plus. Dans les deux cas tout le monde était parfaitement conscient que le mieux aurait été de tout reprendre à zéro mais que ça ne serait fait qu'à grands frais pour un bénéfice à long terme...et donc toujours repoussé à plus tard, quand on aura moins le nez dans le guidon...ce qui n'arrive jamais.

[MarieKisSlaJoue]

Il faut avant leur enseigner comment analyser une demande client et comment y répondre.

N'oublie pas que les heures de cours ne sont pas forcément extensibles et souvent chargées. revenons dans le contexte, il est dit débutant, donc on va partir sur aucune connaissance en info alors il faut en 2/3 ans lui donné toutes les bases pour faire fonctionner son pc. Travailler correctement dessus. Résoudre les problèmes les plus mineures qui pourrai arriver. Sans parler que on à beau être dev, les cours de réseau ça fait pas de mal. Vu que le dev c'est pas que de la programmation on rajoute les heures pour apprendre tous sur les bases de données, le sql toussa toussa.

Du coup les cours de programmation pour les débutants ils sont assez light, et faut les rendre près à travailler en entreprise à la sortie. Comment gagné du temps ? En abordant directement l'objet.

Souvent on entend que les jeunes diplômés ne savent rien faire. C'est pas en abordant tard l'objet au risque qu'il passe à la trappe que ça va s’améliorer.


Et encore on oublie pas les cours de math/Anglais/Linux/Windows

[magnus2005]

et faut les rendre près à travailler en entreprise à la sortie

A 100% d'accord, Ceci est ce qui devrait guider l’éducation nationale en général

où une partie des enseignants a une idée assez approximative du monde de l'entreprise.

Ceci est malheureusement vrai dans l’éducation nationale (certain s'y interesse quand même) et aussi un fait typiquement français. En formation il n'y a pas photo par rapport au enseignant qui travaille encore dans le domaine ou il enseigne. Ceci du point de vue des connaissance et de l’expérience. Cela ne préjuge pas de la capacité à transmettre son savoir (il vaut mieux être capable de transmettre le peu que l'on connait que d'être très savant et ne pas savoir comment le transmettre).

Ca me parait être davantage un argument contre le travail dans des structures comme la tienne que pour la POO

Écoute sur un traitement comptable si tu pense que celui qui connait la gestion des pointeur est plus compétent que les autres libre à toi.
Je peux même te dire que certains ne connaissent même pas les tableaux multi dimensions.
J'ai commencé par le C++, je connais bien les pointeurs j'ai fait de l'assembleur mais finalement ceci ne rend pas plus compétent pour construire une application de gestion des congés.

l'objet, sur les sujets où il fonctionne, nécessite souvent un investissement plus lourd (donc des délais plus longs)

De par mon expérience l'objet nécessite investissement le plus minim et les résultat les plus rapides. Ce gain a été acté par l’intégralité des leaders du marché. C'est pour ça que tous les langages modernes désormais intègre la POO (même le COBOL 2000)

probablement la mise au pas d'une équipe hétéroclite, par la mise en place de méthodes communes

Oui aussi

Ensuite, "livré dans les temps", ça veut presque toujours dire bâclé, parce que les prévisions sont toujours optimistes, les difficultés sous estimées, les fonctionnalités "complétées" en cours de route. Et la victime idéale de ce genre de situation, c'est justement la maintenabilité.

Dans le monde de la méthodologie de La RACHE Oui. Perso j'ai opté pour l'XP.
Ceci dit je ne fait pas du R&D. Je travaille en ce moment sur des domaines très classiques (de mon point de vue), Si on a bien analyser le projet, les problèmes de délais sont généralement du à des problème RH qu'autre chose. Personne ne reproche à un chef de projet de ne pas tenir les délais quand un des développeur a disparu pendant 1an.

on peut produire très vite, en objet, du code très sale et parfaitement non maintenable (en multipliant les classes et les liens forts).

Oui à 100% je viens de voir un magnifique exemple de cela hier encore. Cela est souvent du à un problème dans la logique de factorisation qui devrait sauter aux yeux d'un développeur devant une modèle objet.

[chaplin]

C'est sur le moyen terme qu'on juge de la maintenabilité, et on l'obtient presque toujours au prix de délais supplémentaires (en fait de réécritures en milieu de projet, quand on commence à avoir un peu de visibilité sur les vrais problèmes, les limites de l'existant, et la direction des évolutions futures).

Ensuite, "livré dans les temps", ça veut presque toujours dire bâclé, parce que les prévisions sont toujours optimistes, les difficultés sous estimées, les fonctionnalités "complétées" en cours de route. Et la victime idéale de ce genre de situation, c'est justement la maintenabilité.

CQFD

J'ajouterais que lorsqu'on travail en équipe, chaque développeur à son style de développement, mais si plusieurs développeurs travaillent sur les mêmes fonctionnalités, il est indispensable de mettre en commun tout ce qui peut l'être. En POO, les événements sur les objets servent justement à traiter les parties non communes, en laissant la main au développeur le reste étant implémenté dans la classe, c'est à dire la partie commune.

[Invité]

j'ai travaillé sur de gros projets objets et de gros projets procéduraux tous les deux vieux de plus de 10 ans, ça donne le même bazar.

Je crois qu'on est tous d'accord. L'objet ne garantit pas plus que le procédural la maintenabilité du code. Je crois que le principal problème vient du fait qu'on a tendance à laisser le code vieillir.

Mon expérience, c'est que pour garder du code maintenable, il faut investir entre le quart et le tiers de son temps de maintenance en améliorations non visibles de celui ci. Eliminer les redondances, refaire des petits bouts, documenter, parfois simplement prendre le temps de lire et comprendre le code original.

La responsabilité, en ce domaine, est partagée. L'encadrement a souvent peu envie de "perdre de l'argent" sur des développements non directement vendables, mais les développeurs vont souvent au plus simple, et ont tendance à ne pas améliorer le "code des autres".

C'est d'ailleurs une chose qu'il faudrait enseigner (plutôt que la POO, à mon avis): lire du code, le comprendre, et y intervenir sans tout massacrer, en s'adaptant à un style qui n'est pas le sien.

j Dans les deux cas tout le monde était parfaitement conscient que le mieux aurait été de tout reprendre à zéro mais que ça ne serait fait qu'à grands frais pour un bénéfice à long terme...et donc toujours repoussé à plus tard, quand on aura moins le nez dans le guidon...ce qui n'arrive jamais.

Reprendre à zétro terrifie tout le monde (en fait tous les seniors) parce qu'on a tous en tête les produits qu'on a tués au passage "V1-V2 par réécriture complète". Il me semble que la bonne solution est presque toujours une réécriture par morceaux.

C'est généralement plus sûr parce qu'on passe d'un code qui marche à un code qui marche et qu'on peut tester au fil du temps. Ca prend en fait moins de temps que la réécriture, si on tient compte des tests, des régressions, des mauvaises surprises. Et c'est moins déstabilisant pour l'utilisateur (quand la réécriture implique une évolution d'interface).

Mais là encore, c'est le genre de chose que beaucoup de développeurs détestent faire, et que beaucoup de chef de projets trouvent peu valorisant.

Francois

[Invité]

Écoute sur un traitement comptable si tu pense que celui qui connait la gestion des pointeur est plus compétent que les autres libre à toi.Je peux même te dire que certains ne connaissent même pas les tableaux multi dimensions.

Je le crois sincèrement. Sur un traitement un tant soit peu compliqué, l'ingénieur qui a des bases en algorithmiques, et a déjà vu du bas niveau, aura très souvent de meilleurs réflexes que celui qui est entré dans le métier sur des paradigmes haut niveau.

En gros, le premier tiendra compte de la volumétrie, parce qu'il sait que c'est là dessus qu'on explose (toujours), il ne se posera pas trop de questions sur la nécessité des tris, le fait qu'il vaut mieux éviter les recherches linéaires, qu'il y a généralement une bonne et une mauvaise façon d'écrire une boucle, saura quand une indirection (ou un passage par valeurs) devient déraisonnable.

Mais c'est surtout lors des tests et du débogage que la différence se verra. Le développeur connaissant ce qui se passe derrière le code saura bien mieux diagnostiquer un bug que celui qui voit la VM ou le compilateur comme une sorte de "magie". Et en débogage, c'est toujours sur le diagnostic que le temps se perd.

Ca ne garantit pas, bien sur, qu'un développeur "technique" soit capable de concevoir une application, de comprendre une problématique, ou juste de communiquer avec ses semblables.

Francois

[el_slapper]

Je le crois sincèrement. Sur un traitement un tant soit peu compliqué, l'ingénieur qui a des bases en algorithmiques, et a déjà vu du bas niveau, aura très souvent de meilleurs réflexes que celui qui est entré dans le métier sur des paradigmes haut niveau.

Pas forcément. C'est d'aileurs à peu près le seul point sur lequel je suis en phase avec Magnus. J'ai vu, très souvent, des programmeurs "techniques" (presque tous des hommes) être aveuglés par la beauté technique de leur code et aller se faire plaisir architecturalement plutôt que de faire au plus simple et au plus efficace. C'est pour ça que j'aime travailler avec des dames - spécialement les plus âgées(de toutes façons, les plus jeunes finissent toutes très vite chef ou MOA). Avec elles, on a du code simple et efficace, qui se limite aux techniques indispensables, qui va droit au but, et qui est facilement réutilisable/refactorisable/encapsulable quand le besoin se fait sentir.

En gros, le premier tiendra compte de la volumétrie, parce qu'il sait que c'est là dessus qu'on explose (toujours), il ne se posera pas trop de questions sur la nécessité des tris, le fait qu'il vaut mieux éviter les recherches linéaires, qu'il y a généralement une bonne et une mauvaise façon d'écrire une boucle, saura quand une indirection (ou un passage par valeurs) devient déraisonnable.

Et? J'ai vu plein de gens formés à la va-vite comprendre assez vite l'interêt de trier pour faire une rupture, ou de sortir d'une boucle quand on a trouvé la valeur que l'on cherchait. Quand le traitement t'a planté deux ou trois fois parceque tu as occupé tout l'espace disque disponible, tu retiens la leçon. Travailler proprement et simplement, c'est beaucoup plus difficille à acquérir.

Mais c'est surtout lors des tests et du débogage que la différence se verra. Le développeur connaissant ce qui se passe derrière le code saura bien mieux diagnostiquer un bug que celui qui voit la VM ou le compilateur comme une sorte de "magie". Et en débogage, c'est toujours sur le diagnostic que le temps se perd.

C'est possiblement utile quand on fait des choses très techniques et/ou compliquées. En info de gestion, passé les 4 opérations, on fait rarement des choses compliquées et/ou techniques.

Ca ne garantit pas, bien sur, qu'un développeur "technique" soit capable de concevoir une application, de comprendre une problématique, ou juste de communiquer avec ses semblables.

Francois

Il aura un avantage - une meilleure connaissance des processus techniques - et une faiblesse - la tendance à surutiliser lesdites compétences.

[ManusDei]

Reprendre à zétro terrifie tout le monde (en fait tous les seniors) parce qu'on a tous en tête les produits qu'on a tués au passage "V1-V2 par réécriture complète". Il me semble que la bonne solution est presque toujours une réécriture par morceaux.

Ca demande donc un code modulable ? Il me semblait que faire des modules le indépendants les uns des autres était la base pour pouvoir maintenir du code.

[Bousk]

Ca demande donc un code modulable ? Il me semblait que faire des modules le indépendants les uns des autres était la base pour pouvoir maintenir du code.

Malheureusement t'as vite fait de trouver quelqu'un qui, sous prétexte de correction d'un bug, avec un peu de laxisme/absence de la part des archis, de manque de règle etc va t'introduire moultes dépendances et "tout casser".

[Invité]

Ca demande donc un code modulable ? Il me semblait que faire des modules le indépendants les uns des autres était la base pour pouvoir maintenir du code.

Bien sur, et tous les programmes sont conçus sur ce principe, je crois. Maintenant, il reste toujours un débat sur la taille des modules. On a longtemps écrit de gros modules, qui pouvaient être inmaintenables (je crois que c'est à cela que faisait allusion Paul Toth). Une école de pensée issue de la POO conseillait, il y a quelques années de les faire le plus petits possibles (micro classes, mini méthodes). Je crois qu'on en revient après s'être aperçu qu'on perd en complexité de l'architecture ce qu'on gagne en simplification du code.

Bref, la modularité c'est nécessaire, mais ça ne suffit pas.

Ensuite, il y a toujours des dépendances, ne serait-ce que parce que les modules fonctionnent au sein du même programme. Au fil des évolutions du programme, cela pose deux problèmes :
- le code spaghetti, qu'on obtient quand on ajoute des "dépendances exceptionnelles" pour régler rapidement un problème urgent, et qu'on oublie de corriger après. Ca peut devenir gênant à force, mais c'est en fait assez facile à corriger
- l'évolution naturelle de la problématique, qui fait que le découpage "naturel" en modules qu'on avait prévu initialement, ne l'est plus du tout.

C'est ce dernier point qui pose généralement problème, et c'est là qu'on a envie de "tout refaire". C'est aussi la principale critique qu'on puisse faire à une certaine vision de la POO (toute celle qui utilise des hiérarchies de classes abstraites, la dérivation ayant tendance à fixer le découpage). En C++, c'est le principal argument en faveur du paradigme générique: ça permet une extension/reconception "par morceaux".

Francois

[DevTroglodyte]

Malheureusement t'as vite fait de trouver quelqu'un qui, sous prétexte de correction d'un bug, avec un peu de laxisme/absence de la part des archis, de manque de règle etc va t'introduire moultes dépendances et "tout casser".

Oui m'enfin là, c'est plus un souci d'intelligence du développeur que de "supériorité" d'un paradigme par rapport à un autre.

[el_slapper]

Bien sur, et tous les programmes sont conçus sur ce principe, je crois. Maintenant, il reste toujours un débat sur la taille des modules. On a longtemps écrit de gros modules, qui pouvaient être inmaintenables (je crois que c'est à cela que faisait allusion Paul Toth). Une école de pensée issue de la POO conseillait, il y a quelques années de les faire le plus petits possibles (micro classes, mini méthodes). Je crois qu'on en revient après s'être aperçu qu'on perd en complexité de l'architecture ce qu'on gagne en simplification du code.(.../...)

Et quand on arrive à des spécifications monstrueuses, de toutes façons, le résultat final va être galère à maintenir et à tester.

J'ai vu un programme batch cobol de 35,000 lignes, dont la fonction était d'enrichir un flux, et qui appelait plus de 70 modules d'accès au données. La plupart des appels étaient dépendants les uns des autres. On a pas mal étudié la possiblité de le couper en morceaux, mais au final, ça n'aurait fait que changer le type de complexité. Il aurait fallu rajouter soit des sous-modules avec des zones de complexité supplémentaires pour discuter avec les sous-modules, soit des petits programmes successifs qui se seraient passé des données un peu dans tous les sens.

Après, sur un langage moderne, on aurait peut-être pu le faire quand même, grâce aux outils de deboguage. Mais on a choisi de ne pas le faire, au vu du prix et des risques.

Pour ce qui est des mini-méthodes, mon premier programme professionel, en VBA, ressemblait à :

Code :

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

1
2
3
4
5
Sub Principal
For ligne = 1 to ligneMax
    Call TraitementLigne(ligne)
next ligne
End Sub

Code :

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

1
2
3
4
5
Sub TraitementLigne(ligne as Integer)
For colonne = 1 to colonneMax
    Call TraitementCase(ligne,colonne)
Next colonne
End Sub

Code :

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

1
2
3
4
5
6
7
Sub TraitementCase(ligne as Integer, colonne as Integer)
If IsNumeric(Cells(ligne, colonne)) Then
    Call TraitementNumerique(Val(Cells(ligne, colonne))) 
Else
    Call TraitementAlphaNumerique(Cells(ligne, colonne)) 
End If
End Sub

Et tout du même genre. Je veux bien qu'il faut découper, mais là, j'allais un peu trop loin, je trouve.....

[bigsister]

Je pense que commencer par la POO est assez rebutant pour les débutants.
Au début, on trouve tous magique un simple echo "Hello World"; qui marche en 30 sec, tandis que 10H d'explication du paradigme POO et l'écriture d'une classe pour faire la même chose... aïe !

Même si c'est lourd, si on a peur l'enseigner les pointeurs autant changer de métier, c'est pas non plus comme résoudre une équation à 10 inconnues.

Néanmoins je pense qu'il ne faut pas trainer à introduire le concept. Perso j'ai énormément galéré pour réellement m'y mettre à postériori, ne serait-ce que pour en comprendre les réels avantages....

[Paul TOTH]

Oui m'enfin là, c'est plus un souci d'intelligence du développeur que de "supériorité" d'un paradigme par rapport à un autre.

non car c'est une dérive qui, au bout de 10 ans, existe quelque soit le paradigme de base.

[gaiasson31]

Je le crois sincèrement. Sur un traitement un tant soit peu compliqué, l'ingénieur qui a des bases en algorithmiques, et a déjà vu du bas niveau, aura très souvent de meilleurs réflexes que celui qui est entré dans le métier sur des paradigmes haut niveau.

Je rejoins ce que tu dis, quittes à me faire taper sur les doigts par certains : un mécano qui sait mettre les mains dans le cambouis aura plus de facilité à entretenir, retaper et construire un véhicule.

[Bousk]

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 !?

[Paul TOTH]

il faut arrêter de penser que "développeur" est un métier unique.

on ne développe pas sous Java, PHP, C++ et VisualBasic de la même façon.

on ne développe pas ComptaFacile, Amadeus et VotrebanqueEnLigne de la même façon (enfin j'espère pour compte compte en ligne).

dernièrement j'ai vu un logiciel de caisse "développé" sous Excel, on coche des prestations et on renseigne la remise et la case "total" donne le montant à payer...les clients sont gérés sur papier...pas besoin d'apprendre la programmation orientée objet pour faire ça. Je ne sais pas si la feuille contient un peu de VBA ou si tout est géré par formule ceci dit.

Or donc, la première question, c'est à quoi veut-on les former ?

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 !?

je reprend mon premier post en même temps que le tient, la bonne question est de savoir à quoi tu veux les former

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.

si tu veux un développeur qui soit capable de répondre à des exigences techniques, des temps de réponse, du partage de ressources, de l'embarqué, tu ne peux pas faire l'économie de ce qu'il y a sous le capot. Peu importe s'il apprend également UML et OOP, il faut également qu'il sache comment fonctionne l'OS, l'allocation mémoire, un garbage collector, ce qu'est un pointeur...il sera probablement amené à utiliser des environnements de développement non objet pour savoir ce qu'il se passe en vrai. Et tout cela n'exclu pas l'objet, mais c'est alors un objet technique, pas un simple concept indépendant du langage et de son environnement d'exécution.

pour moi ce sont des métiers différents, pas forcément incompatibles, mais différents.

[Invité]

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

Dans une formation de développeur, j'aurais tendance à dire qu'il faut commencer à enseigner l'objet quand il devient nécessaire, c'est à dire quand on commence à aborder l'architecture et l'évolution du code. La POO apparait alors naturellement comme une solution à un problème réel, ce qui est, à mon avis, la meilleure façon d'enseigner quelque chose.

Sur une formation en deux ans (type IUT), je dirais en seconde année, après une première consacrée à l'apprentissage d'un langage, l'écriture de petits programmes, l'algorithmique, le fonctionnement des ordinateurs.

En fin d'année, on doit avoir assez d'éléments pour commencer à travailler sur un projet un peu gros, et buter sur les problèmes que la POO viendra résoudre à la rentrée.

Francois

[MarieKisSlaJoue]

Il n'y à pas des stages en première année d'IUT ? Parce que je vois mal un débutant trouver un stage quelque peu intéressant si il n'a même pas les base de la POO. C'est d'ailleurs dans les stages en général que on approfondie très vite les connaissance survolé en cours.

C'est pour ça que j’aurai tendance à dire dès la première année, second semestre exactement.

[magnus2005]

Sauf erreurs de ma part, la programmation objet c'est quand même l'immense majorité du développement de nos jours.

Si la majorité des développeurs font de la POO, alors l'objectif des études d'informatique c'est d'apprendre la POO (entre autres choses).

Or le principe de la "distraction" (en partant de principe que le titre ne parlait pas de distraction au sens récréatif) c'est de détourner quelqu'un de son objectif initial.

C'est comme dire "le missile à été distrait par un avion ennemi et l'a détruit", ça n'a pas de sens.

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.