Témoignages sur vos pratiques de dévelopeur...

Kris73 · Le 30/03/2012, à 21:44

Bonsoir,

vous n’êtes peut-être pas sans savoir qu'une nouvelle spécialité s'ouvre à la rentrée prochaine en Terminale, baptisée ISN = Informatique et Sciences du Numérique; le but est de donner l'envie aux élèves de passer d'un statut de simple consommateur de solutions informatiques, à celui de quelqu'un qui a envie de comprendre ce qu'il y a derrière, voire à celui de créateur de ses propres solutions...
Il y aura une grande part consacrée à l'enseignement d'un langage de programmation, dans l'optique que les élèves réalisent un projet personnel tournant autour des sciences du numérique.

Le souci est que les gens comme moi, qui vont enseigner cette spécialité en venant d'horizons assez variés ( mathématiques, physique, SI,...) et qui ont une vision assez "théorique" de l'informatique, ont du mal à se représenter quel est exactement le processus suivi par un développeur seul ou au sein d'une équipe concevant un logiciel.
Ce serait très instructif si les gens parmi vous qui travaillent dans le secteur pouvaient partager un peu leur manière de faire : je me demande par exemple dans un projet, quelle est la durée de la phase de réflexion "avant codage", quelle part de la durée totale du projet cette phase de codage représente, comment les tàches sont réparties entre différentes personnes...

Dans le programme de cette spécialité, il y a également tout un thème autour de l'algorithmique : je trouve que ce que l'on va enseigner est assez artificiel, et je me demande du coup la manière dont un développeur en situation réelle aborde cet aspect algorithme de son programme : là-aussi y-a-t-il une réflexion préalable "sur le papier", ou alors, comme je me l'imagine, l'algorithme se construit en même temps que le programme lui-même ?

Voila...De manière générale, j'aimerais savoir si les pratiques que vous avez dans votre vie professionnelle sont ou pas complètement déconnectées de la manière dont on vous a fait faire de l'info au cours de vos études, afin de donner aux futurs élèves de cette spécialité une vision la plus juste du métier de développeur...

Un grand merci d'avance !:)

Chris

Hibou57 · Le 30/03/2012, à 22:05

Bonsoir,

Kris73 a écrit :

Le souci est que les gens comme moi, qui vont enseigner cette spécialité en venant d'horizons assez variés ( mathématiques, physique, SI,...) et qui ont une vision assez "théorique" de l'informatique, ont du mal à se représenter quel est exactement le processus suivi par un développeur seul ou au sein d'une équipe concevant un logiciel.

Je n’ai pas d’autorité dans ce domaine, mais j’ai mon idée quand‑même. Elle est que ta vision théorique, tu ne dois pas la voir comme un obstacle pour la compréhension de la part des élèves dans la plupart des cas, parce qu’elle est finalement plus compréhensible que la vision pratique, qui est plus inconnue à priori, alors que la vision théorique aura plus facilement des airs de déjà vu et donc de plus facilement compréhensible (par les maths, etc, qui font déjà parti des cours).

Comme de plus la vision théorique permet de se placer au dessus d’un langage spécifique, et donc de mieux en comprendre les tenant et aboutissant, et même d’avoir la capacité d’aborder plusieurs langages, cette vision théorique est à mon avis la meilleure approche.

Elle pourra cependant poser problèmes avec ceux/celles qui « savent déjà ». Là, ce sera le contraire, la vision théorique va leur paraitre rasoir et ils ne comprendront pas ce qu’ils manquent. Il leur faudra désapprendre ce qu’ils/elles « savent », et ça, c’est connu pour être une opération difficile.

Si j’ai répondu à côté de la plaque, je m’en excuse platement.

Maintenant, tout dépend aussi des objectifs des cours.

Bonne soirée.

Dernière modification par Hibou57 (Le 30/03/2012, à 22:08)

Kris73 · Le 30/03/2012, à 22:18

Merci pour ta réponse, Hibou !

Je suis pleinement d'accord avec ta vision des choses !

Mais je n'évoquais pas le problème de compréhension par les élèves, mais bien le moyen de leur donner une vision juste d'un domaine professionnel, car ils l'idéalisent beaucoup ( "je vais programmer des jeux", "je vais hacker" )...
Un de nos formateurs, enseignant en info à la fac, nous a confirmé que beaucoup d'étudiants s'apercevaient trop tard s'être trompé de filière !

D'où ma volonté de présenter de façon objective tout le travail d'un développeur, sans occulter les aspects "chiants" que les élèves n'ont pas envie de voir !

Hibou57 · Le 30/03/2012, à 22:40

Kris73 a écrit :

Mais je n'évoquais pas le problème de compréhension par les élèves, mais bien le moyen de leur donner une vision juste d'un domaine professionnel

Ça va être difficile, c’est tellement variable.

(boring list) Il y a les développements à petites échelles, réalisés de manières plus ou moins artisanal, il y a les développements à grandes échelles qui s’apparentent plus à de l’architecture et pas tant à de l’écriture de programme, surtout s’ils sont générés automatiquement, il y a les développements qui ne nécessitent pas de validation, ceux qui en nécessitent avec des jeux d’essais, ceux qui en nécessitent sous forme de preuves, ceux qui se font sous la direction d’un chef de projets, ceux pour lesquels ça n’est pas le cas. Et encore, pas dit que la manière dont je catégorise représente bien tout. Ça dépend des domaines.

