Supplique aux enseignants

Publié le par

Chers enseignants,

j’ai le plus grand respect pour votre travail de recherche et votre dévouement à l’enseignement de vos connaissances. Vous faites un travail important, et bien souvent très mal payé. C’est avec tout ce respect et la gratitude pour l’enseignement dont j’ai bénéficié que je vous demande, aujourd’hui, de bien vouloir lire ce message qui vous est destiné et de le prendre avec toute la considération due lors de votre enseignement du langage Java.

En tant que modérateur et contributeur du forum Java sur developpez.net, je dois régulièrement avec mes homologues intervenir sur le forum débutant. On y trouve souvent des questions relatives à des exercices donnés en cours, des travaux pratiques, des projets à réaliser pour l’université. Il n’y a aucun mal là à cela en soit et nous restons très vigilants pour encadrer strictement toute question de la forme « veuillez faire mon exercice pour moi ».

En tant que développeur Java à temps plein depuis 2004, je pense par ailleurs pouvoir affirmer que j’ai aussi une solide expérience des besoins en entreprises et des possibilités du langage.

C’est donc avec les pieds dans ces deux mondes que je me permet d’attirer votre attention sur une certains nombre de points récurrents dans les questions de nos membres et qui ne devraient pas avoir lieu d’être dans le cadre d’un enseignement en adéquation avec les besoins d’entreprises et la réalité du langage Java.

La classe Terminal, Console, Clavier

Certainement, à mes yeux, la classe qui fait le plus de mal aux étudiants. Combien ne sont pas passé sur le forum, tout perdu parce que, chez eux, il n’y a pas de classe « Terminal » dans leur Java? Combien de junior en stage ne se sont-il pas retrouvé démuni face à l’absence de cette classe dans l’entreprise où ils travaillent?

Vous utilisez souvent cette classe pour gagner du temps en cours, car beaucoup d’exercices demandés aux étudiants impliquent une interaction utilisateur via la console. Cette classe fait un mal considérable. En étant utilisée tous les jours par les étudiants, cela deviens un automatisme pour eux de s’en servir. Hors cette classe n’a rien de standard ou de couramment utilisée en entreprise. Son utilisation ne devrait donc pas être un réflexe!

Une des premières choses qui devrait être enseignée aux étudiants en informatique, c’est de ne pas réinventer la roue. Hors, c’est ce que fait cette classe. Elle fournis des méthodes, souvent douteuses et contrevenant aux recommandations et bonnes pratiques du langage, implémentant des comportements déjà présents dans d’autre classes Java. La qualité de l’implémentation dépend souvent de la mouture utilisée mais cette classe n’a jamais lieu d’être.

Chacun d’entre vous dispose de sa propre mouture de la classe, avec son comportement propre. Certains d’entre vous appellent cette classe « Clavier » ou même pire « Console ». Rappelons à ce titre que Java fournit une classe Console et que ceci peut confondre l’utilisateur et le lecteur.

Certes cette classe pouvait avoir son utilité dans le cadre de l’enseignement de Java 1.4, afin d’éviter de perdre du temps à enseigner aux élèves comment récupérer un nombre depuis System.in. Cependant, Java 5 est sorti depuis 2004, soit depuis bientôt 7 ans, et fourni la classe Scanner qui s’utilise comme ceci:

1
2
3
4
import java.util.Scanner
//.......
Scanner sc = new Scanner(System.in);
int i = sc.nextInt();

Je peux aussi vous assurer que dans le cadre professionnel je n’ai jamais vu personne me fournir un code, que ce soit dans des applications « homebrew » ou dans les nombreuses applications open source disponible auprès d’organismes réputés comme apache, codehaus ou objectweb, comportant quoi que ce soit qui s’approche de « Terminal ».

Donc, s’il vous plaît, bannissez toute forme de classe « custom » récurrente de votre enseignement.

Cessez d’écrire vos notes de cours

