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:45

    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:24

    • Partager sur Facebook
    • Partager sur Twitter
      16 septembre 2017 à 0:16:09

      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:51:37

      • Partager sur Facebook
      • Partager sur Twitter
        22 septembre 2017 à 18:17:46

        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
          3 octobre 2017 à 17:34:45

          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
            9 octobre 2017 à 20:07:16

            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
              16 octobre 2017 à 18:35:54

              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:51:50

              • Partager sur Facebook
              • Partager sur Twitter
                17 octobre 2017 à 23:24:24

                Bonjour à tous.

                Merci à tous les participants hier, nous étions nombreux et la discussion fut intéressante.

                Suite a des problemes techniques (facon polie de dire que j'ai fait du n'importe quoi), la discussion n'a pas pu être enregistrée. On verra pour corriger cela la prochaine fois.

                Voici le résumé de la discussion, écrit par Ksass`Peuk. (Merci à lui)


                Séance du 16 octobre. Chapitre 1

                "Coder Proprement" est un livre de Robert C. Martin, dît "Oncle Bob". Il est principalement connu pour ses contributions à propos de la méthode Agile, de la gestion de projet et des principes SOLID. Ses autres livres sont également intéressants, il ne faut pas hésiter à les lire aussi.

                Les objectifs généraux de ce livre sont de fournir :

                • des guidelines pour la rédaction de code: noms, fonctions, commentaires, mise en forme,
                • une certaine connaissance des structures de données,
                • la bonne pratique qu'est "tester" le coder.

                Avec pour finalité d'être capable :

                • de différencier le bon et le mauvais code,
                • d'écrire du bon code,
                • de transformer du mauvaise code en bon code.

                Chapitre 1

                Le but de ce chapitre est de commencer à répondre à la question "qu'est ce qu'un code propre ?", à travers trois questions générales:

                • pourquoi aura-t-on toujours besoin de code ?
                • que le coût du désordre ?
                • qu'est-ce qui caractérise un code propre ?

                Il y aura toujours du code :

                L'abstraction augmente et l'on semble avoir de moins en moins besoin de coder, mais le code n'est finalement qu'un langage dans lequel on exprime nos exigences et il y aura toujours des exigences à exprimer.

                Le coût du désordre :

                Causes

                Les raisons entraînant la création d'un mauvais code sont très souvent reliées à un problème plus général dans tout projet : la pression du temps. C'est généralement du code réalisé trop vite pour répondre le plus rapidement possible à un besoin sans tenir compte de la maintenance future, on remet "à plus tard" le fait de rendre le code propre, mais "plus tard" signifie "jamais".

                Conséquences

                Il s'en suit un ralentissement de la productivité à cause de d'un code négligé dans lequel il est difficile d'avancer, car il est difficile à comprendre et aucune modification n'est négligeable. Surtout que reprendre à 0 est généralement complètement impossible et mène simplement aux mêmes travers.

                Produire du bon code est une question de survie professionnelle.

                Fausses causes, attitude

                Le relationnel avec les décideurs et les nouveaux développeurs est important. Les développeurs ont une trop forte tendance à rejeter la faute sur les décideurs qui les pressent mais il est de leur devoir :

                • de dire non lorsque quelque chose est impossible,
                • de s'assurer qu'il sera rare de devoir dire non à une demande faisable (avec un bon code).

                Code propre :

                Regroupement de plusieurs point de vue à propos de la rédaction de code. Un code propre doit être :

                • élégant : un code agréable à lire est plus facile à lire et donc plus facile à écrire.
                • simple : il y a une certaine idée de minimalisme (principe KISS), relié au point suivant ...
                • efficace : optimal en un certain sens, rien ne permet de l'améliorer de manière évidente,
                • explicite : il doit être assez expressif pour ne cacher aucune intention du développeur,
                • destiné à être partagé : fait pour être lu par des humains, et le désordre appelle le désordre.
                • testé : on assure qu'il fait ce que l'on veut (et les tests ré-expriment les besoins).

                Règle du boyscout : le code doit être plus propre que quand on est arrivé. Nous sommes reponsables d'écrire du code propre, de le maintenir propre et au besoin de le nettoyer.

                Questions abordées pendant les discussions :

                Q1 : il parle d'un style d'écriture, de manière de concevoir.

                Il faut que le code soit conçu pour être compréhensible, mais cela va plus loin que juste la bonne architecture et la bonne organisation. On revient sur l'expressivité : le code montre clairement l'intention du développer, il ne cache rien, il est limpide.

                Q2 : bonnes pratiques dans les langages à travers des guidelines.

                Elles parlent à la fois :

                • de style d'écriture,
                • de bonne manière de concevoir.

                Exemples dans certains langages :

                Les designs patterns sont un exemple dans le point sur la conception. Ils peuvent néanmoins aussi aider d'autres codeurs à comprendre ce qu'on a voulu exprimer parce que ce sont des schémas connus (sans être figés ! Il sont sujets à adaptation). Le principal second intérêt des DP est de comprendre comment on a abouti à leur conception.

                L'utilisation des commentaires est un exemple sur le style d'écriture. Les commentaires ne doivent pas servir à comprendre l'intention du code. Ils doivent seulement aider à faire comprendre éventuellement des point des détails du code qui ne sont pas exprimables par le langage. Lorsqu'un code a besoin de commentaires expliquant le patch d'un patch, d'un patch, c'est le signe que l'on travaille sur un mauvais code.

                Documenter est délié de la notion de commentaire. Ce n'est pas parce que le langage fournit la documentation par l'intermédiaire du commentaire (au sens du langage) que l'on est effectivement en face de commentaires.

                Q3 : Relation avec les décideurs : de la difficulté à être entendu avec les décideurs.

                C'est important d'avoir un bon relationnel et être capable :

                • d'expliquer à d'autres,
                • d'apprendre aux autres à gérer ces problématiques.

                La méthode AGILE est une tentative de résolution par l'introduction du "business" au niveau de la production du code. Les dérives courantes sont l'utilisation de cette méthode pour reconstituer un modèle non agile où les développeurs exécutent sans se faire entendre.

                Il est important de présenter de manière concrète des fonctionnalités auprès des décideurs mais surtout aux destinataires du projet. Idéalement les réunions business et fonctionnalités devraient être complètement séparées pour éviter ce type de dérive.

                Addedum de discussion : l'UML (ou formalisme équivalent) n'est pas toujours adapté pour la compréhension mais peut aider pour le dialogue avec des non-initiés.

                Q4 : Relation avec les apprenants : problème de formation des personnes.

                Apprentissage : projet jetable, problème pour acquérir de la compétence sur la maintenance de projet. Nécessité de formation personnalisées pour former les gens au plus près et ne pas les lâcher complètement dans la nature avec un faux sentiment de compréhension.

                Problématique de l'enseignement "classique" vs les formations internet : impossible de créer et suivre des projets sur le long terme. C'est possible sur les formation internet, mais pas souvent fait.

                Autres questions non abordées :

                Opposition entre code efficace vs premature optimisation

                Certains experts cités dans ce premier chapitre indiquent que pour eux, un code propre est un code efficace. L'idée est qu'un code qui est déjà optimal n'aura pas besoin d'être modifié et donc demandera moins de maintenance.

                Est-ce que cette idée de code optimial ne s'oppose pas au problème de premature optimisation ?

                Choix du langage de programmation

                Deux approches sont possibles pour choisir le langage de programmation (mais on peut étendre cette question a tous les choix technologiques sur un projet) :

                • utiliser le langage le plus adapté à un problème. Donc potentiellement un langage que l'on ne maîtrise pas.
                • utiliser un langage que l'on maitrise, meme s'il n'est pas le plus adapté à un problème. (Dans la limite du raisonnable, on ne va pas créer un site web en assembleur).

                Quel choix feriez-vous et dans quels contextes ?

                Strawpolls :

                Répondus :

                Non proposé :

                Pour prolonger la discussion

                Une discussion a été ouverte, pour continuer de parler des design patterns : https://openclassrooms.com/forum/sujet/club-de-lecture-les-design-patterns

                • Partager sur Facebook
                • Partager sur Twitter
                  20 octobre 2017 à 13:12:20

                  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
                    27 octobre 2017 à 10:37:15

                    ok pas de souci on prendra part i a
                    • Partager sur Facebook
                    • Partager sur Twitter
                      6 novembre 2017 à 17:02:27

                      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:52:12

                      • Partager sur Facebook
                      • Partager sur Twitter
                        27 novembre 2017 à 15:38:11

                        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
                          4 décembre 2017 à 16:39:38

                          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
                            14 février 2018 à 13:56:28

                            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
                              8 mai 2018 à 0:46:50

                              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
                                1 juin 2018 à 12:10:24

                                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:54

                                • Partager sur Facebook
                                • Partager sur Twitter
                                  30 juin 2018 à 15:34:33 - Message modéré pour le motif suivant : Message complètement hors sujet


                                  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