En fait, l’écriture du programme lui‑même n’est presque rien dans la pratique réel, comparé à tout ce qui tourne autour : méthodes, contextes, exigences.

Il faudrait voir s’il faut inclure les techniques qui accompagnent l’écriture des sources des programmes ou s’il ne faut inclure que de l’algorithmique et l’écriture des sources.

Kris73 a écrit :

Un de nos formateurs, enseignant en info à la fac, nous a confirmé que beaucoup d'étudiants s'apercevaient trop tard s'être trompé de filière !

Justement, ce serait intéressant d’avoir des exemples d’échouges, ça dirait sur quoi portait l’ignorance et indiquerait ce qui doit être présenté.

Dernière modification par Hibou57 (Le 30/03/2012, à 22:42)

Rafbor · Le 31/03/2012, à 10:53

Kris73 a écrit :

...le moyen de leur donner une vision juste d'un domaine professionnel, car ils l'idéalisent beaucoup ( "je vais programmer des jeux", "je vais hacker" )...
Un de nos formateurs, enseignant en info à la fac, nous a confirmé que beaucoup d'étudiants s'apercevaient trop tard s'être trompé de filière !

Bonjour,
j'ai la chance de travailler dans le service info d'une PME de 400 personnes, et je pense être du bon côté de la barrière.
Je crois en effet que l'on peut distinguer au moins 2 mondes de développeurs dans ce domaine: les premiers qui comme moi, sont libres d'analyser, de choisir les outils et d'implémenter un développement sans trop de contraintes, en prenant tout le temps nécessaire, et les seconds, qui travaillent dans une SSII et qui subissent les contraintes de timing, de controle sur leur job et d'obligation de résultat. Ces derniers, je les plains.
Pour les besoins de gros projets, nous sous-traitons à ces SSII l'analyse et le développement. Et j'ai vu des gens pleurer au bureau parce qu'ils ne s'en sortaient pas et que leur boss leur mettait une pression énorme, surtout quand les délais prévus étaient dépassés.
Rien que dans la phase de spécifications, j'ai vu un développeur être obligé de travailler chez lui les nuits et le weekend car le chef de projet n'avait alloué que 5 jours d'analyse, et que c'était insuffisant.
Sur ce même projet, le Cdp nous avait vendu son projet pour 45 jours, alors qu'un concurrent l'avait prévu en 90 jours.
Au final, ils y ont passé 100 jours, et encore, je leur ai enlevé du boulot en refaisant et complétant moi-même certaines parties du code vers la fin.

D'autres aspects du travail pratiqué en SSII sont aussi peu enviables. La spécialisation, par exemple. Les tâches sont en effet distribuées par équipes, et certaines personnes sont donc cantonnées à ne réaliser que les IHM, d'autres ne codent que les tests unitaires, d'autres écrivent la doc, ou les specs, etc.. Pas toujours intéressant, et donc on peut comprendre pourquoi certains sont déçus.

Et je me souviens des différentes périodes de crise dans le métier, qui ont conduis ces entreprises à licencier en masse. Pour cela, les pratiques étaient abominables, on donnait au collaborateur dont on voulait se séparer un projet situé à 600 km de chez lui, irréalisable dans le temps impartis, et l'échec étant assuré, on le virait.

sweetly · Le 31/03/2012, à 11:27

Salut,

pour contextualiser, j'ai développé en contexte industriel (dans une moindre mesure) et universitaire (ce que je continue à faire maintenant et pour les futures prochaines années, sûrement).

Kris73 a écrit :

Bonsoir,
vous n’êtes peut-être pas sans savoir qu'une nouvelle spécialité s'ouvre à la rentrée prochaine en Terminale, baptisée ISN = Informatique et Sciences du Numérique; le but est de donner l'envie aux élèves de passer d'un statut de simple consommateur de solutions informatiques, à celui de quelqu'un qui a envie de comprendre ce qu'il y a derrière, voire à celui de créateur de ses propres solutions...
Il y aura une grande part consacrée à l'enseignement d'un langage de programmation, dans l'optique que les élèves réalisent un projet personnel tournant autour des sciences du numérique.
Le souci est que les gens comme moi, qui vont enseigner cette spécialité en venant d'horizons assez variés ( mathématiques, physique, SI,...) et qui ont une vision assez "théorique" de l'informatique, ont du mal à se représenter quel est exactement le processus suivi par un développeur seul ou au sein d'une équipe concevant un logiciel.
Ce serait très instructif si les gens parmi vous qui travaillent dans le secteur pouvaient partager un peu leur manière de faire : je me demande par exemple dans un projet, quelle est la durée de la phase de réflexion "avant codage", quelle part de la durée totale du projet cette phase de codage représente, comment les tàches sont réparties entre différentes personnes...

En contexte industriel, de ce que j'ai pu faire et voir, les situations sont nombreuses, différentes, sous plein d'aspects :
- Projet à partir de zéro, ou reprise de l'existant
- Travail en équipe, déjà constituée ou à constituer, ou seul
- Contraintes de temps plus ou moins forte
- Contraintes techniques (choix de tel ou tel outil, langage, framework, etc. imposé)
- Le développeur lui-même (ses pratiques, ses motivations, ses compétences, etc)

Bref, difficile d'avoir une idée claire, parce qu'amha, il n'y en a pas. Partant de là, mon expérience me montre :
- Si les contraintes de temps (et de pression hiérarchique) sont fortes, le temps passé au design du code (sur papier) se réduit souvent à peau de chagrin.
- Idem pour faire des prototypes, qui bien souvent servent de base (et donc y compris leur architecture qui n'a pas ou peu été pensée) aux produits opérationnels.
En revanche, si le codeur est bon et arrive à s'imposer (souvent en s'appuyant sur sa compétence, à raison d'ailleurs), il va pouvoir faire ce design comme il veut.
En milieu universitaire, c'est un peu différent, et je vais prendre le cas (qui est la majorité) où la(les) personne(s) qui codent ne sont pas (uniquement) des informaticiens. Dans ce contexte, souvent, cette période de design n'existe pas, pour plusieurs raisons :
- On ne sait pas qu'il faut le faire (si t'as pes informaticien de formation, ça te passe au dessus)
- On a pas le temps (un chercheur n'a que peu de temps à consacrer au code)
- C'est rarement voué à être distribué (test d'une idée, à la base, le plus souvent), et quand ça l'est, c'est après coup, parce que le code intéresse d'autres gens.
- On reprend d'autres codes, et là, n'imagine même pas refactorer.

Bref, cette période "sur papier", de ce que j'ai pu voir était assez négligée. En théorie, je pense que la réflexion sur l'architecture du logiciel à produire doit prendre 30% du temps, le reste se répartissant entre le code et ses commentaires, les tests, la documentation et le débogage. En pratique, je dirais qu'elle prend 0 à 20%., et la moyenne doit être plus proche de 0.

Par contre, enseigner à des élèves que cette phase est importante, autant que le codage, la doc et les tests est un bon moyen d'espérer augmenter le respect de son utilisation à l'avenir.

Dans le programme de cette spécialité, il y a également tout un thème autour de l'algorithmique : je trouve que ce que l'on va enseigner est assez artificiel, et je me demande du coup la manière dont un développeur en situation réelle aborde cet aspect algorithme de son programme : là-aussi y-a-t-il une réflexion préalable "sur le papier", ou alors, comme je me l'imagine, l'algorithme se construit en même temps que le programme lui-même ?

Pour les mauvais développeurs, j'ai tendance à penser que oui. Après, ça me paraît être le pire qui soit. Ceci dit, ce n'est aps parce qu'un développeur négligé la phase de conception qu'il n'a aucune idée de(des) algo(s) général(aux) de son code futur. Ça reste dans sa tête, c'est pas forcément très clair, mais il sait déjà où il va/veut aller.
Apprendre correctement l'algorithmique est un bon moyen d'avoir très vite des idées assez claires sur un projet, sans former y passer un temps long.

Voila...De manière générale, j'aimerais savoir si les pratiques que vous avez dans votre vie professionnelle sont ou pas complètement déconnectées de la manière dont on vous a fait faire de l'info au cours de vos études, afin de donner aux futurs élèves de cette spécialité une vision la plus juste du métier de développeur...
Un grand merci d'avance !:)
Chris

Le métier de développeur, de ce que j'en ai vu, n'est pas déconnecté des études, tout simplement parce que c'est tout de même celle-ci qui nous ont appris à coder. Ceci dit, les contraintes professionnelles font que un logiciel n'est pas toujours développé dans les règles de l'art, et que ça se fait parfois (souvent ?) sentir. Maintenant, ça donne du boulot aux mainteneurs...

Dernière modification par sweetly (Le 31/03/2012, à 11:28)

Hibou57 · Le 31/03/2012, à 12:08

Un petit HS

sweetly a écrit :

Bref, cette période "sur papier", de ce que j'ai pu voir était assez négligée.

C’est aussi parce que les outils pour ça sont trop peu nombreux ou peu praticables. Cependant, je ne sais pas si c’est le mépris de cette étape qui abouti à ce manque d’outils ou si c’est le manque d’outils qui abouti au mépris de cette étape.

Kris73 · Le 31/03/2012, à 19:01

Merci à vous pour ces témoignages...j'en retiens qu'effectivement, les contraintes de temps/budget ont la plus grande influence sur la manière de faire le logiciel et le timing alloué à l'étape de codage...
Pensez-vous que présenter les choses "cash" comme ça aux élèves ( comme je l'ai dit, ils idéalisent un peu la chose...) est possible ??

@sweetly : c'est très intéressant ce que tu me dis sur l'algorithmique en tant que "base de réflexion" du développement mais sans y consacrer trop de temps...je crois que c'est bien comme ça que je vais introduire cette partie du programme !

De manière générale, vous semblez tout de même penser que la phase "réflexion avant codage" est beaucoup trop négligée ? @Hibou : pourrais-tu donner un exemple des outils dont tu parles ?

Je suis toujours preneur d'autres avis et témoignages, même si vous codez en free-lance ou autre...

Chris

Hibou57 · Le 31/03/2012, à 19:25

Kris73 a écrit :

j'en retiens qu'effectivement, les contraintes de temps/budget ont la plus grande influence sur la manière de faire le logiciel et le timing alloué à l'étape de codage...
Pensez-vous que présenter les choses "cash" comme ça aux élèves ( comme je l'ai dit, ils idéalisent un peu la chose...) est possible ??

Moi je dirais que oui et beaucoup oui, parce que c’est malheureusement la réalité la plus preignante actuellement (quelques liens ici : Informaticiens en batterie). Reste juste à savoir si ça va changer ou pas dans un avenir plus ou moins lointain, pour savoir si çe ne risque pas de leur donner une fausse image d’une réalité qui aura peut‑être changé. Mais le minimum de l’honneteté, c’est d’en parler.

Kris73 a écrit :

De manière générale, vous semblez tout de même penser que la phase "réflexion avant codage" est beaucoup trop négligée ? @Hibou : pourrais-tu donner un exemple des outils dont tu parles ?

Tu as presque la réponse dans ta question. Si tu essaie de penser à une chose qui est souvent recommandée dans la littérature spécialisée (même si parfois critiquée aussi), une chose dont les louanges sont souvent chantées alors qu’elle est trop peu mise en œuvre, tu pensera par exemple à… UML. L’état de l’offre en outils pour UML est assez catastrophique (le plus souvent il manque les contrôle de validité des schémas, ou alors la validation est incorrecte). Mais je ne pensais pas qu’à des éditeurs UML. Il y a aussi des langage de modélisation ou de méthode ou les deux en même temps, comme BON (Business Object Notation) ou Hood (célèbre dans le monde Ada). Pour ceux là, l’offre est inexistante à ma connaissance, ou alors elle est confidentielle.

Dans une autre technique, mais servant un but de modélisation aussi parfois, il y a les différentes formes de Literate Programming, et là aussi, l’offre n’est pas terrible, les partisans de ces méthodes galères tout le temps (je suis abonné à un Usenet sur ce sujet). Mais celui là, n’est pas utilisé dans l’industrie, à l’exception de deux ou trois projets de démonstration.

Quoique la phase papier, ne se fait pas nécessairement avec ces méthodes. Un langage de suffisamment haut niveau peut jouer ce rôle : Prolog et LISP et dérivés. Avec ces langages, modéliser, surtout avec Prolog, c’est écrire le programme ; avec LISP (enfin, Ocaml/SML), pour paler de modélisation, il faut plutôt passer par des choses comme Coq (génération automatique de programme à partir de preuves de validité de modèle). Coq est utilisé dans l’industrie, même si c’est de manière confidentielle.

Il en existe, oui, mais ils sont peu répandus, et souvent pas murs (UML) ou inexistant (les divers manière de faire du Literate Programming, ou les concurrent d’UML).

La phase papier, avec l’assistance d’un outil, en tous les cas, ça ne ressemble pas du tout à une phrase papier sur papier.

Il faut faire le trie de ce qui est pertinant.

Dernière modification par Hibou57 (Le 31/03/2012, à 19:33)

Kris73 · Le 31/03/2012, à 19:47

Très intéressant, merci !!

EDIT : j'ai lu les articles du Monde Diplomatique et de Marianne dont tu donnes les liens....BRRR!!! ça refroidit un peu

Je vais me sentir un peu gêné de présenter le monde merveilleux des Sciences du Numérique aux élèves de la spécialité à la rentrée..

Dernière modification par Kris73 (Le 31/03/2012, à 19:55)

BFB · Le 01/04/2012, à 20:34

Pour mes pratiques de développeur, je fait l'algorithme et la programmation en même temps, sauf quand c'est trop compliqué, ou que ça ne marche pas. Là passer par le papier permet de se libérer des contraintes du langages de programmation:
Syntaxe peu pratique ou type de syntaxe interdite, allocation de mémoire, structures de données rigides et peu adaptable au problème en cours.
L'abstraction, c'est la base de la science, et en informatique, on galère encore pas mal, raison pour laquelle on change de paradigme de programmation 5 fois en 40 ans.

Avant on essayait de tout prévoir depuis le début, comme à la construction d'un pont, mais ça ne marche pas. (~80% du code écrit est jeté)
Ensuite on a rajouté de la souplesse, mais ça ne suffisait pas non plus.
Ensuite on a fait du prototypage rapide, du "test drivent développement".

Bref, pour ce qui est de la bonne manière de développer un logiciel, on ne la connaît pas encore.

Là je sors un peu du sujet du thread, mais je ne résiste pas à rajouter deux choses.
Il n'y a pas de honte à utiliser les aspiration des élèves. S'il se fantasme la vie d'informaticiens comme celle d'un hacker ou de quelqu'un qui programme des jeux vidéos, c'est pas si mal. Dans cette situation, les choses difficiles à apprendre ne devienne plus le but mais le moyen.
Il y en a des choses à apprendre pour faire des jeux vidéos: géométrie, vecteurs, nombre complexes, changement de repaires, utilisation de coordonnées cartésiennes et polaire, passage de l'un a l'autre. Et encore, là c'est que les math, on peut rajouter la physique, l'économie, l'histoire, la philosophie et encore pas mal de chose très facilement.
Quand le but c'est d'avoir son petit casse brique qu'on a fait soi-même, d'un seul coup, on ne se traîne plus pour apprendre comment on calcule le rebond d'une balle.

Sinon, encore une chose, je ne sais pas si cette envie est personnelle ou générale, mais ça m'aurait fait du bien d'entendre au lycée les limites de la science, ce qu'on ne sait pas encore faire. On ne sait pas faire gros programmes qui ne bug pas par exemple. On peut dire "je me coupe le bras si le théorème de Pythagore ne marche pas sur un cas", mais pas avec un programme informatique de quelques milliers de lignes.

Pour finir un dernier "conseil" pédagogique. A la fac, en première année quand on apprends l'informatique, les profs déroules presque toujours les algorithmes "pas à pas" avec un exemple. C'est essentiel pour comprendre comment marche les variables les conditions et autres.

Bon, j'espère ne pas avoir trop abusé, et que la partie HS valait la peine.

Kris73 · Le 01/04/2012, à 22:38

Non, non , au contraire, ton avis est extrêmement précieux, merci !!

HP · Le 01/04/2012, à 23:55

Rafbor a écrit :

Je crois en effet que l'on peut distinguer au moins 2 mondes de développeurs dans ce domaine: les premiers qui comme moi, sont libres d'analyser, de choisir les outils et d'implémenter un développement sans trop de contraintes, en prenant tout le temps nécessaire, et les seconds, qui travaillent dans une SSII et qui subissent les contraintes de timing, de controle sur leur job et d'obligation de résultat. Ces derniers, je les plains.

Je te rejoins à 200% sur cette analyse…

Elzen · Le 02/04/2012, à 00:52

En ce qui me concerne, je dirais qu'une bonne phase papier… ça se fait sur papier, justement. Ou avec un tableau, pour certains trucs c'est encore mieux, surtout quand on fait ça à plusieurs. Utiliser des logiciels pour ça, je n'pense pas que ça laisse les mêmes libertés.

D'une manière général, on dit que « plus on commence à coder tôt, plus on finit de coder tard ». La phase de préconception est essentielle et permet de beaucoup faciliter la suite. Un autre truc très important est la spécification : commencer, avant de coder, par créer un squelette vide (en-têtes de fonctions pour les langages impératifs, interfaces pour les langages objets, par exemple) accompagnés de commentaires précis détaillant ce qu'il faut en entrée, ce qu'on obtient en sortie, et le cas échéant, ce que fera un état ou une donnée incorrecte. Ça aide beaucoup à savoir où on va, et ça permet de gagner du temps quand on travaille en équipe, puisqu'on peut comme ça commencer à travailler sur quelque chose sans attendre que les autres aient fini.

Un truc qu'il serait bien qu'ils apprennent aussi, c'est qu'il existe tout un tas de langages et de types de programmations différents (C, C++, Java, Python, PHP, Lisp etc.) et que chacun a ses avantages et ses inconvénients. Il n'y en a pas un qui soit la solution unique à tous les problèmes. Alors ils ne vont peut-être pas en voir plusieurs dès l'année de terminale, mais il serait plutôt bon pour eux d'avoir en tête que le choix du langage se fait aussi pendant la phase de préconception, et qu'il vaut généralement mieux en connaître plus ou moins plusieurs que d'être hyper-spécialisé dans un seul.

Hibou57 · Le 02/04/2012, à 00:59

ArkSeth a écrit :

En ce qui me concerne, je dirais qu'une bonne phase papier… ça se fait sur papier, justement. Ou avec un tableau, pour certains trucs c'est encore mieux, surtout quand on fait ça à plusieurs. Utiliser des logiciels pour ça, je n'pense pas que ça laisse les mêmes libertés.

Mais il n’y alors pas de contrôle automatique (et donc digne de confiance) possible. C’est pour cette raison que la tendance et dans l’assistance informatique pour les tâches de modélisation.

HP · Le 02/04/2012, à 05:51

Hibou57 a écrit :

ArkSeth a écrit :
En ce qui me concerne, je dirais qu'une bonne phase papier… ça se fait sur papier, justement. […] Utiliser des logiciels pour ça, je n'pense pas que ça laisse les mêmes libertés.
Mais il n’y alors pas de contrôle automatique (et donc digne de confiance) possible. C’est pour cette raison que la tendance et dans l’assistance informatique pour les tâches de modélisation.

Mouarf…

Mathieu147 · Le 02/04/2012, à 10:36

Je suis d'accord sur ce que vous avez dit sur la phase d'analyse sur papier. J'ai un master en informatique, et si je devais retenir une seule chose de ces années, c'est que si tu commences en te mettant la pression et que tu pars n'importe comment, tu fonces droit dans le mur. Par contre, si tu «perds» ton temps à schématiser sur papier, tu vas récupérer ce temps perdu au centuple.

Ce principe est tout le temps valable: si tu dois écrire une fonction/méthode/classe/etc et que tu dis «bon allez je me pète pas le cul je fais ça vite fait à l'arrache», tu te rendras compte après que, non, ça ne va pas. Il te manquera des fonctionnalités que tu ne sauras pas ajouter facilement vu l'architecture non réfléchie que tu as utilisée, ou bien les performances seront désastreuses, etc.

C'est un peu comme les cours d'algorithmique que j'ai suivis: j'ai «perdu» mon temps avec des trucs super théoriques, mais quand j'ai besoin de trier des données, je me dis «ben c'facile, j'fais un bubble sort parce que j'ai pas besoin de performances extraordinaires mais je veux que mon code reste simple» ou bien «je veux que mon tri carbure, je vais me taper le heap-sort». Je connais les algos (bon, je dois relire la page de Wikipédia pour les détails, mais au moins je sais où chercher et lequel utiliser) et je gagne plein de temps.

Je pense d'ailleurs que les cours d'algorithmique sont intéressants, non seulement pour quelques algorithmes à connaître (tri et recherche, parcours d'arbres, pile/files/deques, etc.), mais aussi pour deux choses. Premièrement on apprend le vocabulaire indispensable pour décrire un programme (boucle, gardien, fonction, variable, etc.), et deuxièmement, je trouve que c'est le cours qui est le plus représentatif de la logique générale à avoir pour programmer.

Je trouve que si on est fort en algorithmique et qu'on aime bien, c'est qu'on a l'esprit tourné pour programmer. Si on trouve ça chiant et qu'on ne s'en sort pas, alors il vaut mieux se réorienter.

Et aussi, il faut leur apprendre à tout le temps regarder la doc. C'est pas toujours bien vu dans un forum de dire RTFM, mais pour un prof d'informatique, je pense que c'est important. Je suis tout le temps dans la doc de PHP ou bien sur le MDN pour Javascript, et même des bêtes questions de syntaxe en HTML ou CSS. On ne saurait pas retenir tous les détails, l'ordre des paramètres d'une fonction, etc. Il faut tout le temps regarder la doc.

Et là, tu en profites pour dire à tes élèves l'importance d'écrire correctement les spécifications des fonctions.

D'ailleurs, j'avais un cours de programmation fonctionnelle, où on devait programmer en Prolog. L'examen oral consistait à écrire des fonctions et à décrire ce qu'elles faisaient. Si on se trompait et que la fonction ne fonctionnait pas, on perdait bien sûr des points, mais si on se trompait dans la doc, on ratait l'examen. En fait le prof demandait qu'on soit plus attentif à décrire ce qu'il faut faire, plutôt qu'à le faire réellement. Je trouve ça judicieux. Parce que quand tu dois écrire le code en vrai, si ça marche pas suivant tes spécifications, tu t'en rendras vite compte. Mais si tes analyses de départ sont mauvaises, alors tu pars sur une mauvaise base pour tout ton projet.

Hibou57 · Le 02/04/2012, à 16:58

HP a écrit :

Mouarf…

Mais encore ?

Kris73 · Le 02/04/2012, à 21:11

Merci Mathieu, voila qui me donne quelques arguments pour présenter l'algo aux élèves, j'appréhende un peu leur réaction

Mathieu147 a écrit :

Je trouve que si on est fort en algorithmique et qu'on aime bien, c'est qu'on a l'esprit tourné pour programmer. Si on trouve ça chiant et qu'on ne s'en sort pas, alors il vaut mieux se réorienter.

Voila une phrase qui risque de me faire de l'usage Je te remercie !!

HP · Le 02/04/2012, à 21:52

Kris73 a écrit :

Le souci est que les gens comme moi, qui vont enseigner cette spécialité en venant d'horizons assez variés ( mathématiques, physique, SI,...) et qui ont une vision assez "théorique" de l'informatique, ont du mal à se représenter quel est exactement le processus suivi par un développeur seul ou au sein d'une équipe concevant un logiciel.

C'est dommage… bon, bien… si tu n'es pas développeur, ça risque d'être (très, très) dur de leur faire passer l'étincelle. Vaut mieux que tu leur balances de grands phrases copiées-collées, à l'emporte-pièce, en travers de la tronche, pour les briser, c'est mieux… genre :

Kris73 a écrit :

Mathieu147 a écrit :
Je trouve que si on est fort en algorithmique et qu'on aime bien, c'est qu'on a l'esprit tourné pour programmer. Si on trouve ça chiant et qu'on ne s'en sort pas, alors il vaut mieux se réorienter.
Voila une phrase qui risque de me faire de l'usage Je te remercie !!

Moi je dirais, que si t'es pas développeur, tu ne devrais pas t'improviser à donner des cours dans le domaine… après, c'est à voir comment tu gères çà au niveau de ta vergogne et/ou de Maslow ; heureusement pour toi, tu risques de tomber sur des victimes bien faciles…

Dernière modification par HP (Le 02/04/2012, à 21:55)

Mathieu147 · Le 03/04/2012, à 08:52

Kris73 a écrit :

Mathieu147 a écrit :
Je trouve que si on est fort en algorithmique et qu'on aime bien, c'est qu'on a l'esprit tourné pour programmer. Si on trouve ça chiant et qu'on ne s'en sort pas, alors il vaut mieux se réorienter.
Voila une phrase qui risque de me faire de l'usage Je te remercie !!

Pas de problème!

Je trouve que, pour chaque type d'études, il faut avoir l'esprit tourné d'une certaine façon. Par exemple, moi qui suis informaticien, je suis absolument certain que j'aurais raté des études de droit parce que (en dehors du fait que ça m'aurait gonflé) je n'ai pas l'esprit tourné de la bonne façon. Enfin, il me semble.

D'ailleurs ma femme me prend pour un zinzin quand je lui dis que c'est une déformation professionnelle de chercher un algorithme de placement optimal des habits sur le fil à linge. Mais je pense sérieusement que c'en est une.

Quand on commence des études, on se rend compte si on a l'esprit correspondant, mais c'est trop tard si ce n'est pas le cas, on a perdu un an parce qu'on a déjà entamé une année d'études. Du coup, je trouve ça bien qu'il y ait des cours d'informatique dans l'enseignement secondaire.

J'ai entendu parler une fois (sur internet mais je ne sais plus du tout où) d'un cours de sécurité donné dans une faculté d'informatique, qui, au lieu d'expliquer le chiffrement, les clés, les fonctions de hashage et ce genre de choses, enseignait comment avoir l'esprit tourné pour créer des logiciels sécurisés. Pendant l'année, les étudiants devaient trouver des moyens de «pirater» des choses non informatiques.

Par exemple, ils devaient trouver un moyen d'entrer dans la chambre d'un autre étudiant en contournant le système de sécurité des cités universitaires. Genre aller à l'accueil et dire qu'on a perdu sa clé et se faire passer pour un autre, évidemment pas se pointer avec une arme à feu et menacer tout le monde.

Au final, ce genre de cours apprend à trouver les failles dans un système, à se mettre à la place de l'attaquant et à pouvoir anticiper ce qu'il pourrait faire. Je regrette de ne pas avoir eu ce genre de cours, j'ai plutôt eu des cours trop théoriques.

Je me rends compte que je suis un peu hors sujet

D'après ce que tu dis, je pense que ta plus grande crainte, c'est que, bien que tu connaisses de manière théorique un peu de programmation et d'algorithmique, tu ne sais pas, en pratique, comment un développeur développe. C'est bien ça?

En fait je pense qu'il y a énormément de façons de faire, chacun fait comme il a envie. La tendance qui a l'air de ressortir de ce topic (et avec laquelle je suis d'accord), c'est que: La phase d'analyse est importante; mais on a pas toujours le temps de la faire; et les outils ne sont pas suffisamment développés.

En fait je pense que, niveau outils, si il y en a des chouettes, mais ils ne sont pas nécessairement accessibles au «commun des développeurs». J'ai eu un cours où on a parlé d'UML et de toute cette phase de réflexion, mais ce que j'en ressors, c'est que tu peux t'amuser à faire des petits schémas mais au final, chacun fait un peu comme il a envie et ça peut prendre plein de temps de décrire tout ton programme. Autant ça peut être intéressant de schématiser une partie complexe pour que quelqu'un d'autre la comprenne, autant schématiser le fonctionnement de l'ensemble de ton programme ça va te prendre plus de temps que de le programmer.

Mais le prof qui donnait le cours mettait au point des outils (informatiques et mathématiques) (que je n'ai jamais vus) permettant de prouver qu'un programme fonctionne exactement selon des spécifications exactes et qu'il n'a pas de bug. Il a dit que lui et son équipe avaient déjà rapporté des bugs de GCC. Mais là où je dis que ce n'est pas accessible au commun des développeurs, c'est que, d'après lui, ils avaient utilisé ces outils pour prouver le fonctionnement d'un logiciel de commande de pilotage d'un avion (Airbus je crois me rappeler). Mais c'était uniquement le petit bout de code qui commandait réellement les parties mobiles de la carlingue (désolé je ne suis pas très calé en vocabulaire aéronautique), soit quelques centaines ou milliers de lignes à tout casser, et il avait fallu plus d'un an à plusieurs personnes.

Donc, les outils super poussés d'analyse c'est chouette pour les chercheurs universitaires, les thèses de doctorat, ou les parties ultra sensibles genre le logiciel d'un avion, de l'ABS d'une voiture ou les trucs qu'on trouve dans les fusées. Mais pour le développeur moyen, tu fais sur base de ton expérience, de ton savoir, d'un petit schéma sur papier, et du résultat de tes tests. Il y a bien des outils comme les débuggeurs ou Valgrind pour les fuites de mémoire, mais c'est plus après coup pour comprendre pourquoi ça ne marche pas, plutôt que d'éviter dès le départ que ça ne marche pas.

C'est quoi exactement le programme de ton cours? Donner envie aux élèves d'entreprendre des études d'informatique? De leur apprendre spécifiquement la programmation? Parce que l'informatique, ce n'est pas uniquement programmer.

Si ton but c'est de les faire aimer ça, alors, j'espère que toi-même tu aimes ça. Je comprends par exemple que l'algorithmique ça puisse être rébarbatif, mais moi j'ai trouvé ça génial, sans doute en partie parce que j'avais un prof qui expliquait super bien et qui était passionné. Sur ce point de vue, je rejoins HP.

BFB · Le 03/04/2012, à 13:07

Kris73 a écrit :

Mathieu147 a écrit :
Je trouve que si on est fort en algorithmique et qu'on aime bien, c'est qu'on a l'esprit tourné pour programmer. Si on trouve ça chiant et qu'on ne s'en sort pas, alors il vaut mieux se réorienter.
Voila une phrase qui risque de me faire de l'usage Je te remercie !!

Voilà une phrase qui m'aurait malheureusement raccourcis mes études de 5 ans si je l'avais cru. Il n'y a pas plus de bosse de l'informatique qu'il n'y a de bosse des maths.
C'est une matière qu'on prends à son début, donc avec presque aucun prérequis. Deplus même au niveau master, on s'en sort bien avec un niveau d'analyse (maths) pur entre "bac S option maths" et "bac+1".

J'ai une autre proposition. A la fac vous reprendrez l'algorithmique et l'info en général depuis le début. Ce que vous avez vu sera donc réexpliqué plusieurs fois et par plusieurs personnes différentes.
C'est un secteur ou beaucoup de gens se sont formés en autodidacte, avec des livres et des sites. Il y a donc beaucoup de ressources a disposition pour ceux qui sont en difficultés comme pour ceux qui voudraient approfondir.

Mathieu147 n'as pas tort sur la question du plaisir, si on y prends du plaisir, alors envisageons cette voie, on est sur que le plaisir reviendra. En revanche pour les autres, peut-être qu'un autre prof saura donner l'étincelle.

Pylades · Le 03/04/2012, à 14:38

Kris73 a écrit :

Mais je n'évoquais pas le problème de compréhension par les élèves, mais bien le moyen de leur donner une vision juste d'un domaine professionnel, car ils l'idéalisent beaucoup ( "je vais programmer des jeux", "je vais hacker" )...

Bah, en étant orienté, on peut coder un jeu d’échecs en une dizaine d’heures… Moins, si l’on est doué ou expérimenté.

ArkSeth a écrit :

Un truc qu'il serait bien qu'ils apprennent aussi, c'est qu'il existe tout un tas de langages et de types de programmations différents (C, C++, Java, Python, PHP, Lisp etc.) et que chacun a ses avantages et ses inconvénients.

Il y a même des langages dont l’unique avantage est le mod_php d’Apache. trollface

Voilà, c’était ma contribution pertinente.

Kris73 · Le 03/04/2012, à 19:42

Mathieu147 a écrit :

D'après ce que tu dis, je pense que ta plus grande crainte, c'est que, bien que tu connaisses de manière théorique un peu de programmation et d'algorithmique, tu ne sais pas, en pratique, comment un développeur développe. C'est bien ça?

C'est tout à fait ça !

Mathieu147 a écrit :

C'est quoi exactement le programme de ton cours? Donner envie aux élèves d'entreprendre des études d'informatique? De leur apprendre spécifiquement la programmation? Parce que l'informatique, ce n'est pas uniquement programmer.

Je te renvoie vers le site de l'Onisep qui présente cette nouvelle spécialité :

http://www.onisep.fr/Toute-l-actualite- … ntree-2012

C'est assez ambitieux, l'objectif ultime, c'est de faire des "créateurs" à partir de simples "consommateurs"

Chris

Kris73 · Le 03/04/2012, à 19:47

ArkSeth a écrit :

Un truc qu'il serait bien qu'ils apprennent aussi, c'est qu'il existe tout un tas de langages et de types de programmations différents (C, C++, Java, Python, PHP, Lisp etc.) et que chacun a ses avantages et ses inconvénients.

Tout à fait, le problème c'est l'horaire réduit de la spécialité ( 2h par semaine )...on va être obligé de faire des choix et de ne qu'évoquer les multiples langages...
On réfléchit à celui que l'on utilisera de manière plus poussée, a priori ce sera Java; on avait aussi le choix de Python mais on a choisit le plus "généraliste" ( je sais pas si le terme est bien choisi )...vous verriez les yeux qui s'éclairent quand on leur dit qu'il pourront programmer des applis Android

Chris

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 30/03/2012, à 21:44

Témoignages sur vos pratiques de dévelopeur...

#2 Le 30/03/2012, à 22:05

Re : Témoignages sur vos pratiques de dévelopeur...

#3 Le 30/03/2012, à 22:18

Re : Témoignages sur vos pratiques de dévelopeur...

#4 Le 30/03/2012, à 22:40

Re : Témoignages sur vos pratiques de dévelopeur...

#5 Le 31/03/2012, à 10:53

Re : Témoignages sur vos pratiques de dévelopeur...

#6 Le 31/03/2012, à 11:27

Re : Témoignages sur vos pratiques de dévelopeur...

#7 Le 31/03/2012, à 12:08

Re : Témoignages sur vos pratiques de dévelopeur...

#8 Le 31/03/2012, à 19:01

Re : Témoignages sur vos pratiques de dévelopeur...

#9 Le 31/03/2012, à 19:25

Re : Témoignages sur vos pratiques de dévelopeur...

#10 Le 31/03/2012, à 19:47

Re : Témoignages sur vos pratiques de dévelopeur...

#11 Le 01/04/2012, à 20:34

Re : Témoignages sur vos pratiques de dévelopeur...

#12 Le 01/04/2012, à 22:38

Re : Témoignages sur vos pratiques de dévelopeur...

#13 Le 01/04/2012, à 23:55

Re : Témoignages sur vos pratiques de dévelopeur...

#14 Le 02/04/2012, à 00:52

Re : Témoignages sur vos pratiques de dévelopeur...

#15 Le 02/04/2012, à 00:59

Re : Témoignages sur vos pratiques de dévelopeur...

#16 Le 02/04/2012, à 05:51

Re : Témoignages sur vos pratiques de dévelopeur...

#17 Le 02/04/2012, à 10:36

Re : Témoignages sur vos pratiques de dévelopeur...

#18 Le 02/04/2012, à 16:58

Re : Témoignages sur vos pratiques de dévelopeur...

#19 Le 02/04/2012, à 21:11

Re : Témoignages sur vos pratiques de dévelopeur...

#20 Le 02/04/2012, à 21:52

Re : Témoignages sur vos pratiques de dévelopeur...

#21 Le 03/04/2012, à 08:52

Re : Témoignages sur vos pratiques de dévelopeur...

#22 Le 03/04/2012, à 13:07

Re : Témoignages sur vos pratiques de dévelopeur...

#23 Le 03/04/2012, à 14:38

Re : Témoignages sur vos pratiques de dévelopeur...

#24 Le 03/04/2012, à 19:42

Re : Témoignages sur vos pratiques de dévelopeur...

#25 Le 03/04/2012, à 19:47

Re : Témoignages sur vos pratiques de dévelopeur...

Pied de page des forums