En Belgique, la dernière fois que j’ai eu des informations à ce sujet, on m’a expliqué que l’enseignement représentait entre 10 et 20% du temps de travail d’un universitaire appointé. Le reste étant consacré à la recherche et tout ce qui tourne autour. Écrire des notes de cours prend un temps considérable. Avec optimisme, on peut envisager qu’une personne, à temps plein, est capable d’écrire un cours correct, corrigé et dont tous les exemples ont été testés et validés par un confrère, en deux mois.

Cela donne, dans votre cas, entre 10 et 20 mois nécessaires pour réaliser un cours complet. A coté de ça, le rythme de sortie annoncé par oracle pour les futures versions de Java standard sera d’une version majeure tous les 18 mois. En parallèle il y aura aussi une version majeure de Java Enterprise tous les 18 mois, avec un décalage dans le temps par rapport à Java standard.

Beaucoup d’entre vous n’ont pas matériellement le temps de réaliser un cours exempt d’erreurs et à jour. Il n’y a rien de mal à ça, les contraintes de votre fonction sont ce qu’elle sont. Mais la conséquence est là, beaucoup d’entre vous donnent soit un cours désuet, basé sur des paradigmes de programmation vieux de 7 à 10 ans, soit un cours à jour contenant des erreurs ou des mauvaises pratiques. Lorsque l’on recherche des notes de cours sur les sites des université, en général, il suffit de lire 5 pages du cours pour y trouver au moins un code qui ne compilera pas ou aura des effets de bord non gérés.

N’hésitez pas à réutiliser des cours existants et réputés dans la communauté. Il n’y a aucun mal à exiger des étudiants qu’ils se procurent un livre de cours réputé et plébiscité par la communauté Java, tels que le « thinking in Java » de Bruce Eckel (anglophone et un peu vieux) ou Developpons en java, de Jean-Michel Doudoux. Ce qu’il y apprendront dépassera de loin ce que vous aurez le temps de leur enseigner pendant les heures de cours et les suivra dans leur carrière professionnelle.

Je ne doute pas que certains d’entre vous (comme Serge Tahé de l’université d’Angers, dont un certain nombre de cours sont disponibles sur developpez.net) réalisent de très bon cours Java. Mais ceci est un travail à temps plein que beaucoup d’entre vous ne peuvent pas se permettre. Pour nous, entreprises, qui sommes au final les utilisateurs finaux de votre produit « Ã©tudiant formé à Java », il est souvent bien difficile de faire désapprendre aux juniors les mauvaises pratiques qu’ils auraient acquises par vos notes. Le choix des mots dans un enseignement écrit est souvent extrêmement important, une idée ou un concept mal exprimé peut avoir de lourdes conséquences pour celui qui vous lit. Et pour ceux qui travailleront avec lui plus tard.

Interdisez vous d’interdire

Et accessoirement, arrêtez de demander à vos étudiants d’implémenter des listes chainées ou des dictionnaires!

Une des qualités premières d’un programmeur Java, pour une entreprise, c’est sa capacité à réduire au minimum le code nécessaire pour réaliser une application, afin de garder ce code lisible, facilement maintenable et de coûter le moins cher possible. N’interdisez jamais à vos étudiants d’utiliser des possibilités de l’api java qu’ils n’ont pas encore vu en cours. En faisant ce genre de chose, vous allez brider et désavantager des étudiants qui nous sont précieux, ceux là même qui réfléchissent pragmatiquement à réduire au minimum leur charge de travail, à être efficaces.

Je comprend votre besoin de voir vos étudiants démontrer qu’ils sont capables de réaliser une boucle, une méthode, de gérer une valeur de retour ou une exception. Cependant, un peu d’imagination permet de fournir des exercices ne reproduisant pas des fonctionnalités déjà présentes dans l’API. A mes yeux, lorsque vous demandez comme exercice « Créez une liste chainée pour gérer les Client dans une Banque », ce genre de réponse devrait être encouragé et mériter la note maximale:

List<Client> clients = new LinkedList<Client&gt();

