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

Actualités Discussion :

Les développeurs consacrent trop de temps à corriger le mauvais code

  1. #41
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Il ne faut pas confondre complexe et compliqué.

    On répond à des problématiques complexes qui nécessitent forcément des réponses complexes, sinon pas besoin de nous, autant le faire à la main.

    Par contre, sauf dans de rares cas, ce n'est pas normal en 2018 que ça vire au compliqué. Sinon effectivement ça pue le mauvais choix, d'outils et/ou de conception et/ou de personne, en tout cas il y a un loup en amont quelque part effectivement.

    Cette complexité elle doit rester métier / orga / management / moyens / temps etc. Lorsque ça vire à la technique ça pue le geek qui s'est encore embarqué dans des trucs et des machins pensant tout faire tout mieux que tout le monde et surtout de ce qu'il ne connait pas.

    J'ai trouvé deux phénomènes provocateurs :
    - Les "chefs" ou "décideurs" ou "mecs du conseil" qui veulent une proportionnalité entre coder et produire. Donc 0 place à la sensibilité, formation, la veille, etc.
    - Les geeks suprêmes maîtres du monde. Donc 0 place à la sensibilité, la formation, la veille, etc.

    Et lorsque le chef est geek, meilleur amis de ses devs geek, là ça schlingue du cul sévère ^^
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  2. #42
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par mister3957 Voir le message
    Il ne faut pas confondre complexe et compliqué.
    En français officiel, il n'y a pas de distinction très nette entre complexe et compliqué.

    Extraits de la 9e édition du dictionnaire de l'Académie française :
    • Complexe = Qui n'est pas simple, qui est composé d'éléments divers et entremêlés ; compliqué, difficile à comprendre.
    • Compliqué = Composé de parties plus ou moins nombreuses qui ont entre elles des rapports difficiles à analyser, à saisir ; dont la réalisation ou l'usage est délicat ou difficile.


    Citation Envoyé par mister3957 Voir le message
    On répond à des problématiques complexes qui nécessitent forcément des réponses complexes, sinon pas besoin de nous, autant le faire à la main.
    On a aussi besoin des développeurs pour automatiser des tâches simples et répétitives.

  3. #43
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 551
    Points
    10 551
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    En français officiel, il n'y a pas de distinction très nette entre complexe et compliqué.
    Pour moi, et au vu des définitions c'est clair

    Complexe porte sur la mixité des éléments (de trivial à très technique) et justement certains éléments peuvent être très techniques.
    Compliqué porte plus sur l'interaction entre les éléments.

    Moi je mets en plus, pour complexe, la grande étendue du système

  4. #44
    Membre à l'essai

    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2018
    Messages
    34
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Burundi

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Septembre 2018
    Messages : 34
    Points : 19
    Points
    19
    Billets dans le blog
    1
    Par défaut
    C'est vrai que ces situations peuvent faire recurer quelques entreprises mais c'est aussi nécéssaire pour le moment

  5. #45
    Membre averti
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 106
    Points : 311
    Points
    311
    Par défaut
    Citation Envoyé par sirthie Voir le message
    +1n !

    Combien de délais de réalisation de projets sont-ils fixés trop court/-cher par des commerciaux ? Est-ce la faute des devs s'ils passent "trop de temps en maintenance" à cause de délais fixés trop court ?
    Situation vécue :
    CHEF : Le client a besoin d'un batch pour traiter des données. On a vendu 9 jours pour ça au client.
    MOI : OK, bon, vu le truc... En 2-3 jours, ça pourra être fait, on peut garder un peu de marge pour les éventuels retours de bugs.
    CHEF : Ha non. En fait, les commerciaux ont déjà consommé 7,5 jours pour vendre le truc. Donc il te reste 1 jour pour tout faire, parce qu'on veut quand même un minimum de marge.
    MOI : ...

    Autre situation vécue :
    CHEF : Alors on a vendu ça et ça au client, et ça aussi. Tu a X jours pour le faire.
    MOI : ...
    * Une heure après, je reçois un appel direct du client (client disposant de commerciaux anciennement techniques) *
    CLIENT : Ils sont un peu cons chez vous non ? C'est pas réalisable ce qu'ils ont proposé. Fais comme tu peux et prends ton temps, on veut un truc aux oignons !
    MOI :

    Et parmi tant d'autres.

    C'est pour ça que j'exècre de plus en plus ces fichues SSII, le cancer du paysage informatique français.

  6. #46
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par JCD_31 Voir le message
    * Une heure après, je reçois un appel direct du client (client disposant de commerciaux anciennement techniques) *
    CLIENT : Ils sont un peu cons chez vous non ? C'est pas réalisable ce qu'ils ont proposé. Fais comme tu peux et prends ton temps, on veut un truc aux oignons !
    MOI :
    Vécu tellement en traduction technique aussi… Un contact direct avec le client, c'est de l'or. À leur décharge, les commerciaux ont tellement peur de proposer des vrais tarifs au risque de perdre le projet qu'ils donnent d'office le prix le plus minable qu'ils peuvent offrir. Avec un contact client, on peut renégocier. Bon, on passe un peu pour des branquignoles parfois, mais ça permet de faire le tri dans les clients aussi : ceux qui tiennent à la qualité restent, les autres vont voir chez des prestataires moins scrupuleux

  7. #47
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par JCD_31 Voir le message
    Situation vécue :
    CHEF : Le client a besoin d'un batch pour traiter des données. On a vendu 9 jours pour ça au client.
    MOI : OK, bon, vu le truc... En 2-3 jours, ça pourra être fait, on peut garder un peu de marge pour les éventuels retours de bugs.
    CHEF : Ha non. En fait, les commerciaux ont déjà consommé 7,5 jours pour vendre le truc. Donc il te reste 1 jour pour tout faire, parce qu'on veut quand même un minimum de marge.(.../...)
    Vécu aussi, celui-là. Plusieurs fois. Et pas qu'en SSII. En édition de logiciels aussi.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  8. #48
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2008
    Messages
    167
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Février 2008
    Messages : 167
    Points : 471
    Points
    471
    Par défaut
    Citation Envoyé par Christian Olivier Voir le message
    Les développeurs (18 millions dans le monde) peuvent agir ensemble comme un « multiplicateur de force » puisque, comme l’a précisé l’enquête, ils « ont le potentiel, collectivement, d’augmenter le PIB mondial de 3000 milliards de dollars au cours des dix prochaines années ». Les organisations qui les emploient auraient donc tout intérêt à les « utiliser » plus efficacement.
    D'un part le PIB mondial je n'en fou royalement, d'autre part, pour nous utiliser efficacement, il faudrait commencer par nous faire des spécifications au petits ognons et avoir bien réfléchie aux fonctionnels du logiciel.

    Et puis séparer les développeurs par technologie/chose/truc à la mode/je ne sais pas quoi encore (traduction : backoffice, FrontOffice, fullstack, ...) n'augure rien de bon pour les couts de maintenance. Chacun renvoyant la patate chaude à l'autre (ou jetant le bébé avec l'eau du bain, au choix), et personne ne connaissant le métier du client et son vrai besoin .

  9. #49
    Membre expérimenté
    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2016
    Messages
    373
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Septembre 2016
    Messages : 373
    Points : 1 335
    Points
    1 335
    Par défaut
    Citation Envoyé par sirthie Voir le message
    Je ne voudrais pas être désobligeant, mais à te lire, j'ai l'impression que tu n'as jamais codé. Il y a plein de codes qui "fonctionnent"... jusqu'à ce que tu modifies quelque chose, et là, c'est le bordel, et tu sais même pas déterminer pourquoi, tellement le code est un foutoir pas possible.
    Je ne code que depuis quelques année certes, mais je touche quotidiennement à différents langages sur différent logiciel qui ont tous été développer par une ou plusieurs personnes différentes au cours de ses 15/20 dernières années. Alors du code qui claque au moindre changement je connais. En fait sur certain logiciel j'ai pris la décision de ne jamais toucher l'existant mais d'ajouter une couche, c'est chiant, souvent compliquer, je râle beaucoup mais ça tient et fonctionne. Et quand je ne peu pas faire autrement, je prend le temps de commenter un maximum (ouai parce que les mecs qui développe et qui commente sont rare...) ce que j'arrive à comprendre pour pouvoir m'y retrouver plus tard.

    Bref, ses codes en bordel, très difficilement évaluable... Bha c'est mon quotidien. Est ce du mauvais code pour autant ? Va savoir, est ce que les personnes qui ont coder ça on mis en place le logiciel sur un coup de chance ? Est ce que ce ne sont pas les différentes personnes qui sont passer les unes à la suites des autres qui rendent le code aussi difficile ? Les couches que j'ai ajouter ne sont pas forcément plus propres que ce qui existe déjà. Au moins elles sont commentées...

    Le code n'est pas propre c'est clair. J'aurais bien envie de tout ré-écrire, mais honnêtement même les clients n'ont pas toute les spec de leur produit... Alors tout refaire en ce basant uniquement sur un code très peu lisible c'est surtout prendre le risque d'oublier quelques chose. Ou de ce rendre compte trop tard qu'on à pas vue telle ou telle fonctionnalité très spécifique. Et là deux solution, tout ré-écrire une nouvelle fois ou l'ajouter à l'arrache. En bref, c'est faisable, mais il faut avoir beaucoup de temps à perdre alors que le code actuel fonctionne et fait le taff.

    Citation Envoyé par sirthie Voir le message
    Donc, non, un bon code n'est pas seulement un code qui "fonctionne" (dans un état donné) ; ça, c'est pour les utilisateurs.

    Un bon code doit également être un code bien organisé, bien structuré, bien commenté, optimisé, factorisé, minimal, lisible, intelligible, avec des conventions de nommage, conforme aux standards/pratiques actuell(e)s, etc., etc.
    Pour moi c'est la description d'un code propre. Et un code peut être propre sans pour autant être bon. Un code peut être propre et inclure des traitements inutiles qui le ralentisse ou provoque des erreurs dans certain cas. Et des bouts de code propre j'en ai ré-écrit pas mal aussi (en expliquant au stagiaire qui l'avait développer les raisons de cette ré-écriture, ainsi qu'en lui expliquant le nouvel algo mis en place... Bref...).

    Citation Envoyé par sirthie Voir le message
    Je ne nie pas que cela puisse exister, mais avec mon expérience (intégrateur web), j'ai beaucoup de mal à imaginer la chose. Faire ça volontairement serait tout simplement vraiment trop contraignant pour le codeur.

    De surcroît, s'il postule pour un nouvel emploi quel code pourrait montrer à un employeur un codeur tel que vous l'évoquez ? Et n'oubliez pas que dans le web, on peut consulter le code...

    Enfin, dans le web, toujours, on travaille souvent en équipe. J'ai du mal à imaginer que quelqu'un qui fait du mauvais code (au moins) volontairement ne se fasse pas repérer tôt ou tard à tout le moins s'il n'est pas seul dans son domaine (front-end, back-end) à travailler dans la boite.
    Et pourtant, je travaille sur un logiciel VBA qui est coder dans ce sens. Les tables sont remplis avec des alias. Il n'y a quasiment aucun id pour relier les tables mais toujours des string avec alias. Les champs on des nominations très alambiqué. Et le code est un ensemble de fonction de 5 lignes maximum (Et qui appel donc des sous fonctions qui elles mêmes appelles des sous fonctions qui appelles elles aussi des sous fonction qui ...) qui nous font voyager sur des dizaines de modules différents. Le mec qui à développer l'application c'est même amuser à créer des fonctions pour chaque fonction access existant. Ce qui fait qu'au lieu de faire par exemple un "Nz(Value, "")", il passe par la fonction "Isnull(Value)", rendant la lecture de sont code extrêmement difficile. Et là si t'es pas le mec qui à développer l'appli et qui sais quel syntaxe il à mis en place... Bref, ça existe :/

  10. #50
    Membre éprouvé
    Homme Profil pro
    Intégrateur Web
    Inscrit en
    Août 2012
    Messages
    263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Intégrateur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2012
    Messages : 263
    Points : 1 040
    Points
    1 040
    Par défaut Tout à fait exact
    Citation Envoyé par Edrixal Voir le message
    Je ne code que depuis quelques année certes, mais je touche quotidiennement à différents langages sur différent logiciel qui ont tous été développer par une ou plusieurs personnes différentes au cours de ses 15/20 dernières années. Alors du code qui claque au moindre changement je connais. En fait sur certain logiciel j'ai pris la décision de ne jamais toucher l'existant mais d'ajouter une couche, c'est chiant, souvent compliquer, je râle beaucoup mais ça tient et fonctionne. Et quand je ne peu pas faire autrement, je prend le temps de commenter un maximum (ouai parce que les mecs qui développe et qui commente sont rare...) ce que j'arrive à comprendre pour pouvoir m'y retrouver plus tard.

    Bref, ses codes en bordel, très difficilement évaluable... Bha c'est mon quotidien. Est ce du mauvais code pour autant ? Va savoir, est ce que les personnes qui ont coder ça on mis en place le logiciel sur un coup de chance ? Est ce que ce ne sont pas les différentes personnes qui sont passer les unes à la suites des autres qui rendent le code aussi difficile ? Les couches que j'ai ajouter ne sont pas forcément plus propres que ce qui existe déjà. Au moins elles sont commentées...

    Le code n'est pas propre c'est clair. J'aurais bien envie de tout ré-écrire, mais honnêtement même les clients n'ont pas toute les spec de leur produit... Alors tout refaire en ce basant uniquement sur un code très peu lisible c'est surtout prendre le risque d'oublier quelques chose. Ou de ce rendre compte trop tard qu'on à pas vue telle ou telle fonctionnalité très spécifique. Et là deux solution, tout ré-écrire une nouvelle fois ou l'ajouter à l'arrache. En bref, c'est faisable, mais il faut avoir beaucoup de temps à perdre alors que le code actuel fonctionne et fait le taff.



    Pour moi c'est la description d'un code propre. Et un code peut être propre sans pour autant être bon. Un code peut être propre et inclure des traitements inutiles qui le ralentisse ou provoque des erreurs dans certain cas. Et des bouts de code propre j'en ai ré-écrit pas mal aussi (en expliquant au stagiaire qui l'avait développer les raisons de cette ré-écriture, ainsi qu'en lui expliquant le nouvel algo mis en place... Bref...).



    Et pourtant, je travaille sur un logiciel VBA qui est coder dans ce sens. Les tables sont remplis avec des alias. Il n'y a quasiment aucun id pour relier les tables mais toujours des string avec alias. Les champs on des nominations très alambiqué. Et le code est un ensemble de fonction de 5 lignes maximum (Et qui appel donc des sous fonctions qui elles mêmes appelles des sous fonctions qui appelles elles aussi des sous fonction qui ...) qui nous font voyager sur des dizaines de modules différents. Le mec qui à développer l'application c'est même amuser à créer des fonctions pour chaque fonction access existant. Ce qui fait qu'au lieu de faire par exemple un "Nz(Value, "")", il passe par la fonction "Isnull(Value)", rendant la lecture de sont code extrêmement difficile. Et là si t'es pas le mec qui à développer l'appli et qui sais quel syntaxe il à mis en place... Bref, ça existe :/
    Bonnes remarques. Perso, je n'ai que travaillé sur des projets de redesign de sites web dont la taille était suffisamment petite pour qu'ils puissent être refaits from scratch. Dans ces cas, essayer de comprendre et d'aménager le code existant (et de créer/modifier des contenus et de créer un nouveau design) prenait plus de temps que de repartir de zéro.

    J'imagine que pour du développement logiciel ou des sites web plus importants, ce n'est peut-être pas possible, pour des raisons de délai et/ou de budget ou autres.

    Pour moi c'est la description d'un code propre. Et un code peut être propre sans pour autant être bon. Un code peut être propre et inclure des traitements inutiles qui le ralentisse ou provoque des erreurs dans certain cas. Et des bouts de code propre j'en ai ré-écrit pas mal aussi (en expliquant au stagiaire qui l'avait développer les raisons de cette ré-écriture, ainsi qu'en lui expliquant le nouvel algo mis en place... Bref...).
    Remarque pertinente ! J'ai quand même mentionné dans mon commentaire qu'un bon code n'est pas seulement un code qui "fonctionne", et donc, qu'un bon code doit également fonctionner, et que j'incluais dans les mauvais codes les codes surdimensionnés pour produire un résultat donné (le genre jQuery pour réaliser un effet basique). Tu as raison de distinguer les deux.

    Cela dit, si tout le monde codait bien dès le départ, si... si... si...

  11. #51
    Membre éprouvé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Août 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Août 2014
    Messages : 476
    Points : 1 042
    Points
    1 042
    Par défaut
    Idem, on a des gens chez nous qui adorent coder les tests unitaires (ils ne produisent que ca d'ailleurs). Du coup ils recodent des tests unitaires sur des softs qui ont 10 ans d'age et qui tournent sans soucis en prod. Totalement absurde.
    Revoir des briques ou des parties que tu ne sens pas fiables, pas robuste ou trop bridé (ex : pb perfs) ca a du sens mais reecrire pour reecrire ou pour l'etat de l'art (oui on en a chez nous qui passent aussi leur journee a faire du refactoring de code), aucun interet (de toutes façons ce sont des heures generalement non vendues a nos clients).
    Generalement les technos evoluent tellement vite que reecrire du code 'qui fonctionne' mais qui n'est pas 'beau' n'a que peu d'interet a part derouler des heures.
    On l'a vecu quand on faisait des applis client lourds WPF, tout le code de gestion IHMs etait complexe et assez usine a gaz
    => on s'est pas amusé a le reprendre (il y avait des idées de refactoring de pans entiers pour faire du code "beau"; au final on a carrément changé de technos (la mode du client leger etant passé par là) et reecrit en js.

    Apres c'est le propre du developpeur de toujours considérer que ce qu'ont fait les precédents etait moche, mal foutu et donc refaire une enieme fois a sa sauce.
    On est tous passé par là c'est la maladie du developpeur. On est toujours le con de quelqu'un d'autre (generalement c'est le suivant qui reprend notre code).
    Autre maladie dans ma boite (on retrouve ca dans des grosses boites egalement), les devs preferent faire des POC (souvent sur des sujets bateaux - genre implémenter des choses - sans risques - pompées sur le NET) que de reprendre du dev existant (bref tellement plus fun de faire du neuf en jouant avec les technos plutot que de se taper la maintenance, sale boulot).
    Donc mon ressenti (resultat de ce que j'ai rencontré dans mon entourage professionnel (amis etc)) c'est que naturellement de nos jours, la maintenance/correction de code existant je ne pense pas que ce soit la tendance (sauf si vraiment ca ne marche pas).

  12. #52
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par Edrixal Voir le message
    Et le code est un ensemble de fonction de 5 lignes maximum (Et qui appel donc des sous fonctions qui elles mêmes appelles des sous fonctions qui appelles elles aussi des sous fonction qui ...) qui nous font voyager sur des dizaines de modules différents. Le mec qui à développer l'application c'est même amuser à créer des fonctions pour chaque fonction access existant. Ce qui fait qu'au lieu de faire par exemple un "Nz(Value, "")", il passe par la fonction "Isnull(Value)", rendant la lecture de sont code extrêmement difficile. Et là si t'es pas le mec qui à développer l'appli et qui sais quel syntaxe il à mis en place... Bref, ça existe :/
    Étant donné ta description, je n'ai pas l'impression que ce développeur ait volontairement codé de manière à rendre plus difficile la maintenance du code par ses successeurs.

    En ce qui concerne le découpage, certains développeurs lisent plus facilement du code découpé en sous-fonctions et d'autres lisent plus facilement des pavés.

    Par exemple, à mon boulot, j'avais fait un sondage : quel est le code Python le plus facile à lire parmi ces deux-là ?
    Code Python : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    """
    Parcourir récursivement les fichiers '.cpp', '.h' et '.hpp' du dossier courant
    et afficher le nombre total de lignes lues.
     
    Ce code fonctionne avec Python 3.6.4.
    L'analyse statique du code a été validée par mypy 0.570.
    """
     
    ###########
    # Imports #
    ###########
     
    import os, re, traceback
    from typing import Iterable, Pattern, Tuple
     
    #################################
    # Paths and regular expressions #
    #################################
     
    DIR_PATH: str = '.'
    CPP_FILE_NAME_REGEX: Pattern[str] = re.compile(r'^.*\.(cpp|h|hpp)$')
     
    #############
    # Main code #
    #############
     
    def _mainImpl() -> None:
    	cppLineCount: int = 0
    	for cppFilePath in getRecursiveChildrenCppFilePaths(DIR_PATH):
    		cppLineCount += countLinesInFile(cppFilePath)
    	print('Number of lines of C++ code: ' + str(cppLineCount) + '.')
     
    def getRecursiveChildrenCppFilePaths(dirPath: str) -> Iterable[str]:
    	for filePath, fileName in getRecursiveChildrenFilePathsAndNames(dirPath):
    		if isCppFileName(fileName):
    			yield filePath
     
    def getRecursiveChildrenFilePathsAndNames(dirPath: str) -> Iterable[Tuple[str, str]]:
    	for dirPath2, _, fileNames in os.walk(dirPath):
    		for fileName in fileNames:
    			filePath: str = os.path.join(dirPath2, fileName)
    			yield (filePath, fileName)
     
    def isCppFileName(name: str) -> bool:
    	return CPP_FILE_NAME_REGEX.match(name) is not None
     
    def countLinesInFile(filePath: str) -> int:
    	with open(filePath) as file:
    		return sum(1 for line in file)
     
    if __name__ == '__main__':
    	try:
    		_mainImpl()
    	except Exception as e:
    		print('Error: ' + str(e))
    		traceback.print_exc()
    	os.system('pause')
    Code Python : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
     
    """
    Parcourir récursivement les fichiers '.cpp', '.h' et '.hpp' du dossier courant
    et afficher le nombre total de lignes lues.
     
    Code testé sur les versions suivantes de Python :
    - 3.5.3 (avec PyPy) et
    - 3.6.4 (avec CPython).
    """
     
    ###########
    # Imports #
    ###########
     
    import os, re, traceback
     
    #################################
    # Paths and regular expressions #
    #################################
     
    DIR_PATH = '.'
    CPP_FILE_NAME_REGEX = re.compile(r'^.*\.(cpp|h|hpp)$')
     
    #############
    # Main code #
    #############
     
    if __name__ == '__main__':
    	try:
    		cppLineCount = 0
    		for dirPath, _, fileNames in os.walk(DIR_PATH):
    			for fileName in fileNames:
    				if CPP_FILE_NAME_REGEX.match(fileName) is not None:
    					cppFilePath = os.path.join(dirPath, fileName)
    					with open(cppFilePath) as cppFile:
    						for line in cppFile:
    							cppLineCount += 1
    		print('Number of lines of C++ code: ' + str(cppLineCount) + '.')
    	except Exception as e:
    		print('Error: ' + str(e))
    		traceback.print_exc()
    	os.system('pause')
    L'échantillon était faible (6 personnes, si je me souviens bien), mais une moitié trouvait le premier code plus lisible, tandis que l'autre moitié trouvait le deuxième code plus lisible.

    Donc la lisibilité est en partie subjective. Par contre, la première version est bien plus adaptée pour faire du réusinage de code.

    Concernant Isnull(Value) au lieu de Nz(Value, ""), je ne connais pas assez VBA pour juger. Je sais que certains langages comme PHP ont souvent des changements non rétrocompatibles, ce qui peut justifier d'ajouter des couches d'abstraction pour perdre moins de temps quand on passe d'une version à la suivante. Mais je ne sais pas ce qu'il en est de VBA.

  13. #53
    Membre éprouvé
    Homme Profil pro
    Intégrateur Web
    Inscrit en
    Août 2012
    Messages
    263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Intégrateur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2012
    Messages : 263
    Points : 1 040
    Points
    1 040
    Par défaut Il ne s'agit pas de faire du "beau code"
    Citation Envoyé par kilroyFR Voir le message
    Generalement les technos evoluent tellement vite que reecrire du code 'qui fonctionne' mais qui n'est pas 'beau' n'a que peu d'interet a part derouler des heures.
    (...)
    Apres c'est le propre du developpeur de toujours considérer que ce qu'ont fait les precédents etait moche, mal foutu et donc refaire une enieme fois a sa sauce.
    On est tous passé par là c'est la maladie du developpeur.
    (...)
    (En ce qui me concerne, en tout cas) Il ne s'agit pas de faire du "beau code", mais de faire du code concis, lisible, intelligible et performant... d'autant qu'il y a des chances que la prochaine personne qui doive intervenir ultérieurement sur ce code soit moi-même (et si c'est quelqu'un d'autre, il me remerciera), et quand j'ai divisé le poids des pages d'un site par cinq au cours d'une refonte, ce n'étais pas pour "faire beau".

    Bon, sans le web et sur des sites de petites dimensions, il est possible de repartir de zéro, ce n'est probablement pas le cas dans d'autres domaines où la base de code est trop importante.

    Concernant les "caprices" ou les "obsessions" des développeurs, que plusieurs commentaires ont évoqué, je conseille la lecture de l'article The care and feeding of software engineers (or, why engineers are grumpy) ou de sa traduction française, Soin et alimentation des ingénieurs informatique (ou pourquoi les ingénieurs sont grincheux)

    L'auteur y aborde le fait que les développeurs, qui sont des travailleurs hautement qualifiés, sont également des personnes créatives auxquelles on ne permet pas d'exprimer leur créativité et qu'on confine à des rôles d'exécutants, ce qui n'est pas une bonne chose, de surcroît si on les fait bosser sur du mauvais code.

    IL semble dès lors normal que ces devs veuillent réintroduire de la créativité dans leur boulot... mais pas au bon endroit.

    L'auteur propose donc de permettre aux devs d'exprimer leur créativité ailleurs que dans les projets de leur boite, dans des hack days, des hack weeks, du temps libre octroyé pour développer des projets persos, etc. etc.

    Vous en pensez quoi ?

    PS : Bon, comme je l'ai dit, moi, j'ai une (modeste) expérience dans l'inté web. Dans d'autres domaines, les contraintes sont sans doute différentes.

  14. #54
    Membre éprouvé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Août 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Août 2014
    Messages : 476
    Points : 1 042
    Points
    1 042
    Par défaut
    Citation Envoyé par sirthie Voir le message

    IL semble dès lors normal que ces devs veuillent réintroduire de la créativité dans leur boulot... mais pas au bon endroit.

    L'auteur propose donc de permettre aux devs d'exprimer leur créativité ailleurs que dans les projets de leur boite, dans des hack days, des hack weeks, du temps libre octroyé pour développer des projets persos, etc. etc.

    Vous en pensez quoi ?
    Ben avec le temps je me rends compte (on fait beaucoup de dev offshore - ile maurice; ils parlent francais et sont les moins chers; inde a venir) que le poste le plus important c'est architecte logiciel chez nous.
    On developpe en archi SOA micro services et du coup le dev proprement dit se reduit a des choses tres simples (automatisable souvent); donc on n'a pas besoin de gens creatifs ou bac+12. Des devs moyens suffisent largement. L'avantage etant qu'on en trouve facilement et pas cher (réalite du marché). Plus facile a gerer que des devs qui veulent jouer avec des technos ou se faire plaisir. Nos devs suivent des templates et rentrent tres facilement dedans. Oui ce sont de simples executants mais c'est ce type d'archi qui nous a permis de mettre en place ceci et il faut reconnaitre que c'est redoutablement efficace.
    L'archi du systeme reste du domaine de competence d'une poignées d'ingés.
    Et oui pour les creatifs qui ont envie de s'exprimer en essayant des technos et autres il y a plein de moyens pour cela (personnellement je fais du dev remunéré en dehors du taf et je separe donc bien mon activité professionnelle (archi/dev) de l'autre). Au taf je reste dans le cadre de ce qu'on a vendu/choisi et les POC et autres nouveautés je les teste dans mes heures persos a la maison. Lorsque c'est pertinent je propose a mon taf avec un POC qui prouve l'interet.
    Si c'est ok on integre dans archi et on industrialise; les devs utilisent sans se poser de questions.
    En 30 ans pour moi le metier de dev a ete devalorisé mais c'est comme ça.
    Dans l'archi retenue et notre façon de fonctionner on n'a plus besoin de kador pour sortir des logiciels. Meme des gens sortis tous frais de l'ecole sont de bons candidats . Ils ne coutent pas chers non plus du coup. On evite les caprices d'eventuels devs ce qui simplifie la gestion. Oui les devs sont des ouvriers chez nous (d'ailleurs ils travaillent dans une "unite de production logiciel" ce qui veut tout dire). Notre hierarchie a poussé a fond dans cette demarche (archi soa/micro service) car elle est ideale pour la sous traitance. C'est l'avenir c'est evident. D'ailleurs beaucoup s'y mettent et pas pour rien. Pour ceux qui n'y passent pas ce sont des refractaires au changement ou des gens qui s'assoient sur des acquis/postes qu'ils ne veulent pas lacher. SOA/Micro service ca a fait completement explosé notre organisation interne (et demoralisé beaucoup de gens qui ne se reconnaissaient pas dans cette organisation) mais au final c'est la boite qui est gagnante a tous les points de vue.

  15. #55
    Membre éprouvé
    Homme Profil pro
    Intégrateur Web
    Inscrit en
    Août 2012
    Messages
    263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Intégrateur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2012
    Messages : 263
    Points : 1 040
    Points
    1 040
    Par défaut À propos de la lisibilité...
    Citation Envoyé par Pyramidev Voir le message
    L'échantillon était faible (6 personnes, si je me souviens bien), mais une moitié trouvait le premier code plus lisible, tandis que l'autre moitié trouvait le deuxième code plus lisible.

    Donc la lisibilité est en partie subjective. Par contre, la première version est bien plus adaptée pour faire du réusinage de code.
    La lisibilité est une question complexe. Tout d’abord, la définition en est souvent floue/circulaire (lisibilité : qualité de ce qui est lisible), et le sens du mot varie selon l’objet auquel le mot renvoie (la lisibilité d’une carte géographique n’est pas la lisibilité d’un texte), et les synonymes et mots de sens proche abondent : intelligibilité, lecturabilité, compréhensibilité, appréhensibilité, appréhendabilité (liste non exhaustive).

    Il s’agit ici de textes ordinaires, et non de codes informatiques.

    En gros, dans le design web et la mise en page, et en matière de textes, les spécialistes de la question distinguent deux aspects de la chose :

    La lisibilité “physique”/“optique”/visuelle, qui repose sur des éléments physiques : dessin des caractères, taille des caractères, espacement des caractères, espacement des mots, hauteurs de ligne, longueur des lignes, nombre moyen de caractères par ligne, nombre moyen de lignes par paragraphes, contraste texte/fond, distance par rapport au support, luminosité du support, etc., etc.

    L’intelligibilité/lecturabilité/compréhensibilité/appréhensibilité/appréhendabilité, etc. d’un texte, qui est la capacité d’un texte à être compris le plus aisément possible, ce qui dépend de la familiarité des mots, de leur brièveté, de la non-ambiguïté de leur sens dans un contexte donné, de la syntaxe des phrases, de la longueur des phrases, du rapport nombre de mots/information, etc., etc.

    Ces éléments sont quantifiables et leur optimisation, qu’il s’agisse de ceux qui déterminent la lisibilité optique/visuelle d’un texte ou son intelligibilité/compréhensibilité produit généralement les mêmes effets (personne ne comprend mieux les phrases avec une syntaxe inhabituelle, de mots longs, et non familiers, polysémiques dans un contexte donné, etc., etc. que leurs équivalents avec une syntaxe classique, des mots, brefs, familiers, monosémiques dans un contexte donné, etc., etc.)

    Cependant, il y a des effets d’habitude et d’entrainement : un grand lecteur lira plus facilement des paragraphes longs qu’un lecteur lambda… mais il appréciera tout autant que ce dernier des paragraphes plus courts. Pour ma part, j’éprouve des difficultés à lire de livres disons imprimés avant les années 1970 car leurs caractères à empattement sont souvent trop étroits avec des déliés trop fins (dans le print, le support est limité et coûteux, et nombre de polices de texte “pré-web” ont des caractères plus étroits que des polices développées pour le web ; comparez une Times New Roman à une Georgia et une Arial à une Verdana).

    Question : les lecteurs contemporains des livres publiés dans les premières décennies du 20e siècle lisaient-ils ces livres aussi facilement que je lis des textes en Verdana parce qu’il y étaient habitués, ou pas ?

    Bref, tout ça pour dire qu’il y a une foule d’éléments objectifs et quantifiables de la lisibilité/intelligibilité, mais que la question est cependant complexe.

    Et donc, les gens qui trouvent plus lisibles les gros blocs de code trouvent-il la lisibilité de ces blocs meilleure en raison de facteurs objectivables/mesurables ou par effet d’habitude ou d’entrainement ?

  16. #56
    Membre éprouvé Avatar de 4sStylZ
    Homme Profil pro
    Null
    Inscrit en
    Novembre 2011
    Messages
    314
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Null
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2011
    Messages : 314
    Points : 1 056
    Points
    1 056
    Par défaut
    Citation Envoyé par JCD_31 Voir le message
    s ces fichues SSII, le cancer du paysage informatique français.
    Soit tu accepte le système full-controle et tu reste dans cette boite, soit tu décide de bosser dans un environnement différent (méthode agiles et compagnie).
    C’est pas un problème lié aux SSII, c’est un problème de méthode et de gestion de projet ton histoire.

    Mais je l’ai vécue.

  17. #57
    Membre extrêmement actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2015
    Messages
    1 104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 104
    Points : 2 573
    Points
    2 573
    Par défaut
    Citation Envoyé par JCD_31 Voir le message
    C'est pour ça que j'exècre de plus en plus ces fichues SSII, le cancer du paysage informatique français.
    Certes. Accuser nos ânes de SSII est un peu facile toutefois. Ce diagnostic est juste mais ne répond à aucune question. Pourquoi les SSII sont à ce point contraintes pas des délais intenables ? Pourquoi et comment les clients arrivent à ce point à contraindre les budgets, quitte à dépenser ensuite une fortune en maintenance (donc coûts futurs OPEX plus élevés) ? Pourquoi les chefs de produit, les commerciaux, les designers et les développeurs n'arrivent pas à travailler ensemble ? Pourquoi les grands comptes invoquent la prestation pour des jobs qui DOIVENT être internes car nécessitant une connaissance métier forte ? Le turn-over important sur un projet est-il seulement le reflet d'une politique RH à la rue des SSII (recrutement en très grande majorité de jeunes diplômés que l'on augmente jamais) ?
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  18. #58
    Membre averti
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 349
    Points : 439
    Points
    439
    Par défaut
    Citation Envoyé par kilroyFR Voir le message
    Ben avec le temps je me rends compte (on fait beaucoup de dev offshore - ile maurice; ils parlent francais et sont les moins chers; inde a venir) que le poste le plus important c'est architecte logiciel chez nous.
    On developpe en archi SOA micro services et du coup le dev proprement dit se reduit a des choses tres simples (automatisable souvent); donc on n'a pas besoin de gens creatifs ou bac+12. Des devs moyens suffisent largement. L'avantage etant qu'on en trouve facilement et pas cher (réalite du marché). Plus facile a gerer que des devs qui veulent jouer avec des technos ou se faire plaisir. Nos devs suivent des templates et rentrent tres facilement dedans. Oui ce sont de simples executants mais c'est ce type d'archi qui nous a permis de mettre en place ceci et il faut reconnaitre que c'est redoutablement efficace.
    L'archi du systeme reste du domaine de competence d'une poignées d'ingés.
    Et oui pour les creatifs qui ont envie de s'exprimer en essayant des technos et autres il y a plein de moyens pour cela (personnellement je fais du dev remunéré en dehors du taf et je separe donc bien mon activité professionnelle (archi/dev) de l'autre). Au taf je reste dans le cadre de ce qu'on a vendu/choisi et les POC et autres nouveautés je les teste dans mes heures persos a la maison. Lorsque c'est pertinent je propose a mon taf avec un POC qui prouve l'interet.
    Si c'est ok on integre dans archi et on industrialise; les devs utilisent sans se poser de questions.
    En 30 ans pour moi le metier de dev a ete devalorisé mais c'est comme ça.
    Dans l'archi retenue et notre façon de fonctionner on n'a plus besoin de kador pour sortir des logiciels. Meme des gens sortis tous frais de l'ecole sont de bons candidats . Ils ne coutent pas chers non plus du coup. On evite les caprices d'eventuels devs ce qui simplifie la gestion. Oui les devs sont des ouvriers chez nous (d'ailleurs ils travaillent dans une "unite de production logiciel" ce qui veut tout dire). Notre hierarchie a poussé a fond dans cette demarche (archi soa/micro service) car elle est ideale pour la sous traitance. C'est l'avenir c'est evident. D'ailleurs beaucoup s'y mettent et pas pour rien. Pour ceux qui n'y passent pas ce sont des refractaires au changement ou des gens qui s'assoient sur des acquis/postes qu'ils ne veulent pas lacher. SOA/Micro service ca a fait completement explosé notre organisation interne (et demoralisé beaucoup de gens qui ne se reconnaissaient pas dans cette organisation) mais au final c'est la boite qui est gagnante a tous les points de vue.


    Si tu travailles gratuitement chez toi pour que ton patron s'enrichisse, pas étonnant que le métier se dévalorise!

    Je pense que ça dépend des pays:
    Ayant travaillé dans les 2 pays, France et Canada, les développeurs sont généralement mieux traité/payé au Canada.


    Et de ce que j'entends souvent ces derniers temps, beaucoup d'entreprises reviennent de l'offshore car très mauvaise qualité, mauvaise communication, différence d'heures ... ce qui au final revient plus cher.

  19. #59
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par champomy62 Voir le message
    (.../...)

    Et de ce que j'entends souvent ces derniers temps, beaucoup d'entreprises reviennent de l'offshore car très mauvaise qualité, mauvaise communication, différence d'heures ... ce qui au final revient plus cher.
    J'entendais déjà ce refrain en 2008, avec un assureur qui s'était planté sur une refonte comptable en Inde et qui avait dit "plus jamais". Mais tu as 2 trucs qui contrebalancent. En (1), des projets correctement pilotés depuis la métropole peuvent fonctionner. C'est rare, mais ça existe, et le premier décideur venu qui se croit compétent veut pouvoir dire "moi aussi". En (2), la plupart des décideurs valsent à droite à gauche au gré des opportunités, et n'ont pas ce niveau de retour d'expérience. C'était moins cher à l'achat, donc ils vont le refaire. Ils n'ont pas souffert des couts de maintenance(ils étaient déjà parti ailleurs pour plus de pognon),donc ils continuent à croire que c'est une bonne idée(ça l'est parfois,mais pas quand eux sont aux commandes).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  20. #60
    Membre expérimenté
    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2016
    Messages
    373
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Septembre 2016
    Messages : 373
    Points : 1 335
    Points
    1 335
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Étant donné ta description, je n'ai pas l'impression que ce développeur ait volontairement codé de manière à rendre plus difficile la maintenance du code par ses successeurs.

    En ce qui concerne le découpage, certains développeurs lisent plus facilement du code découpé en sous-fonctions et d'autres lisent plus facilement des pavés.

    Donc la lisibilité est en partie subjective. Par contre, la première version est bien plus adaptée pour faire du réusinage de code.
    On est d'accord, et je suis effectivement plus fan de la seconde version.
    Cependant la première version ici est aussi simple à lire car dans le même fichier.

    Par contre si chaque fonction était dans des fichiers différents perdu au milieux d'un tas d'autre fonction qui n'ont rien à voir, le fils serait beaucoup plus complexe à suivre. Ajoute à ça des noms qui ne sont pas clairement bien définie. Sa devient beaucoup moins gérable et cela même pour des personnes qui préfère ce type de code.


    Citation Envoyé par Pyramidev Voir le message
    Concernant Isnull(Value) au lieu de Nz(Value, ""), je ne connais pas assez VBA pour juger. Je sais que certains langages comme PHP ont souvent des changements non rétrocompatibles, ce qui peut justifier d'ajouter des couches d'abstraction pour perdre moins de temps quand on passe d'une version à la suivante. Mais je ne sais pas ce qu'il en est de VBA.
    J'ai mal citer l'exemple ici, le nom réellement employer est IsNullable(Value) qui termine au bout de la deuxième sous fonction à un Nz(Value, "").
    Après effectivement vue sous cet angle, je comprend mieux la logique car VBA comme tout langage évolue et il arrive que certaine fonction finissent par disparaitre, même si c'est à moindre échelle comparer à d'autre langage.
    Mais pourquoi ajouter deux couches supplémentaire pour vérifier si la variable est vide puis si elle est null avant de l'envoyer dans une fonction de base qui fait exactement la même chose ?

    En tout cas merci pour cet échange de point de vue, ça permet aussi de prendre du recul !

Discussions similaires

  1. Mac OS X second OS le plus utilisé par les développeurs aux USA
    Par Hinault Romaric dans le forum Mac OS X
    Réponses: 21
    Dernier message: 17/08/2011, 22h58
  2. L'API de Facebook la plus détestée par les développeurs
    Par Idelways dans le forum APIs Réseaux sociaux
    Réponses: 8
    Dernier message: 17/08/2011, 09h55
  3. L'API de Facebook la plus détestée par les développeurs
    Par Idelways dans le forum Actualités
    Réponses: 0
    Dernier message: 12/08/2011, 00h57
  4. Réponses: 8
    Dernier message: 30/08/2009, 11h19
  5. Réponses: 8
    Dernier message: 10/06/2007, 01h43

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