Partage
  • Partager sur Facebook
  • Partager sur Twitter

Club de lecture de la communauté openclassroom

Discussions autour d'un livre sur la programmation

    2 septembre 2017 à 23:29:41

    Bonjour à toute la communauté d'OpenClassrooms.

    Tout développeur le sait : il est parfois difficile d'avancer dans ses lectures lorsque l'on cherche à apprendre de nouvelles notions, d'autant qu'il est même parfois difficile de bien choisir la ressource qui traite de ces notions. De plus, nous n'avons, pendant la lecture, que notre point de vue et celui de l'auteur (ou du moins ce que l'on en comprend) pour juger de la pertinence des informations que l'on lit.

    C'est pourquoi des membres de la communauté proposent de se réunir à intervalles réguliers pour discuter à propos d'un livre, sur le discord https://discordapp.com/invite/zcWp9sC , en vocal.

    Les objectifs sont les suivants :

    • avoir un groupe pour se motiver mutuellement à continuer la lecture ;
    • avoir des points de vue différents, d'autres habitudes, d'autres langages ;
    • produire des commentaires pertinents à propos de diverses ressources.

    Pour rester ouvert à un maximum de personnes différentes (autant d'un point de vue du langage que du niveau), le livre choisi devra :

    • parler d'un thème de l'informatique au sens large (y compris conception, gestion de projet, etc), indépendant d'un langage (même si l'illustration par un langage particulier convient) ;
    • posséder un intérêt pour des développeurs de tout niveau (le but est d'avoir matière à débattre y compris pour des débutants, pas de faire du question-réponse) ;
    • être dispo quelque part en PDF.

    Le livre en question sera choisi (par la communauté) en deux temps, d'abord diverses propositions seront faites, puis votées. Un post de forum sera préparé pour cela.

    Actuellement, nous pensons que ça serait une bonne idée de se rassembler une fois par semaine pendant 30 minutes à 1h (cela pourra bien entendu être adapté selon comment se passent les séances), pour avoir un maximum de personnes, tout en gardant un débat avec suffisamment de contenu pour que cela en vaille la peine. Un autre post de forum sera créé pour choisir le prochain créneau. Cela n'interdit pas, bien entendu, de continuer les discussions en dehors de ces créneaux.

    Comme dit précédemment, ces discussions auront lieu en vocal sur un salon du Discord d'OC. Il est possible de venir en simple spectateur (pour écouter), si l'on souhaite participer, nous demandons d'être sûr à l'avance de la qualité de son micro.

    Une séance traitera a priori d'un chapitre du livre. Pour une séance, trois intervenants seront choisis, parmi les volontaires, pour (dans l'ordre) :

    • faire un résumé des séances précédentes (s'il y a lieu),
    • présenter les thèmes et questions à aborder pendant la séance,
    • prendre des notes sur ce qui est dit pendant la discussion.

    Cela implique notamment que les questions et thèmes de discussions devraient être transmises à l'avance à la personne chargée de les présenter.

    En fin de séance, les notes prises pourraient être relues rapidement pour s'assurer que rien d'incohérent n'a été introduit. Et elles serviraient pour préparer le résumé lors de la séance suivante et produire le résumé global du livre qui sera accessible par la suite sur le post de forum correspondant à ce livre.

    Si un chapitre semble trop long pour une séance, il pourrait être coupé en deux à l'avance. De la même manière, si l'on s'aperçoit qu'à la fin d'une séance, il y a encore matière à débattre, le chapitre suivant pourrait être décalé d'une semaine.

    Voilà, si vous êtes intéressés, surveillez bien les forums en attente de la première annonce de livre. Tout cela a déjà été bien discuté sur le discord (channel #club-de-lecture) mais les modifications du format ne sont bien entendu pas fermées à la discussion.

    Au plaisir !

    -
    Edité par gbdivers 5 mai 2018 à 19:51:18

    • Partager sur Facebook
    • Partager sur Twitter

    Rejoignez le discord NaN pour discuter programmation.

      16 septembre 2017 à 0:12:10

      Bonjour,

      L'étape suivante pour le club de lecture est de choisir un livre. Ce livre va être choisi par la communauté, en respectant les contraintes indiquées lors de l'annonce.

      Pour cela, je vous invite à proposer des livres dans cette discussion ou sur le discord de la communauté : https://discordapp.com/invite/zcWp9sC (dans le canal `club-de-lecture`).

      Dans une semaine, un vote sera lancée et vous pourrez choisir le livre que vous souhaitez.

      De plus, il faut choisir la date et heure de la semaine pour le club de lecture. Le vote pour cela se passe à l'adresse suivante : https://framadate.org/9PazGmJzs4uSSXXK 

      Merci.

      -
      Edité par gbdivers 5 mai 2018 à 19:50:22

      • Partager sur Facebook
      • Partager sur Twitter

      Rejoignez le discord NaN pour discuter programmation.

        22 septembre 2017 à 18:18:10

        Bonjour a tous

        Pour le moment, peu de propositions de livres ont été fait. Pour éviter de prendre trop de temps sur le choix du livre, celui qui avait été proposé sur le Discord : Coder proprement, de Robert C. Martin. Pour ceux qui n'ont pas ce livre, n’hésitez pas a demander sur le Discord si quelqu'un a le PDF du livre.

        Pour l'heure du club de lecture, pour le moment, le sondage penche pour 19h-20h, en début de semaine. N’hésitez pas a donner votre avis sur le sondage. Celui-ci sera ouvert jusqu’à la fin du mois.

        Merci

        • Partager sur Facebook
        • Partager sur Twitter

        Rejoignez le discord NaN pour discuter programmation.

          3 octobre 2017 à 17:33:54

          Bonjour a tous

          Dernière ligne droite. Les votes sont clos, le rendez-vous hebdomadaire pour le club de lecture sera tous les lundi, de 20 heure a 21 heure. Le livre sera "Coder proprement", de Robert C. Martin.

          Pour ceux qui veulent discuter en vocal avant de commencer le club de lecture, en particulier pour tester vos micros, rendez-vous lundi prochain a 20h, sur le discord.

          Le club de lecture commencera la semaine suivante (le lundi 16 a 20h), par la discussion sur le premier chapitre.

          • Partager sur Facebook
          • Partager sur Twitter

          Rejoignez le discord NaN pour discuter programmation.

            9 octobre 2017 à 20:06:18

            Bonsoir a tous. 
            Si vous souhaitez tester vos micros, discuter du club de lecture ou simplement dire bonjour, on est connecté sur le vocal du discord ce soir jusqu'à 21h.
            • Partager sur Facebook
            • Partager sur Twitter

            Rejoignez le discord NaN pour discuter programmation.

              16 octobre 2017 à 18:35:31

              Bonjour a tous

              Petit rappel, la première séance du club de lecture à lieu ce soir à 20h (heure française), sur le discord https://discordapp.com/invite/zcWp9sC. Nous discuterons du premier chapitre, "Code propre", du livre "Coder proprement", de Robert C. Martin.

              À ce soir.

              -
              Edité par gbdivers 5 mai 2018 à 19:50:36

              • Partager sur Facebook
              • Partager sur Twitter

              Rejoignez le discord NaN pour discuter programmation.

                20 octobre 2017 à 13:12:02

                Le club de lecture sera exceptionnellement repoussé au Lundi 30 Octobre, beaucoup trop d'absents à prévoir pour ce Lundi. On reste cependant sur le chapitre 2.

                • Partager sur Facebook
                • Partager sur Twitter

                Rejoignez le discord NaN pour discuter programmation.

                  6 novembre 2017 à 16:59:05

                  Bonjour a tous

                  N'oubliez pas qu'il y a une séance ce soir, a 20h, sur le discord https://discordapp.com/invite/zcWp9sC pour parler du troisième chapitre.

                  Et voici le résumé de la séance de la semaine dernière, sur le chapitre 2 "Noms significatifs". Merci a Ksass`Peuk pour ce résumé.

                  Chapitre 2

                  Le but de ce chapitre est d'établir un certain nombre de règles simples pour avoir un bon nommage des différents éléments d'un programme (variables, fonctions, classes, etc).

                  Les différents points abordés par ce chapitre sont :

                  • noms révélateurs d'intentions
                  • éviter la désinformation
                  • faire des distinctions significatives
                  • choisir des noms prononçables
                  • choisir des noms compatibles avec une recherche
                  • éviter la codification
                  • éviter les associations mentales.
                  • noms des méthodes
                  • noms des classes
                  • ne pas faire le malin
                  • choisir un mot par concept
                  • éviter les jeux de mots
                  • choisir des noms dans le domaine de la solution
                  • choisir des noms dans le domaine du problème.
                  • ajouter un contexte significatif
                  • ne pas ajouter de contexte inutile

                  Noms révélateurs d'intentions

                  Un bon nom doit exprimer, pour l'élément qu'il nomme :

                  • la raison de son existence,
                  • son rôle,
                  • son utilisation.

                  Typiquement, s'il y a besoin d'un commentaire pour expliquer cela, le nom est mauvais. Non seulement il est important de trouver un bon nom mais il faut être prêt à changer quand on en trouve un meilleur.

                  Une nouvelle fois le point crucial est de révéler les intentions du code. Le problème n'est généralement pas dans la trop importante simplicité du code mais plutôt dans la quantité d'informations implicites qu'il renferme, cela implique du lecteur la connaissance d'informations qui ne sont pas expliquées par le code.

                  Exemples typiques :

                  • signification de valeur numériques en dur dans le code,
                  • signification d'un indice pour un tableau,
                  • manière particulière d'utiliser une variable ou une fonction.

                  Éviter la désinformation

                  Le nom ne doit pas risquer de détourner le sens du code. Mieux vaut éviter, par exemple d'utiliser un mot comme "liste" dans un nom si on ne désigne pas précisément une liste (qui a un sens particulier en programmation).

                  Il faut également faire attention à ne pas utiliser des noms trop proches qui peuvent induire en erreur car l'on ne remarque pas immédiatement les différences qui peuvent apparaître.

                  Un bon nom implique que l'on n'a pas la nécessité d'aller voir les commentaires avant d'auto-compléter un nom (et pas le besoin d'aller voir une liste de fonctionnalités proposées par exemple).

                  Caractères prise de tête si mal utilisés:

                  • "o" majuscule (facilement confondu avec zéro)
                  • "L" minuscule (facilement condondu avec un)

                  Faire des distinctions significatives

                  Modifier un nom pour le compilateur, c'est aller aux devants de problèmes. Exemple typique : renommage d'une variable "qui a le même sens" qu'une autre pour éviter le conflit de nom. Si les variables ne sont pas les mêmes, elles n'ont nécessairement pas le même sens.

                  Mauvaises pratiques :

                  • introduction de faute volontaire dans un mot pour le différencier,
                  • utilisation de numéros,
                  • utilisation de mots parasites.

                  Généralement, on ne provoquera pas de désinformation mais au minimum, on n'exprime pas clairement les intentions du code.

                  Le mots comme "info" ou "data" ne sont pas précis. Difficulté par exemple de différencier correctement "MachinData" et "Machin", rendant difficile le fait de savoir laquelle des deux on doit utiliser pour obtenir une information particulière quand on utilise l'une ou l'autre.

                  Conseil : ne jamais mettre le mot variable dans le nom d'une variable, ou array dans un tableau, ou string dans une chaîne, etc.

                  Choisir des noms prononçables

                  Besoin dû principalement au fait que notre cerveau est câblé pour mieux manipuler des choses prononçable. Cela permet entre autre d'avoir une conversation intelligible avec une autre personne.

                  Choisir des noms compatibles avec une recherche

                  Éviter par exemple les noms d'une seule lettre et ou les constantes numérique, qui sont difficiles à rechercher dans un texte. Par ailleurs l'inversion de chiffres dans une grande constante peut rendre cette constante impossible à détecter.

                  La longueur d'un nom doit correspondre à la taille de sa portée.

                  Plus le nom est susceptible d'être recherché à plusieurs endroit, plus il doit être facile à rechercher.

                  Éviter la codification

                  La codification doit être apprise, ce qui est une charge de travail inacceptable quand on doit déjà se taper l'apprentissage de la base de code sur laquelle on arrive. D'autant que les noms codifiés sont souvent imprononçables et sujets aux erreurs de saisies.

                  Notation hongroise

                  Importante dans l'API C Windows, créée à un moment où la vérification de type était pour ainsi dire inexistante, et que l'on avait besoin d'un mécanisme explicite dans le nommage pour mémoriser les types.

                  Ce n'est plus le cas aujourd'hui, la plupart des langages étant fortement typés ou inversement, certains langages rendant la distinction de type généralement inutile.

                  Bref : la notation hongroise, aujourd'hui, ne sert plus à rien.

                  Préfixe des membres

                  Préfixage "m_" pour les membres inutile : les classes et fonctions doivent être assez courtes pour qu'une telle disctinction soit inutile. Ce préfixe représenterait alors un foullis inutile.

                  Interfaces et implémentations

                  Mieux vaut éviter de commencer une interface avec "I". Au choix, il est plus pertinent de signaler une implémentation (par un suffixe "Imp" par exemple).

                  Eviter les associations mentales.

                  C'est le problème des noms qui sont insuffisamment explicites au sens où le développeur doit faire lui même un effort pour réassocier le nom à un autre nom plus explicite correspondant au concept réel.

                  Exemple : initiales de plusieurs mots que le développeur doit lui même réassocier à ces mots pour finalement atteindre le concept.

                  Noms des classes

                  Nommer les classes par des groupe nominaux (pas de verbe).

                  Éviter les mots trop généraux comme : Manager, Processor, Data, Info, etc.

                  Noms des méthodes

                  Choisir des mots auquels on s'attend :

                  • get pour recevoir de l'information,
                  • is pour exprimer un prédicate,
                  • etc.

                  Ne pas faire le malin

                  Éviter l'humour lorsque l'on nomme des éléments d'un programme. Si la blague est oubliée, cela peut porter à confusion. Dites ce que vous pensez, et pensez ce que vous dites.

                  Choisir un mot par concept

                  Et s'y tenir ! Typiquement éviter de faire cohabiter : fetch, retrieve et get. Les noms doivent être autonomes et cohérent, si les concepts sont similaires, les écritures de ces concepts doivent être simulaires, et inversement.

                  Cela constitue le lexique du programme et il ne doit pas perturber le lecteur.

                  Éviter les jeux de mots

                  Lorsqu'un mot peut avoir deux sens différents, mieux vaut le bannir. Par exemple lorsque le concept est semblable mais agit de manière sensiblement différente, mieux vaut choisir un autre mot.

                  Choisir des noms dans le domaine de la solution

                  Le domaine du problème n'est généralement pas le domaine des développeurs du code. Mieux vaut choisir des mots qui sont dans le domaine de la solution (donc typiquement des termes informatiques).

                  Choisir des noms dans le domaine du problème

                  Lorsque le concept n'appartient PAS au domaine informatique, ne pas essayer de simplifier et vulgariser. Mieux vaut utiliser le terme technique exacte du problème pour pouvoir faire appel à un expert du domaine le cas échéant.

                  Ajouter un contexte significatif

                  La plupart des noms ne sont pas significatifs en l'état. Il faut leur redonner un contexte à travers des classes, fonctions ou espaces de noms appropriés. Voir d'ajouter un préfixe en dernier ressort.

                  Ne pas ajouter de contexte inutile

                  Éviter de mettre de l'information redondante (le nom de l'application elle-même par exemple) ou hors de propos (distinctions adresse postale d'un client ou d'un fournisseur).

                  Mots de la fin

                  Le choix des noms est difficile et nécessite

                  • une bonne aptitude à décrire,
                  • une culture générale partagée,
                  • un bon enseignement.

                  Beaucoup de développeurs ont peur du renommage, mais nous ne mémorisons généralement pas réellement les noms dans un programmes. Nous les traitons et les oublions quand nous avons fini de travailler sur une zone particulière du programme.

                  Questions abordés pendant les discussion

                  Nous avons globalement eu moins de discussions pendant cette séance, le chapitre énonçant finalement des usages qui sont déjà assez fortement présents chez les développeurs pros.

                  Q1: Point de désaccord sur la présence de mots comme "list" dans un nom

                  Par exemple pour distinguer un élément d'une collection VS une collection elle-même. D'un côté l'utilisation du pluriel peut parfois être dure à remarquer. D'un autre côté, l'ajout d'autres mots "parasites" comme "group_of" ou "bunch_of" conduit à de l'imprécision. Au cas par cas, cette règle peut sembler un peu forte.

                  Q2: Choix des noms prononçables, portage de vieux code

                  Certains code dans des langages comme Cobol imposent des contraintes fortes sur le nommage des variables qui ont souvent mené à des dérives comme des noms composés quasi-exclusivement d'initales et de chiffres. Ces noms imprononçables sont très généralement source de confusion, lors d'un portage mieux vaut complètement renommer ces éléments.

                  Q3: Point sur la codification VS la création d'un lexique

                  Ne pas confondre l'utilisation d'un lexique commun et la codification. Si l'importance du lexique devient telle que l'apprendre et le comprendre n'est plus triviale alors ce lexique tire vers la codification ce qui est une mauvaise chose.

                  Q3b: notation hongroise

                  Cette notation a en plus le défaut de ne pas être robuste à la maintenance, si l'on change légèrement le typage des éléments, on peut se retrouver à devoir changer le nom de la variable alors que son utilisation et son sens n'ont pas changé.

                  Q4: Contexte de noms : les espaces de noms

                  Les espaces de noms sont très utiles pour organiser les éléments d'un programme cependant tous les langages ne possèdent pas la même notion d'espace de nom (pas le même contexte d'utilisation et pas le même impact sur le code), et même la présence d'un tel mécanisme ne garantit pas que les développeurs vont l'utiliser.

                  Pour comparaison, on peut prendre la notion d'espace de noms à la C++ et la notion de package à la Java. Java y définit une notion de visibilité, ce qui n'est pas le cas de C++, et malgré le fait que cette notion d'espace de nom permettent de donner plus de sens au code (par la visibilité justement), cette notion ne semble pas être si utilisée par la communauté Java.

                  -
                  Edité par gbdivers 5 mai 2018 à 19:50:50

                  • Partager sur Facebook
                  • Partager sur Twitter

                  Rejoignez le discord NaN pour discuter programmation.

                    27 novembre 2017 à 15:45:57

                    Rendez-vous ce soir à 20h sur le discord, pour ceux qui veulent, pour discuter sur le chapitre 5 "Mise en forme".
                    • Partager sur Facebook
                    • Partager sur Twitter

                    Rejoignez le discord NaN pour discuter programmation.

                      4 décembre 2017 à 16:40:44

                      N'oubliez pas ce soir, nous discuterons des chapitres 6 "Objets et structures de données" et 7 "Gestion des erreurs". Rendez-vous a 20h sur le vocal du discord.
                      • Partager sur Facebook
                      • Partager sur Twitter

                      Rejoignez le discord NaN pour discuter programmation.

                        14 février 2018 à 13:56:06

                        Lors de la séance le lundi 12 février, nous avons discuté des points suivants :

                        • les chapitres 14 à 16 sont trop spécifiques au Java et sont moins intéressants à discuter. Donc on ne les fait pas.
                        • le chapitre 17 reprend tous les points abordés dans le livre. Nous avons fait une relecture rapide.
                        • Ksass`Peuk s’est proposé pour faire un résumé du livre.

                        En conséquence, nous pouvons considérer que la lecture du livre "Coder proprement" de R.C. Martin est finie et nous pouvons passer au livre suivant. Plusieurs décisions ont été prises :

                        • ne plus se limiter à un livre accessible aux débutants.
                        • ne plus se limiter à un livre en français.
                        • ne plus se limiter à un livre de petite taille.

                        Il a également été décidé de s’orienter vers un livre sur l’intelligence artificielle et/ou l’algorithmique. Les livres proposés au vote sont donc les suivants (sous confirmation que les PDF sont disponibles) :

                        Bien sûr, rien n’est figé dans le marbre, vous pouvez toujours discuter de ces points sur le discord. Le sondage sera créé dimanche soir sur le discord, vous avez donc quelques jours pour proposer d’autres livres et discuter des propositions.

                        Quelques news du discord.

                        N’hésitez pas à participer aux discussions sur le discord.

                        • Partager sur Facebook
                        • Partager sur Twitter

                        Rejoignez le discord NaN pour discuter programmation.

                          8 mai 2018 à 0:42:11

                          Le livre actuel "Introduction to Algorithms" ne semble pas plaire a beaucoup de monde. Rendez vous demain, pour ceux qui veulent, pour discuter rapidement sur un éventuel changement de livre. A 20h, sur le discord (cf ma signature). On va choisir très probablement livre plus orienté débutant et en français.
                          • Partager sur Facebook
                          • Partager sur Twitter

                          Rejoignez le discord NaN pour discuter programmation.

                            1 juin 2018 à 12:09:42

                            Comme la semaine dernière (on va essayer de faire ca toutes les semaines. Sauf la semaine prochaine, je suis en vacances)

                            Rendez-vous ce soir pour la discussion live en vocal à 20h sur le discord NaN https://discordapp.com/invite/zcWp9sC  

                            Est-ce une erreur de vouloir apprendre à développer des jeux vidéos ?

                            La création de jeux vidéos est probablement la motivation principale de nombreux débutants en programmation, particulièrement en C++. Malheureusement, les raisons d'un tel engouement sont souvent basées sur des des a priori sur le développement de jeux vidéos.

                            Il faut reconnaître que le développement de jeux vidéos est un domaine qui peut être passionnant. En premier lieu parce que les jeux vidéos en eux-mêmes sont passionnants. Mais aussi parce que les jeux vidéos demandent des compétences dans de très nombreux domaines, artistiques ou techniques : graphismes, sons, game design, performances, intelligence artificielle, etc. 

                            Le but de cette discussion va être d'avoir le point de vue général d'un développeur de jeux vidéos sur les différentes problématiques de ce domaine.

                            -
                            Edité par gbdivers 1 juin 2018 à 12:16:46

                            • Partager sur Facebook
                            • Partager sur Twitter

                            Rejoignez le discord NaN pour discuter programmation.

                            Club de lecture de la communauté openclassroom

                            × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                            × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                            • Editeur
                            • Markdown