IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Algorithmes et structures de données Discussion :

Pourquoi notre propre code nous est-t-il incompréhensible ?


Sujet :

Algorithmes et structures de données

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2014
    Messages : 194
    Points : 12 291
    Points
    12 291
    Par défaut Pourquoi notre propre code nous est-t-il incompréhensible ?
    Pourquoi notre propre code nous est-il incompréhensible ?
    Un développeur se penche sur la question et identifie six problèmes

    Tous les développeurs se sont posé un jour cette question : « pourquoi je n’arrive pas à comprendre ce bout de code ? Pourtant, c’est moi qui l’avais écrit quelques mois auparavant ! ». Le pire, c’est que parfois même en lisant les commentaires on ne comprend pas, et ça arrive si souvent qu’on se demanderait dans ces cas-là si notre intelligence s’est dégradée ou si au moment d’écrire ce code nous étions possédés par une entité intellectuelle supérieure.

    Stephen Young, un développeur, designer et blogueur, a écrit récemment sur ce sujet qu’on devrait apprendre à éparpiller les miettes de pain derrière nous lorsqu’on écrit un code source pour pouvoir retrouver notre chemin lorsqu’on y revient. Oui, mais comment ?

    Selon lui, il existerait 6 problèmes qui font que notre programme -si clair et élégant- ressemblera à du charabia lorsqu’on le relira quelques mois plus tard :
    1. Les modèles mentaux trop complexes : un programme est une solution à un problème du monde réel, lorsqu’on veut trouver cette solution on doit d’abord former un modèle du problème, puis un modèle de la solution (que Stephen Young appelle modèle sémantique) avant de passer au code. Il faudra donc veiller à ne pas sauter directement du problème à la solution sans former de modèles. Aussi, il faudra veiller à simplifier ces modèles autant que possible, car « les problèmes que nous tentons de résoudre sont suffisamment complexes. On ne doit pas ajouter à cela plus de complexité ».
    2. La mauvaise traduction du modèle mental : cette traduction « syntaxique » vise à transformer le modèle sémantique en code source. Le problème est qu’il est facile de traduire ce code lorsque le modèle sémantique est fraîchement cartographié dans notre tête, mais lorsqu’on y revient plus tard, ceci n’est pas aussi évident.
      Pour éviter les problèmes syntaxiques, il faudra veiller à bien choisir les noms des variables, fonctions et arguments pour qu’on puisse facilement comprendre leurs rôles. Aussi il faudra veiller que les noms des modules et classes soient autant que possible proches du modèle sémantique. De plus, il faudra que chaque classe ait un seul but : « je finis souvent par réécrire une classe parce que j’ai du mal à lui donner un nom assez court qui décrit tout ce qu'elle fait », assure Young.
      Quant aux commentaires, ils sont utiles si on n’en abuse pas, ils doivent décrire pourquoi vous avez eu à faire quelque chose et non pas comment vous l’avez fait.
    3. Pas assez de regroupement : lorsqu’on programme, on remarque qu’on a souvent besoin de répéter un nombre de choses plusieurs fois, c’est pour ça qu’il existe maintenant plusieurs Design Pattern, des fonctions standard et des bibliothèques qui sont très utiles dans le sens où « on n’a plus besoin de penser à la façon dont le code fait quelque chose, mais plutôt se concentrer sur ce qu'il fait ».
    4. Utilisation obscure de vos bouts de code : « lorsque vous revenez plus tard à votre code source, il est souvent très difficile de reconstituer toutes les utilisations prévues de vos classes et méthodes. Généralement, ceci est dû aux différents usages qui sont dispersés dans tout le reste de votre programme », écrit Young. Une des solutions à ce problème, selon lui, est de disposer d’un ensemble complet de cas de tests qui permettent d’avoir une image complète du code et de comment l’utiliser.
    5. Pas de chemin clair entre les différents modèles : ce chemin qui relie l’objectif de votre programme, au modèle sémantique puis au modèle syntaxique (code) doit être aussi simple que possible. « Parfois, il est préférable de choisir une structure de classe particulière ou un algorithme non pas pour son élégance, mais pour sa capacité à relier les différents modèles d’une façon claire et naturelle ».
    6. Inventer des algorithmes : « dans presque tous les cas, il existe des algorithmes qui peuvent être mis ensemble pour résoudre votre problème ». Programmer consiste donc à choisir des algorithmes existants dans la bonne combinaison pour résoudre un problème. Selon lui, « si vous inventez de nouveaux algorithmes, c’est soit que vous ne connaissez pas le bon algorithme à employer, soit vous travaillez sur une thèse de doctorat ».

    Pour conclure, Young conseille de fournir autant d'indices que possible afin de permettre à quiconque regardant votre code de recréer le même modèle sémantique que vous aviez à l'origine dans l'esprit. « Cela paraît simple, mais en réalité c’est très difficile de faire bien ».

    Source : Medium

    Et vous ?

    Êtes-vous d’accord avec Stephen Young sur ces six points ?

    Quel problème aimeriez-vous ajouter/modifier ?

  2. #2
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2004
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2004
    Messages : 374
    Points : 1 399
    Points
    1 399
    Par défaut
    Quel soulagement d'actuellement travailler sur ma thèse de doctorat !

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 187
    Points : 434
    Points
    434
    Par défaut
    Ca résume la philosophie de la programmation objet

    Les modèles mentaux trop complexes : la programmation objet permet de réduire la complexité unitaire de chaque "modèle" en limitant les dépendances (par opposition au modulaire)

    La mauvaise traduction du modèle mental : le principe de la moindre surprise du Ruby On Rails est un très bon exemple (j'ai plus le terme exact en tête)

    Pas assez de regroupement : deux lignes de code copiée-collées-modifiées plus de deux fois, ou une ligne répétée 3-4 fois est la manifestation d'une faute de conception en programmation "idéale". Ces "fautes" peuvent être justifiées bien sûr, donc commentées.

    Utilisation obscure de vos bouts de code : ça rejoint le point précédent

    Pas de chemin clair entre les différents modèles : là pour le coup je suis pas trop d'accord. Le besoin de comprendre un processus en détail et dans son ensemble implique souvent un trop grandes dépendance entre les "modèles". Un système maintenable est un système qu'on n'a pas besoin de comprendre dans sa globalité, "qui appelle qui" etc. C'est une raison pour lesquelles je pense que le "MVVM" de microsoft est une aberration de conception en comparaison au MVC.

    Inventer des algorithmes : écrire un algorithme se traduit inévitablement par un warning "complexité cyclomatique" dans checkstyle . Ecrire un algorithme pour encoder un truc, sérialiser, interpréter, ok. Mais c'est pas de la programmation objet, c'est du modulaire.

    Bref, il a écrit une manière très intéressante d'expliquer les fondements de l'objet !

  4. #4
    Membre expérimenté Avatar de Uranne-jimmy
    Homme Profil pro
    Bioinformatique
    Inscrit en
    Décembre 2012
    Messages
    778
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Bioinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Décembre 2012
    Messages : 778
    Points : 1 461
    Points
    1 461
    Par défaut
    J'ai tendance à diminuer le nombre de commentaire pour augmenter la nomination clair de mes variables et fonctions.
    N'ayant donc pas l'habitude de lire de commentaire, mon esprit arrive sans soucis à retrouver ma logique bien à moi dans mes programmes ^^
    (surtout que vu le temps que j'ai passé dessus, ça a aussi du me marquer)

    Par contre le dernier point je comprends pas : Je suis donc en train depuis le début de mon contrat dans mon entreprise de faire le travail d'un futur docteur avec un diplôme de technicien ? J'ai du mal à y croire.
    Expert en recherche google caféinomane

  5. #5
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2007
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 677
    Points : 2 137
    Points
    2 137
    Par défaut
    Moi non plus je ne suis pas fondamentalement d’accord avec le dernier point (ou alors je n’ai pas saisi le sens du propos). Peut-être que 9 fois sur 10 la roue existe, ça je peux l’admettre, mais de là à décréter que si on invente un algorithme c’est forcément qu’on ne connait pas le bon algorithme à employer, je ne suis pas du tout convaincu.
    Le WIP de The last bastion, mon projet de jeu-vidéo (un TD en 3D)

    Mon portfolio / Ma page fb

  6. #6
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Cet article est simplement un rappel de quelques bonnes pratiques de conception et de développement dont une piqûre de rappel régulière est nécessaire même avec l'expérience.
    Rien de révolutionnaire en soit.

    Personnellement, ne pas comprendre mon propre code m'arrivait surtout lors de mes études où j'avais tendance à beaucoup développer la nuit (aidé par des cocktails détonnant )...
    Par la suite, ça devient tout de même nettement plus rare.

    Désormais, je suis plus surpris par le manque de perf ou la consommation mémoire excessive de mon code.
    En effet, lorsque je suis concentré sur une fonctionnalité, je me focalise sur la simplicité du code, sa robustesse, sa modularité et le métier, surtout le métier même...
    Ce n'est qu'en seconde lecture, quelques semaines après une fois le recule pris, que je constate les évolutions à mettre en place pour améliorer les perf. (et là je rage contre moi-même car à chaque fois cela me paraît évident et que je ne comprends pas comment j'ai pu passer à côté lors du premier jet...)

    Développer est une tâche complexe avec énormément de paramètres à prendre en compte.
    Dans un monde idéal, on ferait la conception en 3 temps avec une pause à chaque fois et le développeur ne serait pas celui qui effectue la conception afin d'avoir une regard critique impartiale sur celle-ci.
    Malheureusement, le rythme des projets ne le permet pas...

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2010
    Messages
    126
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 126
    Points : 351
    Points
    351
    Par défaut
    Il m'arrive de reprendre le code de vieux projets personnels en ayant fait une pause de plusieurs années, et je ne les trouve jamais incompréhensible. La plupart du temps ma réaction est "tien ça c'est pas propre, j'aurais du le faire comme ça". J'ai tendance à essayer de soigner mon code, est comme Uranne-jimmy je limite le nombre de commentaire; je pense qu'une bonne pratique est d'utiliser les commentaires uniquement pour clarifier l'intention (le "pourquoi"), et de clarifier le "comment" en utilisant une nomenclature descriptive des variables, fonctions, objets, etc.

    Après dans un cadre pro je tombe parfois sur de tels torchons que ça ne m'étonnerais pas que leurs auteurs les trouves eux même incompréhensible au moment de leurs écritures...

  8. #8
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 409
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 409
    Points : 4 713
    Points
    4 713
    Par défaut
    Citation Envoyé par Saverok Voir le message

    Désormais, je suis plus surpris par le manque de perf ou la consommation mémoire excessive de mon code.
    En effet, lorsque je suis concentré sur une fonctionnalité, je me focalise sur la simplicité du code, sa robustesse, sa modularité et le métier, surtout le métier même...
    Ce n'est qu'en seconde lecture, quelques semaines après une fois le recule pris, que je constate les évolutions à mettre en place pour améliorer les perf. (et là je rage contre moi-même car à chaque fois cela me paraît évident et que je ne comprends pas comment j'ai pu passer à côté lors du premier jet...)
    C'est tout a fait normal, Knuth (qui n'est pas juste 'un développeur qui se penche sur une question') nous met en garde contre les optimisations prématurées et résume les étapes de l'algorithmie comme cela :
    1. Make it work.
    2. Make it right.
    3. Make it fast.

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 192
    Points : 395
    Points
    395
    Par défaut algo
    Inventer des algorithmes : « dans presque tous les cas, il existe des algorithmes qui peuvent être mis ensemble pour résoudre votre problème ». Programmer consiste donc à choisir des algorithmes existants dans la bonne combinaison pour résoudre un problème. Selon lui, « si vous inventez de nouveaux algorithmes, c’est soit que vous ne connaissez pas le bon algorithme à employer, soit vous travaillez sur une thèse de doctorat ».
    Contrairement à certains, je suis assez d'accord avec ça.

    Je pense que vous n'avez peut-être pas saisi ce qu'il a voulu dire ici.

    Peut-être peut-on reformuler comme ceci : "demandez-vous combien de fois vous avez écrit du code pour répondre à un besoin d'une manière qui n'a jamais été utilisée par personne depuis que la programmation existe".

    A moins que vous travailliez dans des domaines "relativement récents" ou très pointus tels que le traitement de l'image, la programmation parallèle, l'intelligence artificielle...

  10. #10
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Responsable Architecture logicielle
    Inscrit en
    Décembre 2008
    Messages
    541
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable Architecture logicielle
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2008
    Messages : 541
    Points : 1 729
    Points
    1 729
    Par défaut
    Citation Envoyé par temoanatini Voir le message
    Contrairement à certains, je suis assez d'accord avec ça.

    Je pense que vous n'avez peut-être pas saisi ce qu'il a voulu dire ici.

    Peut-être peut-on reformuler comme ceci : "demandez-vous combien de fois vous avez écrit du code pour répondre à un besoin d'une manière qui n'a jamais été utilisée par personne depuis que la programmation existe".

    A moins que vous travailliez dans des domaines "relativement récents" ou très pointus tels que le traitement de l'image, la programmation parallèle, l'intelligence artificielle...

    Dans certains domaines spécifiques (transport, etc) ,
    le développeur est fortement axé métier et est amené à concevoir ses propres algorithmes pour répondre à une problématique particulière ( changement de loi, moteur de calcul , etc).

    Les algorithmes standard ( parcours de graphe etc.) restent déjà établis mais leur utilisation conjointe donne un algorithme global qui n'existe probablement pas...
    Les propriétés mathématiques restent connues (statistiques, etc), mais c'est l'axe métier qui sera considéré comme un algorithme à part.

  11. #11
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par dfiad77pro Voir le message
    Dans certains domaines spécifiques (transport, etc) ,
    le développeur est fortement axé métier et est amené à concevoir ses propres algorithmes pour répondre à une problématique particulière ( changement de loi, moteur de calcul , etc).

    Les algorithmes standard ( parcours de graphe etc.) restent déjà établis mais leur utilisation conjointe donne un algorithme global qui n'existe probablement pas...
    Les propriétés mathématiques restent connues (statistiques, etc), mais c'est l'axe métier qui sera considéré comme un algorithme à part.
    De ce que je comprends, tu dis la même choses que l'auteur
    C'est l'orchestration des algo qui est à développer (et leur paramétrage) mais pris unitairement, ils existent déjà quelques parts

  12. #12
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    192
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 192
    Points : 395
    Points
    395
    Par défaut
    Citation Envoyé par dfiad77pro Voir le message
    Les algorithmes standard ( parcours de graphe etc.) restent déjà établis mais leur utilisation conjointe donne un algorithme global qui n'existe probablement pas...
    il me semble que dans le fond, c'est ce qu'il a voulu exprimer ici :
    « dans presque tous les cas, il existe des algorithmes qui peuvent être mis ensemble pour résoudre votre problème »

  13. #13
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2007
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 677
    Points : 2 137
    Points
    2 137
    Par défaut
    Citation Envoyé par temoanatini Voir le message
    A moins que vous travailliez dans des domaines "relativement récents" ou très pointus tels que le traitement de l'image, la programmation parallèle, l'intelligence artificielle...
    C’est le "à moins" qui fait que je ne suis pas d’accord avec l’auteur sur sa dernière affirmation.

    J’ai bossé pendant quelques années avec un docteur en informatique spécialisé en traitement d’image, et je peux t’assurer que les problématique sur lesquelles on bossait (enfin, surtout lui, moi je me "contentais" de transformer ses délires mathématiques en algo et de rendre le tout exploitable) avaient peu de chance d’être résolues après un simple état de l’art.

    Mais encore une fois, je suis conscient que 9 fois sur 10 l’algo qu’on écrit n’est qu’un agrégat d’algos "standards".
    Le WIP de The last bastion, mon projet de jeu-vidéo (un TD en 3D)

    Mon portfolio / Ma page fb

  14. #14
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par Amine Horseman Voir le message
    « je finis souvent par réécrire une classe parce que j’ai du mal à lui donner un nom assez court qui décrit tout ce qu'elle fait », assure Young.
    Et ben c'est que t'as pas assez de classes. Réécrire la classe ne sert à rien. Pour que le code soit lisible il faut qu'il soit court et qu'il se concentre à faire une chose à la fois. Un nom de classe de 15 bornes de long indique que la classe doit être splittée en plusieurs classes plus petites.

    Citation Envoyé par Amine Horseman Voir le message
    Quant aux commentaires, ils sont utiles si on n’en abuse pas, ils doivent décrire pourquoi vous avez eu à faire quelque chose et non pas comment vous l’avez fait.
    Le plus important c'est d'avoir des tests unitaires qui servent de documentation au code. Cette documentation étant vivante (puisque vous exécutez vos tests avant chaque commit) vous avez l'assurance qu'elle est à jour, et quelle est up-to-date.
    Dans ces conditions les commentaires deviennent pratiquement inutiles.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  15. #15
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Responsable Architecture logicielle
    Inscrit en
    Décembre 2008
    Messages
    541
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable Architecture logicielle
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2008
    Messages : 541
    Points : 1 729
    Points
    1 729
    Par défaut
    Citation Envoyé par temoanatini Voir le message
    il me semble que dans le fond, c'est ce qu'il a voulu exprimer ici :


    Oui, je radote un peu à mon âge donc à voir la définition d'algorithme au sens propre et figuré.

  16. #16
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 423
    Points : 8 699
    Points
    8 699
    Billets dans le blog
    43
    Par défaut
    Ce qu'affirme le bloggueur est peut-être intéressant, mais cela manque sérieusement d'exemples et de preuves à l'appui.
    Sans doute à étayer pour rendre l'article vraiment exploitable.

    Concernant le problème plus général de la lisibilité du code, par soi-même ou par d'autres, beaucoup a déjà été écrit à ce sujet.
    On pourrait citer parmi de nombreux conseils possibles les suivants :
    * Evitez le hacking en utilisant les subtilités d'un langage pour coder en un minimum de caractères (je pense par exemple à l'opérateur ternaire ? : parfois utilisé à tord et à travers. Le moins et souvent l'ennemi du mieux.
    * Evitez la verbosité excessive des commentaires où le code est noyé. Quand on a plus de commentaires que de code, c'est qu'il y a sans doute un problème.
    * Adopter un style de codage stable, consistant et s'y tenir, du moins sur un projet donné. Le bon usage de l'indentation pourtant le B-A-BA d'un code lisible n'est pas toujours respecté en 2014 et bientôt 2015...
    * Réutilisez les bibliothèques et frameworks existant plutôt que de réinventer la roue. Ceux-ci auront toujours plus de chance d'être mieux documentés et testés que votre propre création.
    * Etc.
    Tutoriels et FAQ TypeScript

  17. #17
    Membre expert
    Avatar de Chauve souris
    Homme Profil pro
    amateur (éclairé ?)
    Inscrit en
    Novembre 2005
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 76
    Localisation : Paraguay

    Informations professionnelles :
    Activité : amateur (éclairé ?)

    Informations forums :
    Inscription : Novembre 2005
    Messages : 1 186
    Points : 3 086
    Points
    3 086
    Par défaut
    Blanchi sous le harnois par la programmation C et C++, j'ai pris l'habitude d'écrire des fonctions petites et de les documenter (avec un joli pavé avant contenant description, conditions d'entrée, conditions de sortie et tests internes). Le problème n'est pas mes neurones sénescents, mais le fichu Visual Studio qui refuse de compiler ce qui a été écrit avec les versions précédentes (pas très éloignées dans le temps, d'ailleurs).
    "Toute l'histoire de l'informatique n'a été que l'histoire des systèmes d'exploitations" (Le Manifeste du PC)

  18. #18
    Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Novembre 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Novembre 2014
    Messages : 1
    Points : 3
    Points
    3
    Par défaut
    Oserais-je ajouter quelques considérations personnelles ? Euh… ouais, en fait :
    1. Les modèles mentaux trop complexes : Le sempiternel manque d’analyse, couplé effectivement à un manque de simplification. Quand on ne va pas jusqu’au bout, jusqu’à la bonne atomicité, ça se paye toujours, à plus ou moins longue échéance.
    2. La mauvaise traduction du modèle mental : absolument d’accord avec tout là-dedans. Et surtout mille fois oui, quand on commente on n’explique pas ce qu’on fait (qui doit normalement être compréhensible en respectant un minimum de règles d’écriture) mais POURQUOI ON L’A FAIT !
    3. Pas assez de regroupement : la factorisation c’est la vie
    4. Utilisation obscure de vos bouts de code : ça c’est sûr, dans certains cas il est même nécessaire de commencer par l’implémentation de ces tests. La question à se poser dans ce cas passe de « comment je vais le faire » à « comment je vais l’utiliser ». Quand on cherche à y répondre on se retrouve contraint à instrumenter son code par tous les moyens à sa disposition. C’est toujours ça de pris pour l’avenir. Retour au point 1.
    5. Pas de chemin clair entre les différents modèles : ça c’est entre autres le problème récurrent du choix entre une implémentation « algo-centrée » (par exemple une bonne grosse machine d’états) et une implémentation « data-centrée » (par exemple des tables de hashage spécialisées et auto-suffisantes). Au bout de toutes ces années j’ai la sensation qu’en ce domaine tout est une question d’expérience. Il n’y a pas de recette miracle hormis être excessivement rigoureux dans sa manière de concevoir. Et ce coup-ci retour au point 2...
    6. Inventer des algorithmes : oui, en règle générale tout a souvent déjà été fait. Mis à part ceux qui bossent sur des trucs vraiment pointus en R&D, participer à la réalisation d’un projet industriel en entreprise consiste à savoir quoi ré-utiliser.
    7. Pour conclure, un petit avis personnel : le code écrit par un développeur employé dans une entreprise appartient à cette entreprise. Point. Il doit donc être en permanence accessible et compréhensible par tout le monde. Ce qui débouche automatiquement sur la prise en compte de toutes les considérations précédentes.

  19. #19
    Membre actif
    Profil pro
    ingénieur
    Inscrit en
    Novembre 2011
    Messages
    165
    Détails du profil
    Informations personnelles :
    Localisation : France, Tarn (Midi Pyrénées)

    Informations professionnelles :
    Activité : ingénieur

    Informations forums :
    Inscription : Novembre 2011
    Messages : 165
    Points : 259
    Points
    259
    Par défaut
    Par contre le dernier point je comprends pas : Je suis donc en train depuis le début de mon contrat dans mon entreprise de faire le travail d'un futur docteur avec un diplôme de technicien ? J'ai du mal à y croire.
    plains toi! Moi je fait un travail de technicien avec un diplôme de docteur!

  20. #20
    Membre expérimenté Avatar de Uranne-jimmy
    Homme Profil pro
    Bioinformatique
    Inscrit en
    Décembre 2012
    Messages
    778
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Bioinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Décembre 2012
    Messages : 778
    Points : 1 461
    Points
    1 461
    Par défaut
    Citation Envoyé par tiresias54 Voir le message
    plains toi! Moi je fait un travail de technicien avec un diplôme de docteur!
    Ce serait pas un problème si j'étais pas technicien de recherche en microbiologie et si j'avais le bagage suffisant ! ^^
    Expert en recherche google caféinomane

Discussions similaires

  1. [Article] Pourquoi générer le code JavaScript est une fausse bonne idée
    Par sekaijin dans le forum Général JavaScript
    Réponses: 11
    Dernier message: 25/01/2015, 23h14
  2. Réponses: 4
    Dernier message: 04/06/2009, 10h51
  3. ce code n'est pas correct, pourquoi?
    Par laurent.w dans le forum Access
    Réponses: 2
    Dernier message: 14/12/2006, 15h11
  4. [JavaDOC] Ajouter notre propre javadoc dans Eclipse
    Par redzone dans le forum Eclipse Java
    Réponses: 5
    Dernier message: 27/01/2004, 11h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo