Discussion :

[Patrick Ruiz]

Quelles sont les choses qu’on devrait enseigner aux développeurs à l’université ?
L’auteur de la plateforme Binaris passe en revue une liste non exhaustive d’aspects

De façon traditionnelle, l’exercice en tant que professionnel de l’informatique en général est conditionné par le passage du postulant par une formation qui mène à un diplôme dans le domaine. La France est un bel exemple de ces pays où l’accès à bon nombre de postes de développeur informatique nécessite de présenter au futur employeur un parchemin qui correspond à 4 années d’études supérieures à minima (bac+4, bac+5, doctorat, etc.).

L’obtention d’un emploi nécessite de faire valoir le diplôme adéquat ou du moins celui que le futur employeur mentionne sur l’offre. De façon générale, le cursus universitaire apparaît donc comme une sorte de préparation aux défis qui attendent le postulant sur le terrain. Seulement, l’auteur de la plateforme serverless Binaris lui attribue un certain nombre de tares dont la propension à pencher sur la théorie plutôt que sur des aspects susceptibles de faire de ses produits d’excellents praticiens.

« Voici quelques-unes des choses que j’aimerais que l’on enseigne à l’université plutôt que de s’appesantir sur de la théorie pure » :

1. Éviter de baser ses décisions sur le nombre de lignes de code

Le nombre de lignes de code est l’une des métriques autour desquelles les discussions d’équipes de développement en informatique tournent souvent. Pour un projet donné, il peut être question de savoir s’il est mieux d’avoir une grosse ou une petite base de code (en termes de nombre de lignes de code). Le développement de l’auteur de la plateforme Binaris laisse filtrer que ce type de questionnement est quasi inutile lorsqu’il souligne que « le faire serait similaire à évaluer la qualité d’un livre sur la base du nombre de lignes de code. »

De façon brossée, il précise qu’il n’est pas nécessaire de compter, mais d’écrire autant de lignes de code que nécessaire tout en restant cohérent avec quelques principes : le code est cohérent ; le code est autodescriptif ; le code est bien documenté ; le code s’appuie sur des fonctionnalités modernes et stables ; le code n’est pas inutilement complexe, etc.

2. Il n’y a pas de « bons » et de « mauvais » langages de programmation

Dans un parallèle qu’il établit avec une boîte à outils, il montre que chaque langage de programmation introduit un jeu de compromis avec lequel chaque développeur doit traiter. En d’autres termes, il n’y a pas de
« bons » et de « mauvais » langages de programmation. Il y aurait simplement un choix à effectuer et même s’il souligne qu’il y a, dans la plupart des cas, peu de situations pour lesquelles le choix du langage est une question cruciale, il dresse une liste de points à prendre en compte pour l’atteinte de cet objectif : la disponibilité des ressources en ligne ; la rapidité de développement ; la tendance à générer des bogues ; la qualité et l’étendue de l’écosystème de bibliothèques ; les performances, etc.

« Il y a aussi un type d’association que les tendances actuelles suggèrent fortement. Si vous travaillez dans le domaine de la science des données, il serait réaliste d'utiliser Python, R ou Scala (peut-être Java). Si c'est un projet pour passer du temps, utilisez le langage qui vous rendra le plus heureux. Il n'y a qu'une seule règle non négociable sur laquelle je m'appuie. Je refuse d'utiliser des langages qui n'ont pas la plupart des problèmes que je vais rencontrer directement résolus sur StackOverflow. Ce n'est pas que je ne peux pas le résoudre, c'est juste que ce n'est pas la peine d'y consacrer du temps », ajoute-t-il

3. Lire le code d’autres développeurs est une activité difficile

« Lire le code des autres donne presque l'impression de lire une langue étrangère. Même si vous êtes à l'aise avec le choix du langage de programmation de l'auteur, vous devez quand même vous adapter à différents styles et choix d'architecture. Cela suppose également que l'auteur a écrit un code cohérent et fiable - une cible qui peut être atteinte ou manquée », écrit-il laissant ainsi filtrer que la lecture du code d’autres développeurs n’est pas une activité aisée. Pourtant, c’est une activité qui meuble une bonne partie du quotidien du développeur qui travaille au sein d’une équipe. Il faut arriver à maîtriser cet exercice et le développeur de la plateforme Binaris suggère de faire de la revue de code sur des plateformes comme GitHub pour aiguiser cette aptitude.

« La seconde astuce qui peut vous aider à lire le code d'autres personnes est un peu plus unique. C'est une technique que j'ai mise au point et elle a vraiment réduit le temps qu'il me faut pour me sentir à l'aise avec du code d'autres développeurs. Après avoir regardé le style du code que je veux lire, je commence par ouvrir vi et à écrire du code dans le style utilisé par le projet. Lorsque vous écrivez du code dans le nouveau style, vous améliorerez également vos compétences en lecture. Le style vous semblera moins étranger, comme vous l'avez déjà expérimenté. Même lorsque je parcours un projet aléatoire sur Github, je m'y adonne rapidement », ajoute-t-il.

4. Garder à l’esprit qu’il n’y a pas de code « parfait »

Dans son billet, l’auteur de la plateforme Binaris a aussi tenu à recadrer l’idée selon laquelle tous les programmeurs en industrie écrivent du code « parfait ». Il insiste sur ceci que même dans ces sphères où l’on a affaire à des programmeurs très expérimentés, le salut passe par les revues de code.

« Je travaille avec une équipe d'ingénieurs vraiment brillants. Ce sont quelques-uns des programmeurs les plus compétents et les plus confiants dont on puisse s'attacher les services. Chaque membre de notre équipe (y compris moi) aurait une crise de panique totale si quelqu'un suggérait de faire passer du code non révisé. Même si vous pensez être le prochain Bill Gates vous ferez des erreurs. Je ne parle même pas d'erreurs logiques, je parle de fautes de frappe, de caractères manquants. Je parle de choses pour lesquelles on a besoin d'une autre paire d'yeux », écrit-il.

5. Travailler comme développeur ne veut pas dire 8 heures de programmation par jour

Dans bien de pays au monde, la journée de travail a une durée de 8 heures. Pour un employé de bureau, on arrive au lieu de service, s’installe sur un siège devant un ordinateur et se lance dans ses activités. Mais, lesquelles ? De quoi s’agit-il dans la réalité ? De « 8 heures de travail » ou « 8 heures au travail » ? En d’autres termes, pour combien de temps les travailleurs sont-ils productifs sur une journée de travail ?

« Très peu de personnes sont capables d’écrire du code pendant plus de 4 heures par jour. Les personnes qui ne sont pas d'accord avec cette affirmation sont soit l'exception à la règle, soit travaillent dans des entreprises qui devraient mieux les traiter. La programmation est une tâche exigeante sur le plan mental. Il est tout à fait déraisonnable de s'attendre à ce que quelqu'un écrive du code 8 heures par jour, 5 jours par semaine. », répond l’auteur de la plateforme Binaris dans son billet de blog.

Un sondage d’Invitation Digital Ltd – une firme de marketing basée au Royaume-Uni – paru en début d’année met en lumière des tendances similaires : la durée moyenne de productivité sur le lieu de service est de 2 h 53 min, soit moins de 3 h.

Il s’agit d’un avis avec des points susceptibles de faire débat. Par exemple, il semble difficile d’imaginer une formation de niveau universitaire au cours de laquelle l’on n’enseigne pas aux étudiants qu’il n’y a pas de « bons » et de « mauvais » langages de programmation ou encore que lire le code d'autres intervenants dans la filière n'est pas une activité aisée. Cela reste néanmoins une contribution aux questionnements liés aux habitudes que les travailleurs de la filière programmation informatique doivent avoir.

Source : billet de blog

Et vous ?

Les aspects que soulèvent l’auteur de la plateforme Binaris font-ils vraiment défaut aux cursus de formations universitaires en informatique ?

Êtes-vous issu d’une formation universitaire en informatique ? Si oui, lui reconnaissez-vous ces tares ?

Quels sont d’après vous les choses que l’on devrait enseigner aux développeurs à l’université ?

Voir aussi :

Qu'est-ce qui fait un bon programmeur ? Un senior liste cinq caractéristiques d'un bon programmeur

Faut-il éliminer le mythe du programmeur génie ? Selon un sénior, « la plupart des gens sont moyens » et cela n'est pas grave

Le talent et la passion suffisent-ils pour faire un bon développeur ? Les créateurs de Django, PHP et Rails n'étaient pas des passionnés du code

Tout le monde ne peut pas devenir développeur, il faut d'abord disposer de certains prérequis

[Angelsafrania]

Les tests automatisés !
Apprendre les différents types de tests automatisés existant, apprendre à en écrire des pertinents.

[pboulanger]

Des cours d'algorithmes, on retrouve beaucoup trop de 'développeurs' ne sachant pas choisir la structure de données adaptées à son problème ou l'algorithme adapté... Comprendre la différence en une std::map et un std::unordered_map par exemple en terme de performance mais aussi en consommation mémoire... etc...

On retrouve de plus en plus de développeurs très fort en coding game mais incapable de s'adapter à un problème qu'ils n'ont pas étudié précédemment. Je me souviens d'un collègue; qui pour un parcours d'une structure de données arborescente, avait implémenter 3 boucles for imbriquées (le concept de la récursivité lui était étranger....

L'apprentissage d'un langage pure fonctionnel est un plus...

[Gnomial]

Sortant tout juste d'un cursus universitaire, je me permets de donner mon point de vue.

1. Éviter de baser ses décisions sur le nombre de lignes de code

L'auteur a bien raison, on nous chambre en permanence sur le nombre de lignes de code. Je pense qu'il faut faire la balance entre performances et maintenabilité. Le problème est que la compétition innée dans les cursus de programmation est :

1 - Le premier qui finira à écrire son algorithme (donc en négligeant toutes les règles de qualité du code)
2 - Celui qui aura écrit le moins de lignes de codes (quitte à se retrouver avec des if else (habituellement écrits sur 4 lignes) rédigés sur 1 seule ligne mais incompréhensibles)

Et je pense que ces "unités de mesure" viennent principalement du fait que les algorithmes que l'on écrit en cours ne sont jamais très conséquents et tournent toujours plus ou moins rapidement et qu'il n'y a pas d'utilisateur final, à tel point que mesurer la performance paraît inutile (et implicitement la maintenabilité). Mais également du fait que aucun outil pour mesurer les performances ne sont enseignés aux élèves. Lors de ma 1ère année de Licence, nous programmions en Ada et la moitié des programmes des élèves n'étaient pas indentés. Le seul objectif était de produire un algorithme fonctionnel.
Seulement lorsque tu rentres dans la "vraie vie" d'un programmeur, tu te rends comptes que tu as un résultat à produire auprès du client et que la performance et la maintenabilité font partie des premiers critères.

3. Lire le code d’autres développeurs est une activité difficile

Quand le développeur écrit son programme, il a son propre "environnement de réflexion". Soit il a créé le code de A à Z, soit il a déjà pris connaissance du code précédent (et si ce n'est ni l'un ni l'autre, chapeau ). Il est donc implicite que la personne qui va relire le code n'aura pas la même réflexion et la même image d'ensemble du code que le développeur précédent. Un code qui peut nous paraître simple à "déchiffrer" peut paraître tout aussi compliqué à autrui. Je pense que peu importe qui écrit du code, il sera toujours difficilement intégrable à notre propre réflexion.
C'est comme décrire un endroit que tu as visité le mois dernier à Châteauroux: tu as l'image d'ensemble, tu sais à quoi ça ressemble.. mais la personne en face s'en fout cherchera à s'imaginer l'endroit et ça ne ressemblera jamais exactement à ce que tu essaies de décrire.

4. Garder à l’esprit qu’il n’y a pas de code « parfait »

J'associe toujours l'écriture du code à l'écriture d'un livre ou la création d'une oeuvre d'art... Existe t-il vraiment des critères pouvant définir ce qu'est un code parfait ? Outre les critères de performances, ce sera toujours plus ou moins subjectif. Michel adore les boucles while, alors que Jacquie préfère les boucles for avec un exit. Qui a raison ?

5. Travailler comme développeur ne veut pas dire 8 heures de programmation par jour

Et pour n'importe quel métier, honnêtement. Je pense qu'il faut simplement faire attention à notre "passion" pour la programmation et ne pas se laisser prendre au piège pour que l'on en fasse plus sous prétexte que cela nous plaît. Personnellement, j'aime la programmation, mais pas au point que ce soit ma passion (ou du moins pas ma première passion) et je pense que ça m'aide à équilibrer ma vie au travail. Mais ça ne m'empêche pas de m'appliquer (et de m'impliquer) dans mon travail.

[iclo]

Bonjour,

Les formations actuelles manquent souvent de bonnes bases algorithmiques et de méthodologies de développements et de tests.
J'en suis arrivé quand je fais passer des tests techniques lors d'un recrutement à demander un pseudo code pour trier un simple tableau de 5 nombres entiers. Les 3/4 des candidats diplômés ou sur le point de l'être sont incapables de sortir ne serait-ce qu'une base de programme.

Il serait plus judicieux d'insister pendant les études sur des bases intemporelles, et surtout à apprendre "à apprendre par soi même" que de vouloir former des gens sur des outils / framework/ technologies précises qui auront soit disparu quelques années après ou bien mutées à un point qu'il aura fallu se former pour rester compétent.

[el_slapper]

La maintenance. Les foutre sur des vieux codes pourris, avec plein de couches de maintenances différentes qui puent.... Mais qui marchent comme du papier à musique. Et leur faire faire une petite modif, comme ça, juste pour rigoler.

Sinon, l'autre truc que j’aimerais de la part des établissements de formation, c'est de ne pas diplômer les gens qui n'ont pas le niveau. Mais bon, vœu pieux.

[Jamatronic]

Bon, en général, celui qui prétend m'imposer ce que je dois enseigner, je lui fais bouffer ses lunettes et ses couilles.

Mais je plussoie à 1000% le post de el_slapper.

[iclo]

Sinon, l'autre truc que j’aimerais de la part des établissements de formation, c'est de ne pas diplômer les gens qui n'ont pas le niveau. Mais bon, vœu pieux.

Je suis en effet souvent sidérer par le niveau de certains candidats : il est tout à fait normal d'avoir encore beaucoup à apprendre (nous en sommes tous là durant l'ensemble de notre carrière) mais quand le "bootstrap" du développement n'est pas là, ça devient très compliqué.

[el_slapper]

Je suis en effet souvent sidérer par le niveau de certains candidats : il est tout à fait normal d'avoir encore beaucoup à apprendre (nous en sommes tous là durant l'ensemble de notre carrière) mais quand le "bootstrap" du développement n'est pas là, ça devient très compliqué.

J'ai dit vœu pieux, d'ailleurs, parce-que plusieurs forces concourent à cette situation :

• Le marché est demandeur de jeunes diplômés - pour peu qu'il y aie marqué "informatique" sur le diplôme
• les recruteurs sont mal armés pour détecter les gens qui ne savent pas faire un fizzbuzz
• les formations sont ambiguës : on prépare des "data scientists" ou des "ingénieurs qui passeront vite chef de projet", pas des développeurs
• la tradition veut qu'on juge les gens sur les maths plus qu'autre chose
• l'habitude du corps professoral de juger les élèves sur des exercices standard, pas sur des exercices un peu vicieux(et donc réalistes). Bon, ce n'est pas vrai pour tous, mais c'est bien répandu
• (et sans doute encore d'autres)

Donc voilà, des gens qui n'ont pas la tournure d'esprit nécessaire pour faire un code qui sortent d'un micropoil des exemples standard, on en trouve bien avec un beau diplôme, et on ne peut rien en faire. Et ils inondent les SSII, et donc, fatalement, les grands comptes. Et en plus on leur a fait croire qu'ils ne feraient que de beaux projets, là ou la réalité du terrain est nettement plus moche. J'avais un avantage immense, au final. On m'avait dit "ton boulot, ça sera probablement de récupérer un atelier avec 20/30 presses à injecter dedans, qui tourne nickel, et à arriver à faire mieux quand même. C'est moche, c'est sale, on se salit vite les mains, mais les pièces sortent propres, on ne sait pas par quel miracle, mais comme c'est de l'alimentaire, c'est nécessaire. Et tu dois améliorer la productivité. Ton budget est dérisoire. Bon courage.".

Une bien meilleure préparation(a minima psychologiquement) que d'enquiller les projets sur les mille et une manières de faire un tri de la manière la plus élégante possible. C'était bien plus réaliste, et chercher à améliorer la vitesse de changement d'un moule à injection de seau pour l'emballage(pour y mettre du yaourt ou de la peinture à numéroter les moutons, authentique), ou encore à réduire le nombre de rebuts, ressemblait sans doute plus à la maintenance d'un vieux batch COBOL qui calcule et prépare l'impression de votre montant d'assurance automobile qu'un projet informatique page blanche sur une théorie scientifique rigolote. Même si ça n'était pas de l'informatique du tout.

[SQLpro]

... Je me souviens d'un collègue; qui pour un parcours d'une structure de données arborescente, avait implémenter 3 boucles for imbriquées (le concept de la récursivité lui était étranger....

D'autant plus que tout code récursif peut être "dérécursivé" par l'usage d'une pile (théorème mathématique découvert par un mathématicien italien dans la seconde moitié du 20e siècle....). Et c'est évidemment beaucoup plus performant (en pratique, utilisé dans les bons SGBDR comme Oracle ou SQL Server pour piloter les arbres BTree des index...).

A +

[cecedu26]

La premiere chose a leur enseigner c'est ceci :

https://www.developpez.net/forums/d2...E#post11189675

[abdennour bouaicha]

a mon avis il faut enseigner si qui est demandé dans le marche ,
je connais des étudiants ingénieurs en informatique n' ont plus vue le javascript dans l’école , et lors du stage fin d’étude ils ont soufrai.

[Gunny]

J'ai appris tout ça à l'Université personnellement...
Par contre, ce que je regrette n'avoir pas appris alors qu'on s'en sert tout le temps (je suis sorti en 2010, ça a peut-être changé depuis) :
- Tests automatisés : ok, j'ai eu un seul module, ça a servi d'introduction technique, mais après, plus rien. Or le plus important et le plus difficile c'est de réfléchir à quels tests écrire, et comment les écrire.
- Contrôle de source : je n'ai simplement jamais utilisé de logiciel de contrôle de source durant mes études. C'est incroyablement important quelle que soit la taille du projet (même un tout petit projet perso).
- Travail en équipe, code review, maintenance, refactoring : cela compte pour au moins la moitié du travail d'un dev.


Je pense que se focaliser sur les technologies que "le marché" cherche est une erreur, il faut voir un niveau au dessus. Être un bon développeur c'est posséder de solides bases en programmation (algorithmique, bases de données, réseaux), mais aussi beaucoup de méta-compétences : capacité d'adaptation, rigueur, curiosité, etc. Les technologies en elles-même importent peu car elles changent tout le temps et s'apprennent vite.

[JeanYvette]

J'ai vu plusieurs commentaires parler de cours d'algorithmie, il en est en effet réellement important. Combien de fois j'ai vu des gens venir me demander de les aider sur quelque choses en pensant qu'ils avaient moins de compétences là où au final, le problème venait simplement de l'algo.
Certains veulent tuer une mouche avec un bazooka et donc se retrouvent avec des besoins beaucoup trop élevés...

Apprendre, par la même, à faire un code simplifié, qui est souvent synonyme d'un algo simple ou au moins simplifié.

Un problème majeur que je retrouve est... le copier/coller. Certains s'en sortent grâce à un petit coup de ctrl + c / ctrl + v... En effet, comme disent certains, un dév "flemmard" est un dev "astucieux (pour expliquer le principe de classes que l'on peut porter sur plein de projet). Mais parfois, il serait bon de savoir comment faire quelque chose voulue DEPUIS ZÉRO, j'ai l'impression que plus le temps passe, plus cela se perd (moi en premier) mais les bases aussi, par conséquent, peuvent se perdre...

Ensuite, et là c'est la personne qui travaillent pas mal sur les SGBD qui donne un exemple de ce qu'il croise quotidiennement, il faut arrêter de commencer l'enseignement/prise en main avec des outils de style TOAD. Je m'explique (Ceci est un exemple que l'on peut retrouver dans d'autres domaines):
"Vous voulez la liste des tables qui contiennent le mot xxx dans son nom ?"
=> "Lancez TOAD est faites une recherche dans les noms d'objets via le menu machin"
"Vous cherchez la liste des procédures qui font appel/utilisent une table spécifique ?"
=> "Lancez TOAD et cherchez dans les textes des objets via le menu truc"
Conclusion : Les gens ne connaissent pas/plus les tables systèmes et un moment ça devient gênant. Alors bien sûr qu'ne fois qu'on sait le faire en requête, que l'on sait comment ça fonctionne "derrière" utiliser un outils comme cela fait gagner du temps, mais il ne faut pas que ça soit au détriment de connaissance de bases
=> Des outils oui, pour gagner du temps oui, pour perdre nos connaissances, non !

[Invité]

Il serait plus judicieux d'insister pendant les études sur des bases intemporelles, et surtout à apprendre "à apprendre par soi même" que de vouloir former des gens sur des outils / framework/ technologies précises qui auront soit disparu quelques années après ou bien mutées à un point qu'il aura fallu se former pour rester compétent.

D'un côté, il est enseigné une technicité dans une forme pédagogique et de l'autre les étudiants ne viennent pas chercher du grain à moudre mais des recettes. Tout va bien donc, l'offre répond à la demande, sauf que cela contribue à former des Ouvriers Spécialisés et non des ingénieurs autonomes, à l’esprit ouvert, en quête de réflexion.

[Invité]

Sortant tout juste d'un cursus universitaire, je me permets de donner mon point de vue.

… Je pense que les algorithmes que l'on écrit en cours ne sont jamais très conséquents et tournent toujours plus ou moins rapidement et qu'il n'y a pas d'utilisateur final, à tel point que mesurer la performance paraît inutile (et implicitement la maintenabilité). Mais également du fait qu’ aucun outil pour mesurer les performances ne sont enseignés aux élèves. Lors de ma 1ère année de Licence, nous programmions en Ada et la moitié des programmes des élèves n'étaient pas indentés. Le seul objectif était de produire un algorithme fonctionnel.

Seulement lorsque tu rentres dans la "vraie vie" d'un programmeur, tu te rends comptes que tu as un résultat à produire auprès du client et que la performance et la maintenabilité font partie des premiers critères.

■ Forme pédagogique

C’est ce que j’ai appelé « Enseigner une technicité dans une forme pédagogique » dans mon précédent post.

Le savoir-faire ne s’enseigne pas… Sauf une fois… mais il faut dire que le formateur était en fait un professionnel indépendant qui enseignait à l’IUT pour pouvoir l’indiquer sur sa carte de visite.

C’était dans le cadre d’un DUT en formation continue dans les années 80.

Ses cours d’analyse revêtaient une forme quasi philosophique que je paraissais être le seul à comprendre. Il n’a par exemple jamais prononcé le terme « Merise ». Son discours était un régal intellectuel mais manifestement pas pour tout le monde. Certains de mes collègues, pourtant des professionnels en principe expérimentés comme moi, manifestaient leur incompréhension totale. C’est là que j’ai compris qu’ils attendaient des recettes. Ils ont gâché la chance qu’ils avaient qu’un professionnel fabuleux leur demande de réfléchir et non justement d’appliquer des recettes. Ses DST, intelligents, professionnels, demandaient de la réflexion. Ses corrections étaient de véritables psychanalyses. Il expliquait mieux que je ne l’aurais fait moi-même, mon approche intellectuelle de ses DST. Un régal pour moi mais un grand désarroi pour d’autres.

Une solution serait peut-être d’inviter des professionnels à venir partager leur savoir-faire.

Une autre solution serait peut-être d’inscrire la formation dans le cadre d’une vraie application.

■ Algorithmique

L’algorithmie n’est plus ce qu’elle était. C’est aujourd’hui un autre mot pour dire programmation. Ce que l’on dit « algorithme » n’est en fait qu’une séquence de code. Et c’est bien ce que décrit la FAQ du site :

Qu’est-ce qu’un algorithme ?

Un algorithme consiste en la spécification d'un schéma de calcul, sous forme d'une suite d'opérations élémentaires obéissant à un enchaînement déterminé.

L’organigramme que l’on nomme aujourd’hui algorigramme a disparu.

Le premier cours Introduction aux algorigrammes, Publié le 25 juin 2007, dans l’espace consacré aux Meilleurs cours pour apprendre l’algorithmique, fait référence à une symbolique… des années 60. Quel professionnel utilise cette symbolique pour formaliser visuellement sa démarche algorithmique ?

Je note toutefois que dans son avant-propos, l’auteur associe « algorithme » et « organigramme » et non « algorithme » et « programme » :

Avant toute programmation, il est recommandé d'avoir une visualisation du programme qu'on va faire. Pour cela, il faut faire un algorithme ou un organigramme. Le premier a une structure linéaire comme un programme alors que le second permet de bien mieux visualiser les différents blocs du programme, les boucles, les tests.
…/…
Les modes de programmation visuelle, qui se développent de plus en plus ressemblent plus à des algorigrammes qu'à un programme. Il est donc important de prendre connaissance dès que possible avec cette schématique.

Bon !... Je ne connais pas de mode de programmation visuelle. Je passe mon tour sur le sujet.

Tout ça pour dire que les Meilleures sources algorithmes et les Exercices corrigés pour apprendre l'algorithmique m’ennuient prodigieusement.

Vierge de tout organigramme (algorigramme), je n’y décèle aucune pédagogie. Les séquences de programmes sont spécifiques d’un langage. Il faudrait donc connaître le langage pour comprendre la démarche.

L’organigramme dispense de connaître le langage utilisé et ouvre la possibilité de programmer/tester dans le langage que l’on connaît.

Un constat :

Compréhension de l'algorithme de calcul de la factorielle

Bonsoir à tous je suis un étudiant débutant dans le domaine informatique. Je suis tombé sur un exercice en ligne sur l'algorithmique après plusieurs heures de réflexion dessus j'ai du mal à comprendre

Pourriez-vous m'expliquer ligne par ligne afin d'éclairer mes zones d'ombres svp!!

Voici l'algorithme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Var n, i, f: entiers
Début 
Écrire  "entrez un nombre :" 
Lire n
f=1 
Pour i=2 à n
f=f*i
Fin pour
Écrire "la factorielle est:" F
Fin

Ma réponse :

Visuellement ça donne ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
                     ┌─────────────────────┐
                     |        n = ?        |
              D_PROG |        f = 1        |
                     |        n :: 1       |
               n<=1  └──────────┬──────────┘  n>1
           ┌───────────────────<?>───────────────────┐
           |                              ┌──────────┴──────────┐
           |                     D_ENTIER |        i = 2        |
           |                              └──────────┬──────────┘
           |                                         ├───────────────────┐  
           |                              ┌──────────┴──────────┐        |
┌──────────┬──────────┐                   |        f = f * i    |        |  
|       MESSAGE       |          T_ENTIER |        i = i + 1    |        |  
└──────────┬──────────┘                   |        i :: n       |        |
           |                              └──────────┬──────────┘  i<=n  |  
           |                                        <?>──────────────────┘
           |                              ┌──────────┴──────────┐
           |                     F_ENTIER | « Factorielle = » f |
           |                              └──────────┬──────────┘
           └────────────────────┬────────────────────┘
                     ┌──────────┴──────────┐
              F_PROG |          Ø          |
                     └─────────────────────┘

[Invité]

3. Lire le code d’autres développeurs est une activité difficile

Quand le développeur écrit son programme, il a son propre "environnement de réflexion". Soit il a créé le code de A à Z, soit il a déjà pris connaissance du code précédent (et si ce n'est ni l'un, ni l'autre, chapeau ). Il est donc implicite que la personne qui va relire le code n'aura pas la même réflexion, ni la même image d'ensemble du code que le développeur précédent. Un code qui peut nous paraître simple à "déchiffrer" peut paraître tout aussi compliqué à autrui. Je pense que peu importe qui écrit du code, il sera toujours difficilement intégrable à notre propre réflexion.

C'est comme décrire un endroit que tu as visité le mois dernier à Châteauroux : tu as l'image d'ensemble, tu sais à quoi ça ressemble.. mais la personne en face s'en fout cherchera à s'imaginer l'endroit et ça ne ressemblera jamais exactement à ce que tu essaies de décrire.

Source : CHANGER D’ALTITUDE - Bertrand PICCARD

Ce que nous croyons être un dialogue entre deux individus, n'est en réalité que deux monologues. Le premier a lieu entre nous-même et notre imaginaire et le second entre notre interlocuteur et son propre imaginaire.

Quand on parle à quelqu’un, les mots que l’on prononce correspondent, lorsqu’ils sortent de notre bouche, à une image, une émotion ou une représentation que l’on pense être très claires et univoques dans notre esprit. Du côté de notre interlocuteur, il n’en sera pas de même. Les mots arriveront soit sur un terrain vierge, où ils devront être décodés, puis interprétés, soit sur un terrain familier, où ils seront tout de suite associés à des images, émotions ou représentations personnelles, qui peuvent se révéler différentes des nôtres. À défaut d’expérience commune, notre interlocuteur essayera de construire la situation dans son imagination, mais nous devrons rester conscients du décalage inévitable que cela engendrera.

Une idée ou un ressenti qui passe dans notre conscience sera traduit en mots (première déformation) pour être communiqué à notre vis-à-vis (deuxième déformation). Ce dernier comprendra les mots comme il peut (troisième déformation) pour les retraduire en idées ou ressentis (quatrième déformation) qui seront intégrés en fonction de son propre vécu (cinquième déformation).

Il faut bien comprendre que quelqu’un qui entend nos paroles, il les passe au filtre de ce qu’il est prêt à comprendre, qu’il essaie de les intégrer en fonction de son propre vécu pour ensuite se créer une représentation mentale de ce que l’on a voulu dire.

Des mots, des phrases ont certes été perçus mais leur sens n’a pas été identique pour l’émetteur et le récepteur. D’un côté comme de l’autre, les sources de déformations et de distorsions sont multiples et comme nous négligeons le plus souvent de nous enquérir de ce que l’autre a compris, nous vivons régulièrement dans des mondes parallèles. Ce n’est qu’en cherchant à percevoir ce que l’autre a réellement compris et en comparant les expériences personnelles de chacun face à un même sujet que l’on peut commencer à communiquer. Pas avant !

Dans notre rapport à l’autre, nous devons abandonner l’idée d’une réalité unique et comprendre la communication comme un partage d’expérience et non comme un échange d’informations.

Chacun fabrique l’autre par projection. Il s’en suit un décalage qui peut devenir abyssal. La projection peut être positive ou négative se faire par idéalisation ou par rejet. Dans les deux cas, ne pas en être conscient engendre une bonne partie de nos problèmes relationnels.

En réalité, il importe moins de savoir ce que pense, ce que dit quelqu’un que pourquoi il le pense, il le dit. Les désaccords peuvent faire peur et il est très confortable d’être d’accord, les similitudes rassurent mais ça ne sert à rien. Chacun a de bonnes raisons de dire ce qu’il dit en fonction de son vécu. On s’enrichit mutuellement au contact du vécu de l’autre. Rejeter les divergences, chacun prouvant qu’il a raison et l’autre tort, rend les relations difficiles, voire même inutiles.

Il y a trois règles pour construire une relation :

1. Parler de son ressenti…
   
   Lorsque l’on dialogue, nous n’avons pas à juger le comportement de l’autre, la règle d’or consiste à exprimer ce que l’autre provoque en nous, ce que nous ressentons vis-à-vis de son attitude.
   
   
2. Partager des expériences…
   
   On communique véritablement quand on partage des expériences personnelles, pas quand on transmet des informations.
   
   Si nous n’apprenons rien de nouveau sur l’autre ou sur nous-même dans une discussion, ou que pire encore notre seul but est de persuader l’autre qu’il a tort, nous ne communiquons pas, nous transmettons des informations qui ne peuvent que susciter le rejet de quelqu’un de différend et l’approbation de quelqu’un de similaire.
   
   Une expérience est unique ; elle appartient à celui qui en fait part et à personne d’autre, jusqu’à ce que l’interlocuteur en saisisse le caractère spécifique. Il est donc important pour faire passer notre message d’expliquer simultanément d’où provient notre avis et sur quelle expérience nous nous fondons car soit notre discours devra être décodé puis interprété, soit il sera associé à des images, des émotions ou représentations personnelles qui peuvent se révéler différentes des nôtres.
   
   Les mots, les phrases sont certes perçus mais leur sens n’est pas identique pour l’émetteur et le récepteur. La transmission de notre pensée subit plusieurs déformations :
   
   
   • Une idée ou un ressenti qui passe dans notre conscience est d’abord traduit en mots,
     
     
   • Communiqués à notre interlocuteur, ce dernier comprend, filtre les mots comme il peut et les retraduit en idées ou ressentis,
     
     
   • Il s’en crée pour finir une représentation mentale qu’il intègre en fonction de son propre vécu.
   
   À défaut d’expériences communes, nous essayons de construire la situation dans notre imagination.
   
   
3. Réaliser qu’il y a autant de réalités différentes que d’individus…
   
   Cela signifie que la plupart des conflits sont aussi vains qu’inutiles.
   
   Comme nous négligeons de nous enquérir de ce que l’autre comprend, nous vivons régulièrement dans des mondes parallèles. Il nous appartient de choisir si nous préférons résister face à des manières différentes de fonctionner ou développer la liberté de découvrir d’autres façons de penser.

CHANGER D’ALTITUDE - Quelques solutions pour mieux vivre sa vie - Bertrand PICCARD - Octobre 2014

[Mat.M]

Quels sont d’après vous les choses que l’on devrait enseigner aux développeurs à l’université ?

une des choses les plus importantes c'est d'apprendre à mener à bien un projet informatique au besoin avec des méthodes.
Sinon faire du code pour du code je n'en vois vraiment pas trop l'intérêt au final

Ce que nous croyons être un dialogue entre deux individus, n'est en réalité que deux monologues. Le premier a lieu entre nous-même et notre imaginaire et le second entre notre interlocuteur et son propre imaginaire.

tout cela ça sonne comme des cours de développement personnel faudrait pas dévier du sujet principal.

Ensuite parler de "ressenti" lorsque je compile avec Visual Studio en faisant F5 et que j'ai une exception parce qu'il y a un pointeur mal initialisé dans un code en C++ là il faudrait m'expliquer ce ressenti dont parle l'auteur...

Quand le développeur écrit son programme, il a son propre "environnement de réflexion". Soit il a créé le code de A à Z, soit il a déjà pris connaissance du code précédent

ça c'est le problème de la vision subjectivite des choses et de penser les choses de manière abstraite; j'ai soulevé ce problème dans un autre fil de discussion

[Invité]

tout cela ça sonne comme des cours de développement personnel faudrait pas dévier du sujet principal.

Ensuite parler de "ressenti" lorsque je compile avec Visual Studio en faisant F5 et que j'ai une exception parce qu'il y a un pointeur mal initialisé dans un code en C++ là il faudrait m'expliquer ce ressenti dont parle l'auteur...

Ce dont on ne peut parler il faut le taire ( Wittgenstein )

[Invité]

La modestie. Le plus drôle est d'avoir assisté à une soutenance en école d'ingénieur ou le directeur de cette école exposait le plus sérieusement du monde que les trois premiers mois étaient consacrés au dégonflage de melon. La vérité du métier est que nous n'avons que de rares occasions de briller ou d'apporter une haute contribution à la société. Et puis le travail est tellement émietté désormais que même sur les projets intéressants, on peut difficilement évaluer sa part de contribution.