En fait, dès votre premier cours de travaux pratiques, vous devriez expliquer aux étudiants ce qu’est la javadoc, comment l’utiliser, comment elle est organisée. Nombre d’opérations de base (tri, recherche, copie de tableau, dictionnaires, listes, etc) y sont déjà implémentées et il est ridicule pour un programmeur d’aller réinventer la roue. C’est une des premières choses qu’on enseigne aux étudiant, n’allez pas leur dire qu’on ne réinvente pas la roue en informatique pour ensuite punir ceux qui ont la fainéantise d’appliquer ce principe à la lettre pour réaliser votre exercice en 10 minutes.

De la même manière, punissez les élèves qui vous réalisent une application qui dépasse de loin ce qui a été demandé. Quand un client demande une application pour gérer une liste de contact, dans laquelle il peux ajouter des contacts, chercher des contacts, supprimer des contacts, le tout en ligne de commande, il est inutile et contre-productif pour une entreprise de créer une application graphique, qui capture la photo à la webcam, se synchronise avec un LDAP, sauve sur une base de donnée locale, fait des backups réguliers, permet l’exportation au format iCal et fait le café tous les matins. Ce genre d’application est difficile à maintenir, a un rapport qualité prix bien moindre et, souvent, ces fonctionnalités amènent des bugs qui ne seraient pas là autrement. Une fonctionnalité non demandée manifestement buggée devrait apporter autant de points négatifs qu’une fonctionnalité demandée et non présente ou buggée.

La directive package doit être utilisée systématiquement

Tout code Java doit posséder une directive package, afin de préciser à quel package appartient la classe. Les classes sans package ne seront probabement plus autorisée par Java dans les future versions. Déjà, actuellement, elle ne sont plus reconnues par certains SecurityManager entourant les applets. Nombre de règles de la JLS s’appliquent difficilement à une classe n’ayant pas de package. Par exemple, protected, est visible des classes dans le même package, mais quid quand il n’y a pas de package? Enseignez rapidement à quoi sert la directive package à vos étudiants et forcez les à l’utiliser.

Halte aux fausses vérités

Croyez le ou non, certains cours contiennent des éléments erronés. J’en ai fait les frais à mon époque et beaucoup d’étudiants continuent à recevoir une information erronée sur le language java. Je me permet donc ici de remettre l’église au milieu du village sur deux points.

Java ne crée pas systématiquement un constructeur par défaut et n’appelle pas automatiquement le constructeur du parent. Java ne crée un constructeur par défaut sans argument QUE si aucun constructeur explicite n’est présent dans la classe. Si vous avez des constructeurs explicites dans votre classe avec des arguments, et que vous avez besoin d’un constructeur sans argument, vous devez l’écrire vous même, quitte à ce que son corps soit vide. De la même manière, Java n’appelle automatiquement le constructeur du parent QUE si ce parent dispose d’un constructeur sans argument. Sinon, vous devez faire un appel explicite à super.

Beaucoup de cours mentionnent encore que java transmet, lors des appels de méthodes, les objet par référence et les types de base par copie. C’est faux. Java transfère toujours tous les arguments de la méthode par copie! Cette idée fausse vient du fait que l’objet n’est pas copié. En java, toute variable est soit un type de base, soit une référence vers une instance. Donc en résumé, java transfère donc par copie aussi bien les types de base que les références vers les objets. Il n’y a pas de passage de paramètre par référence en Java.

Les bonne pratiques d’aujourd’hui ne sont plus les mêmes qu’il y a 8 ans

Avec l’avènement de Java 5 et Java 6, nombre de bonnes pratiques ont changés. Je ne vais pas les énumérer ici car, comme je l’ai dit, de très bon cours sont disponibles à ce sujet. Je vais seulement attirer l’attention sur quelques points qu’il faudrait, à mes yeux, systématiquement présenter aux étudiants le plus tôt possible:

Les classes génériques sont très facile à comprendre dans leur utilisation de base, utile dans 90% des cas. La plus grande partie de l’api de base java a été reconstruite pour utiliser les generics. Il n’est pas concevable d’inciter les étudiants à utiliser les apis de base sans utiliser les Generics. De même, les boucles for étendues sont à privilégier sur les Iterateurs. Je vous rappelle à ce titre que List n’est pas du tout la même chose au niveau du comportement que List<?> ou que List<Object>. A ce titre, l’utilisation non typée d’une classe générique devrait être interdite, ce n’est prévu en Java que dans le cadre d’une rétro compatibilité avec Java 1.4.

Les annotations sont très importantes dans la vie d’un programme java et prennent de plus en plus de poids avec chaque version. Ces métadonnées sont souvent très utiles pour faciliter la vie du programmeur. Incitez vos étudiants à utiliser @Override. Expliquez leur aussi à quoi servent @Deprecated et @SuppressWarnings car, tôt ou tard, il y seront confrontés.

Les enums devraient être préférés à l’utilisation de valeurs clés stockées dans des int.

Java, c’est aussi du café

Alors si vous me croisez dans un couloir de votre université un jour et que vous voulez discuter de tout ce que j’ai écrit plus haut, je prendrais un café noir, avec deux sucres :). Ce billet est ouvert aux commentaires et susceptible d’être amendé avec le temps. Je répondrais à toutes les questions dans la mesure du possible.

En vous remerciant chaleureusement de m’avoir lu jusque là,
David Delbecq

19 réflexions au sujet de « Supplique aux enseignants »

  1. Ping : Recap java, semaine 13, année 2011 | Blog de la rubrique java

  5. Très bon article. C’est très intéressant,je vous félicite.Premièrement je comprend ce que tu as dis au début sur la vigilance aux réponse.comme tu dis « nous restons très vigilants pour encadrer strictement toute question de la forme « veuillez faire mon exercice pour moi ».

    Pour ce qui est de la transmission par copie ou par référence quand j’étais en DEUST mon prof me l’avait enseigné mais 2 ans près quand j’ai appris le C# que j’ai vu les 3 cas possibles pour le objet. Mais c’est maintenant que j’ai pu me retrouver en java. A vrai dire je ne me suis pas posé la question ça après avoir appris le cours de C#.

    Je comprend bien que certainement des mentalités qui doivent changer ,il y a des enseignants ne se mettent pas à jour,c’est le même diapo depuis x-temps.Seuls les développeurs s’en soucient vu que c’est eux qui veulent optimiser leurs travail.

    Différencier entre un cours d’algorithmique et un cours du langage. N’étant pas encore un expert confirmé en java, j’ai pu comprendre un certains nombre de chose qui vont m’aider.

  6. Bonjour,

    J’interviens en qualité d’enseignant. Cela fait un petit 10 ans que j’enseigne. Je n’enseigne pas le Java, mais ça n’a aucune importance. Je précise aussi que j’enseigne en Amérique du nord, ce qui modifie légèrement la donne probablement. J’enseigne principalement au niveau des trois années de licence française (baccalauréat ici). Avant de venir ici je suis passé par la France.

    Je pense que ton point de vue, cher David, est orienté vers ce que tu désirerais voir : c’est-à-dire un cours de langage et une formation pour « programmeur Java, pour une entreprise… ». Mais voilà, ce n’est pas toujours (jamais) l’objectif d’un cours. Déjà, les cours de langages sont très rares car profondément inutiles, sauf pour une formation technique à court terme. Mais il me semble que tu t’adresses plus au formation qui forme des analystes programmeurs que des techniciens en programmation. Ce qu’on cherche à offrir dans un cursus universitaire c’est de donner une formation scientifique et non technique. Ceci ne veut donc pas dire former à connaître un langage et une technologie en particulier. Si le langage reste important pour pouvoir pratiquer (et sans pratique pas d’apprentissage), il n’est qu’un outil. Certes, il faut aussi que l’étudiant sache se débrouiller en sortant avec son diplôme. Mais la nature du diplôme est scientifique (je le martèle).

    Donc j’enseigne un cours de C++ qui est en fait un cours d’introduction à la programmation. Nous ne suivons pas exactement la norme C++ pour des raisons qui sont parfois pédagogiques : nous imposons certaines règles qui peuvent paraître bizarre pour un pratiquant aguerri. Mais c’est justement parce que nous pensons en général que c’est une façon d’aider l’étudiant à maîtriser certains points précis : que ce soit à tort ou à raison. Les cours sont aussi là pour former des tout et non se prendre de manière isolés. Ainsi, j’impose dès le début d’utiliser les vector de C++ et je contrains à l’utilisation du at et non des classiques crochets. Puis, dans le cours suivant, ils pratiquent les tableaux primitifs en
    implémentant les vector. Oui nous leur disons qu’ils ne faut pas recréer la roue et les encourageons à utiliser les bibliothèques… mais on leur dit aussi qu’ils seront peut-être ceux qui créeront les bibliothèques. Nous leur apprenons aussi la trigonométrie, la logique, les BD relationnelles, les BD objets la programmation fonctionnelle, les principes de base de l’imagerie, de l’analyse numérique, de l’analyse entière, de la compilation… pourtant beaucoup n’utiliseront pas la matière vue dans chacun de ces cours. En fait, personne n’utilisera directement la matière vu dans tous ces cours.

    Analyser donc un cours et en faire une critique manque le point essentiel : la philosophie et la pensée sous-jacente à un diplôme. À la fin d’un baccalauréat, ils ne doivent pas être tout de suite efficace dans tel ou tel langage (et d’ailleurs lesquels devrions nous cibler sinon ? uniquement ceux voulus par les entreprises ? Ça serait ridicule.) mais ils doivent être capable de dire « en 5 semaines je me forme à n’importe quelle technologie ». C’est un objectif fort différent.

    Plaçons à côté de ça, des étudiants qui sont parfois médiocres en math (perdant la capacité d’analyse d’une structure ou d’un algorithme, sans compter la faiblesse de leur analyse logique), des programmes qui ne peuvent pas tout voir, la pression de la vie professionnel qui fait qu’ils doivent quand même être efficace dans quelque chose en sortant, etc. on en arrive à certaines lacunes que nous essayons tous de vaincre. Mais qui sont constamment présentes… parce que la technologie change justement.

    Ce qui fait que je ne critique pas le geste que tu as eu ici : bien au contraire, il est toujours bon d’entendre un écho venu de l’extérieur du système. Sinon comment s’améliorer. Mais je pense que tu généralises certaines choses (les cours de Java) ce que tu ne devrais pas.

    Maintenant, je suis d’accord sur certain point : un étudiant qui débute devrait apprendre à utiliser les structures avant de les construire; devrait apprendre à faire de la documentation (doxygen par exemple) de manière systématique; devrait apprendre une discipline (un standard) pour l’écriture de son code; devrait apprendre à rechercher et innover (tout en respectant la discipline et les limites imposées)…

    Personnellement, j’essaye de mettre tout ça dans mes cours de première année, puis je demande qu’il n’y ait aucun warning, aucune passe magique (conversion implicite douteuse en C++), que les conceptions soient écrites etc.

    Sauf que je me trompe peut-être aussi ^_^

    Bonne journée… et si tu passes ici (Sherbrooke, Qc, Canada), tu auras ton café.

  7. Salut
    Article très intéressants.
    Ce que je ne comprends pas « cessez d’écrire vos notes de cours ». Le prof, il fait du plagia, du copie/coller ou de la lecture ?
    Ce que je ne peux pas comprendre : pourquoi la javadoc n’a pas de version française ? du genre comme le doc de php, postgresql, sqlserver…

  9. merci à Frank Z pour
    « Je tique un peu sur l’histoire de demander aux profs de ne plus écrire de cours sur un langage particulier.

    Pour l’élève, c’est très précieux : il apprend des concepts et bénéficie de ne pas avoir à séparer le vrai du faux, ou l’important de l’accessoire. Si plusieurs points de vue existent, c’est mieux que le prof synthétise cette divergence.

    Pour l’enseignant, c’est aussi précieux. Ecrire son cours, c’est l’approfondir » ….

    j’écris toujours mes cours au fur et à mesure: je fais évoluer différents cours Java depuis 1996… avec deux versions par an le cours fondamental d’aujourd’hui ne ressemble plus à celui des débuts. Il s’enrichit de l’évolution des pensées de mes collègues, de moi-même et de nos expérimentations pédagogiques : le résultat « scotche » même des programmeurs expérimentés qui nous sont envoyés pour révision des 10000km.
    Ce qui serait idéal c’est d’avoir des documents wiki enrichissables par différents pédagogues expérimentés, ou débutants créatifs intelligents (il y a malheureusement des personnes de bonne volonté mais qui n’ont pas bien compris Java et qui finissent presque par faire autorité!…. suivez la direction de mon regard -> 0 )

  11. Normalement, les universitaires ont pour religion de citer les sources dont ils s’inspirent.

    J’ai fouillé dans les cours d’introduction de l’X pour voir un « Ã©tat de l’art » : ils le font.

    Par ex. :
    http://catalogue.polytechnique.fr/site.php?id=50&fileid=273

    http://www.lix.polytechnique.fr/~liberti/teaching/c++/online/

    Je trouve que quand on enseigne un langage, la recherche théorique n’est jamais très loin. Il faut quelqu’un qui a « de la bedaine » pour fournir une pédagogie propre sur un langage de programmation. L’intérêt, c’est aussi que ceux qui n’ont pas compris par avance (ou en survolant, comme ça doit être ton cas, un manuel de référence) le contenu du cours puissent aussi y accéder.

    Parfois, on peut aussi se trouver confronté à un problème de nature abstraite par rapport à l’informatique. Et là, les manuels de référence des langages existants ne sont pas une bonne réponse. Il faut retourner aux mathématiques…

    Je peux te citer celui auquel je suis confronté (ce n’est pas moi qui l’ai choisi !). J’aimerais bien savoir si c’est un problème de nature informatique ou pas…

    http://fr.answers.yahoo.com/question/index?qid=20091128110039AA4njNo (désolé, c’est un peu verbeux)

  12. On ne fait pas de la philosophie ou de la recherche théorique, on travaille avec un langage qui a une grammaire bien définie et des règles de fonctionnement bien définies. C’est un fait, j’ai vu beaucoup de fausses affirmations dans des cours rédigés pas des professeurs universitaires, erreurs qu’on ne retrouve pas dans de bons bouquins. Quel mal y-a-t-il a dire, lors de son cours, qu’on utilise un bouquin de référence, et inviter les étudiants à le lire? Quand je vois dans des cours rédigés par des universitaires des erreurs de base dans le language, quand j’entends un professeur universitaire me dire que « toutes les classes ont un constructeur par défaut » ou que « toutes les méthodes sont héritées », c’est dangereux. Quand je vois des exemples, en fin de cours, où on utilise des List sans préciser leur généricité et qu’on dit carrément « y a un warning, mais c’est pas grave », c’est faux et dangereux. Quand on ne type pas un générique, par exemple, il y a toutes un série de mécanismes qui se mettent en place dans le compliateur qui font qu’on est très très loin d’avoir un équivalent entre List, List

  13. Bonjour,

    Je tique un peu sur l’histoire de demander aux profs de ne plus écrire de cours sur un langage particulier.

    Pour l’élève, c’est très précieux : il apprend des concepts et bénéficie de ne pas avoir à séparer le vrai du faux, ou l’important de l’accessoire. Si plusieurs points de vue existent, c’est mieux que le prof synthétise cette divergence.

    Pour l’enseignant, c’est aussi précieux. Ecrire son cours, c’est l’approfondir. Le monde universitaire a un rôle clé pour digérer la modernité technique ou scientifique en cours et concepts, stables dans le temps et accessibles à des novices. D’autant plus que tous les élèves ne sont pas forcément des mordus de programmation, mais peuvent souhaiter évoluer vers des fonctions technico-commerciales, de management, décisionnelles, de maîtrise d’ouvrage… Il est tout aussi important pour eux de connaître les concepts du monde dans lequel ils vont évoluer.

    Les enseignants-chercheurs font des erreurs dans les cours qu’ils rédigent ? On a peine à les blamer : ils affrontent avec ouverture d’esprit un océan d’idées éparses, souvent incomplètes et éphémères. J’ai à nouveau du mal à croire qu’un étudiant ou un programmeur débutant dans ses fonctions fera mieux qu’eux. Si des erreurs apparaissent, c’est qu’elles étaient à attendre compte-tenu de la documentation technique « ouverte » disponible. Un petit méa culpa des professionnels de l’informatique ne ferait pas de mal. En plus, je doute qu’un enseignant-chercheur refusera de dialoguer avec un professionnel du métier s’ils sont en désaccord.

    Et puis, si Oracle va fournir une nouvelle version de Java tous les 18 mois, ça ne veut pas dire que tout ce qu’elle contiendra méritera d’emblée l’attention des universitaires et des étudiants.

  14. Ce qui est horrible avec les étudiants, c’est que tu n’as que très peu d’heures pour leur donner les bonnes bases de travail. Et souvent le prof qui est passé avant toi n’a pas eut le temps de finir son programme, qui de toutes manières n’était pas suffisant… Résultat, tu te retrouves à devoir faire passer 2 fois plus d’info à des étudiants qui ne prendront pas la peine d’approfondir à la maison et de vraiment comprendre de quoi il retourne si tu ne leur mâches pas le travail, et encore là je parle des plus motivés. Du coup tu te retrouves à expliquer des trucs bidons et faire des raccourcis dangeureux… Comment expliquer les génériques ou les listeners à des étudiants qui ne savent pas ce qu’est un enum, un final, encore moins un static, ou qui ne connaissent les interfaces que de nom ?…

  16. Salut David,

    Je te demande la permission de m’inspirer de ta missive pour Office en général et Excel en particulier. Lorsque je « récupère » des personnes en formation qui ont « appris » Excel à l’école, que de choses à corriger. L’enseignement d’Excel dans les circuits officiels en Belgique est souvent une véritable plaie, et les exercices donnés sont souvent, voire toujours, déconnectés de la réalité de l’entreprise…

    A+

  17. Salut,

    Assez vrai dans l’ensemble.
    Bon j’ai un peu fait la moue sur le passage concernant les listes, mais c’est tout à fait logique avec la distinction algo/langage ;)

    Le problème vient aussi du fait que certaines études n’ont pas de vrai cour d’algo et que tout cela est mélangé avec les cours du langages…

    Sinon il y a quand même un point sur lequel j’aurais des réserves : @SuppressWarnings !

    La majeur partie du temps il est préférable de corriger le warning (sauf en cas d’utiliser de type Generics sans paramétrage). Le problème c’est que l’ajout de @SuppressWarnings devient un réflexe sans même avoir à réfléchir sur ce que cela implique. Et ça c’est pas bon !

    a++

  18. Bonjour, merci de votre commentaire, je vais y répondre assez succintement.

    En ce qui concerne l’exemple des liste chaînées, il y a deux aspect.
    L’aspect algorithmique (connaissance des algorithme de base, tri, liste, recherches, calcul matriciel, calculs récursif etc). Ce genre de chose est en général abordé dans une cours d’algorithmique théorique. Bien qu’on puisse utiliser java comme support pour tester les connaissances des étudiants dans ce domaine, ce n’est alors plus un cours de java, mais un cours d’algorithmique que vous faites. Mon billet cible bien l’apprentissage du langage ;)

    L’aspect pratique: éviter d’utiliser ArrayList quand LinkedList serait plus performant. Ce cadre, selon moi, peut très bien être abordé en demandant aux étudiants de gérer plusieurs centaines de milliers de données dans une liste. Il pourraient alors constater de visu les différences de performance entre les deux implémentations, sans avoir besoin d’implémenter eux même l’algorithme.

    Pour le « surplus de travail », il ne s’agit pas de désavantager l’étudiant qui en a fait plus et où tout fonctionne. Vive la créativité et la recherche personnelle. Il s’agit de ne pas laisser passer une erreur ou des mauvais pratiques dans le code sous prétexte qu’elle est dans un module non demandé, ni de compenser une erreur dans un besoin demandé sous prétexte que d’autre besoin non demandé à été satisfait. Bref d’éviter, je caricature, la situation « ca fait rien de ce que j’ai demandé, mais je te met quand même ta moyenne parce que ça fait plein d’autres choses ». Une erreur doit avoir le même poids pour tout le monde, qu’il y aie ou non la machine à café dans le programme. Si vous n’appliquez pas cette règle, ce n’est plus un exercice que vous soumettez à vos étudiants, c’est un concours où vous dites « Ã©patez moi, le meilleur à 20 points ».

    Les clients et utilisateurs adorent la recherche personnelle et le fait de proposer des alternative novatrices aux besoins. Ce qu’il ne veulent pas, c’est que ça leur coute beaucoup plus cher ou qu’au final ça ne marche pas. En entreprise comme en cours, ca devrait être la même chose: si tu veux faire plus, libre à toi, mais si ça casse tout, tu assume! Fait d’abord ce qui est requis. Si tu veux faire plus, essaye et si ça rate, ne le montre pas.
    Un bug dans une fonctionnalité non demandée, ca reste un bug et donc une défectuosité plus ou moins grave pour le client. En reprenant l’exemple de l’agenda, si lors de votre synchronisation à un LDAP ça efface toute la base, le premier truc que va vous demandez le client sera « vous trouvez normal de perdre toutes les données? » ;)
    En université c’est la même chose, quand vous recevez des fonds pour une recherche dans un certain domaine, tant que vous n’avez pas fini d’explorer ce domaine, si vous utilisez ces fonds à faire une recherche dans totalement autre chose, vous allez avoir de sérieux problèmes avec le comité de gestion de l’université!

    Il faut donc bien garder en tête chez vos étudiants que le développement à blanc (sans besoin exprimé du client) et en général une mauvaise chose, car cela part du principe que le développeur sais mieux que le client ce dont il a besoin, ce qui est largement prétentieux de sa part. Des idées, c’est bien, mais vérifiez toujours avec votre client/utilisateur si c’est en adéquation avec ses besoins.

  19. Très bon article.
    En effet, beaucoup trop de mauvaises pratiques sont apprises durant la formation univesitaire.

    Cependant, un point particulier me fait tiquer : « Interdisez vous d’interdire ».
    Bien qu’effectivement ré-implémenter chaque fois une liste chaînée est inutile, faire une première implémentation soi même (durant le cours) permet d’appréhender les différences qu’il peut y avoir entre deux implémentations de List, et l’intérêt d’en utiliser une par rapport à l’autre.
    A l’opposé, beaucoup trop de développeurs utilisent des ArrayList tout simplement parce qu’ils ne connaissent que cette implémentation, ou parce que « c’est celle qu’ils ont l’habitude d’utiliser ».
    Ce travail d’implémentation, qui doit-être considéré comme « théorique » uniquement (dans le sens, qui n’est pas sensé être réutilisé dans un cadre autre que le cours de java) peut avoir une importance fondamentale, en particulier lorsque le cours donné n’est pas une approche de java le langage uniquement mais du développement en général aussi.

    Autre point, concernant les étudiants qui veulent en faire trop.
    Pour simplifier ce que j’interprète, il faudrait punir un étudiant qui essaye de faire plus dans le cadre de l’apprentissage, que ce soit un succes ou un échec.
    Outre le fait que ce soit l’opposé absolu de « interdisez vous d’interdir », ce fonctionnement n’est pas très pédagogue. Punir les personnes qui _essayent_ de faire mieux c’est les empêcher d’évoluer et limiter leur potentiel.
    Il ne faut pas oublier que la formation (universitaire ici) n’a pas pour but de préparer les étudiants au fonctionnement des SSII mais aux différents emplois dans le monde de l’informatique, que ce soit dans la recherche ou dans le service.
    Dans le cadre d’une formation professionnelle, cette idée serait « plus envisageable » mais quand bien même, ce n’est pas à l’école de fournir cette partie la de la formation, mais bien à l’entreprise. D’ailleurs, même dans le cadre de l’entreprise, l’idée d’une « punition » pour quelqu’un qui essaye d’en faire plus me parait plus qu’étrange. Effectivement mettre des limites en entreprise et signaler à quelqu’un que ce qu’il fait peut (potentiellement) être contre-productif mais l’idée d’une « sanction » appliquée semble inapproprié.

Laisser un commentaire