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

Affichage des résultats du sondage: Quelles sont les habitudes de programmation qui caractérisent un bon développeur ?

Votants
198. Vous ne pouvez pas participer à ce sondage.
  • Coder intensivement

    22 11,11%
  • Écrire du code simple et être à l’affût de simplifications

    165 83,33%
  • Ne pas optimiser le code au début

    63 31,82%
  • Se concentrer sur la tâche la plus importante

    53 26,77%
  • Tout documenter et commenter

    65 32,83%
  • Faire des pauses régulièrement

    57 28,79%
  • Maîtriser parfaitement ses outils

    58 29,29%
  • Utiliser les lignes de commandes plutôt que les interfaces graphiques

    22 11,11%
  • Écrire du code lisible et compréhensible

    154 77,78%
  • Lire les codes source des projets

    44 22,22%
  • Utiliser un EDI performant

    37 18,69%
  • Corriger les bogues avant d’ajouter de nouvelles fonctionnalités

    81 40,91%
  • Écrire des tests unitaires

    88 44,44%
  • Taper sur Google et être actif sur les forums techniques

    40 20,20%
  • Suivre régulièrement les technologies utilisées et leurs alternatives

    71 35,86%
  • Parcourir toute la documentation

    26 13,13%
  • Autres (à préciser dans les commentaires)

    11 5,56%
  • Pas d'avis

    1 0,51%
Sondage à choix multiple
Débats sur le développement - Le Best Of Discussion :

Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 874
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 874
    Points : 86 891
    Points
    86 891
    Billets dans le blog
    2
    Par défaut Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ?
    Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ?
    Expliquez les avantages que vous en avez tirés

    Dans chaque projet de développement informatique, il y a une finalité, celle de livrer une solution fonctionnelle qui répond au moins aux exigences définies dès le départ ou ajoutées au cours du développement. L’atteinte de cet objectif dépend, entre autres éléments, des compétences développées et de l’expérience acquise au fil de temps. Chaque développeur peut se caractériser par une manière singulière de travailler qui inclut de petites astuces, pratiques ou habitudes qui lui permettent d’aller plus ou moins vite et de livrer un travail d’une certaine qualité.

    En fonction de ses habitudes de programmation, un développeur peut gagner plus ou moins en efficacité et en productivité. La liste est certainement plus longue, mais on peut citer entre autres les habitudes suivantes :

    • coder intensivement ;

    • écrire du code simple et être à l’affût de simplifications ;

    • ne pas chercher à optimiser le code au début : écrire d’abord un code fonctionnel et l’optimiser quand cela sera nécessaire. Ne pas chercher à préoptimiser le code en vue de faire face à toutes sortes de scénarios qui pourraient se produire ;

    • se concentrer sur la tâche la plus importante ;

    • tout documenter et commenter ;

    • faire des pauses régulièrement ;

    • maîtriser parfaitement ses outils : les outils que vous utilisez régulièrement ne doivent pas avoir de secret pour vous ;

    • utiliser les lignes de commandes plutôt que les interfaces graphiques (GUI) ;

    • écrire du code lisible et compréhensible, cela inclut par exemple la définition et le respect de règles de nommage ;

    • lire les sources des projets : vous pouvez commencer à résoudre des problèmes simplement en vous souvenant d’une solution que vous avez vue ailleurs. Vous pouvez donc profiter de la disponibilité des codes source des projets GNU/Linux pour les télécharger afin de pouvoir y jeter un coup d’œil ;

    • utiliser un IDE performant ;

    • corriger les bogues avant d’ajouter de nouvelles fonctionnalités ;

    • écrire des tests unitaires ;

    • taper sur Google et être actif sur les forums techniques ;

    • veille technologique : suivre régulièrement les technologies utilisées et leurs alternatives ;

    • parcourir toutes les documentations : il ne s’agit pas d’apprendre des choses en profondeur, mais se faire juste une idée de ce qui est possible. Ainsi, lorsque vous êtes face à un problème, vous pouvez déjà avoir une piste sur les solutions possibles et retourner dès ce moment à la documentation pour plus de détails sur la mise en œuvre de la solution.


    Il s’agit d’un sondage à choix multiples dont le but est de savoir quelles sont les petites habitudes qui permettent le plus à un développeur d’être plus efficace et plus productif. Nous nous intéressons également aux avantages que celles-ci apportent aux développeurs. Mais n’hésitez pas non plus à dire dans les commentaires, si vous l’estimez, pourquoi l’un des éléments cités ci-haut ne permet pas aux développeurs d’être plus efficaces et plus productifs.

    Et vous ?

    Quelles sont les petites habitudes de programmation qui peuvent faire de vous un bon développeur ?
    Expliquez les avantages que vous en avez tirés.
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 459
    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 459
    Points : 6 060
    Points
    6 060
    Par défaut
    Bonjour,

    Mes remarques point par point :
    • coder intensivement
      Selon le dictionnaire de l'Académie française, 9e édition, intensif signifie Dont l'importance, le rendement, l'efficacité sont portés au-delà de la mesure ordinaire par des efforts, des moyens particuliers. Tautologiquement, oui, coder efficacement en faisant des efforts est efficace, mais ce n'est pas une information. Donc je n'ai pas coché ce point.
    • écrire du code simple et être à l’affût de simplifications
      C'est une bonne pratique. Le code sera plus vite compris donc plus facilement maintenu.
    • ne pas chercher à optimiser le code au début : écrire d’abord un code fonctionnel et l’optimiser quand cela sera nécessaire. Ne pas chercher à préoptimiser le code en vue de faire face à toutes sortes de scénarios qui pourraient se produire
      Ça dépend de quelles optimisations on parle. Je suis pour les optimisations quand elles ne gênent ni la compréhension, ni la maintenance. J'ai vu trop souvent des vector là où la bonne structure de données aurait été une table de hachage.
    • se concentrer sur la tâche la plus importante
      Je l'aurais reformulé en savoir prioriser les tâches. Quand on n'a pas le temps de tout faire dans les temps, c'est une compétence utile. Mais ce choix n'appartient pas toujours aux développeurs. La hiérarchie impose ses priorités.
    • tout documenter et commenter
      C'est dommage que le mot tout apparaisse car cela incite moins à cocher ce point. Je le coche quand même parce que j'ai vu trop souvent des développeurs qui ne documentaient rien et qui ne commentaient presque jamais alors qu'ils en avaient l'occasion, même si la hiérarchie avait en partie une responsabilité là dessus en favorisant l'augmentation de la dette technique.
    • faire des pauses régulièrement
      Cela dépend du rythme de travail et de la personne.
    • maîtriser parfaitement ses outils : les outils que vous utilisez régulièrement ne doivent pas avoir de secret pour vous
      Il me semble important de bien connaître le langage de programmation que l'on utilise et de savoir ce que permettent de faire les bibliothèques que l'on utilise.
      Mais les outils au sens large peuvent avoir beaucoup de fonctionnalités qu'on n'utilise pas, donc je n'ai pas coché ce point.
    • utiliser les lignes de commandes plutôt que les interfaces graphiques (GUI)
      Gné ? A quoi ça sert ?
    • écrire du code lisible et compréhensible, cela inclut par exemple la définition et le respect de règles de nommage
      Oui. Le code sera plus vite compris donc plus facilement maintenu. Déjà évoqué ci-dessus.
    • utiliser un IDE performant
      Ce choix n'appartient pas toujours au développeur. Par exemple, j'ai déjà subi C++ Builder.
    • lire les sources des projets : vous pouvez commencer à résoudre des problèmes simplement en vous souvenant d’une solution que vous avez vue ailleurs. Vous pouvez donc profiter de la disponibilité des codes source des projets GNU/Linux pour les télécharger afin de pouvoir y jeter un coup d’œil
      Je n'ai pas lu attentivement de code source de projets open source, donc je ne me prononcerai pas sur ce point.
    • corriger les bogues avant d’ajouter de nouvelles fonctionnalités
      Oui. Mais ce choix n'appartient pas toujours aux développeurs. La hiérarchie impose ses priorités.
    • écrire des tests unitaires
      Oui. D'ailleurs, j'ai vu trop souvent des développeurs ne pas savoir ce qu'étaient des tests unitaires. Mais, personnellement, je pense que c'est moins prioritaire que la documentation.
    • taper sur Google et être actif sur les forums techniques
      Google n'est pas le seul moteur de recherche et les forums techniques ne sont qu'une source de savoir parmi d'autres. Donc je n'ai pas coché ce point. J'aurais reformulé ce point en se former continuellement. Dans ce cas, j'aurais coché.
    • veille technologique : suivre régulièrement les technologies utilisées et leurs alternatives
      Oui.
    • parcourir toutes les documentations : il ne s’agit pas d’apprendre des choses en profondeur, mais se faire juste une idée de ce qui est possible. Ainsi, lorsque vous êtes face à un problème, vous pouvez déjà avoir une piste sur les solutions possibles et retourner dès ce moment à la documentation pour plus de détails sur la mise en œuvre de la solution.
      Il y a encore le mot toutes qui me gêne. Dans mon expérience, oui, lire le peu de doc existant était une bonne idée. Il y a plusieurs fois où on m'a demandé de développer un truc alors qu'il était déjà implémenté.


    J'ajoute aussi :
    • chercher activement des informations sur le besoin
      Sinon, on risque d'implémenter un truc qui ne correspond pas au besoin.
    • limiter la taille des fonctions
      J'ai vu plusieurs fonctions qui dépassaient les 1000 lignes et il était difficile de les analyser.
    • factoriser le code
      Et éviter les copier-collers. Par exemple, une fois, j'ai vu un copié-collé d'une fonction de 1500 lignes.
      De plus, dans une même entreprise, quand plusieurs applications sont écrites dans le même langage, il vaut mieux qu'il existe un code commun plutôt que chaque application réimplémente la même chose à sa sauce. Cela demande de la communication entre développeurs.
    • communiquer avec les autres développeurs
      Voir le point précédent.
    • écrire du code facile à déboguer pas à pas
      Par exemple, en C++, le code
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      int entier1 = uneFonctionQuiRetourneUnEntier(param1);
      int entier2 = uneFonctionQuiRetourneUnEntier(param2);
      int entier3 = uneFonctionQuiRetourneUnEntier(param3);
      if(entier1 + entier2 < entier3)
          doSomething();
      sera plus facile à déboguer pas à pas que :
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      if(uneFonctionQuiRetourneUnEntier(param1) + uneFonctionQuiRetourneUnEntier(param2) < uneFonctionQuiRetourneUnEntier(param3))
          doSomething();

  3. #3
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 626
    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 626
    Points : 10 542
    Points
    10 542
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    • utiliser les lignes de commandes plutôt que les interfaces graphiques (GUI)
      Gné ? A quoi ça sert ?
    Il y a 2 approches

    La première c'est de coder en "quick and dirty" en loguant (console/ fichier/ réseau) tout un tas de choses.
    Par exemple pour un programme réseau, faire une GUI pour afficher les trames réponses et leurs analyses cela demande du temps.
    Et en plus, souvent tu ne vas pas pouvoir intégrer cette GUI "debug" dans le "programme final" (si ce dernier est une GUI) (à moins que tu fasses une GUI 2 en 1 avec une très bonne séparation pour passer de l'1 vers l'autre)

    La deuxième approche, c'est une amélioration de la première. Parce que tu as tout fait en "quick and dirty", mais tu veux que l'affichage soit plus lisible, tu veux plus d'options, ...
    Tu vas greffer une ligne de commande avec des bascules ...
    Mais cela demande du temps (à moins que tu l'as déjà fait 1 fois).

    Mais quelque soit l'approche, ta ligne de commande sera [quasi] portable (au code O.S. spécifique), un exécutable léger sans dépendance (je sais les courriels font plus de 20 Mo, tout le monde à DropBox, ...).


    Et en plus , si tu as bien fait ta ligne de commande (qui doit être la compagnon du code bas niveau), le "programme final" va être la couche au dessus.


    Édit: On peut voir cette ligne de commande aussi comme du test, puisque si elle bien faite, elle t'affichera l'erreur ou le problème le plus précisément possible.
    Dans le "programme final", souvent on va devoir masquer les erreurs par des erreurs génériques.


    Citation Envoyé par Pyramidev Voir le message
    Voir le point précédent.[*]écrire du code facile à déboguer pas à pas
    Par exemple, en C++, le code
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    int entier1 = uneFonctionQuiRetourneUnEntier(param1);
    int entier2 = uneFonctionQuiRetourneUnEntier(param2);
    int entier3 = uneFonctionQuiRetourneUnEntier(param3);
    if(entier1 + entier2 < entier3)
        doSomething();
    sera plus facile à déboguer pas à pas que :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    if(uneFonctionQuiRetourneUnEntier(param1) + uneFonctionQuiRetourneUnEntier(param2) < uneFonctionQuiRetourneUnEntier(param3))
        doSomething();
    Pas d'accord dans ton exemple "lisible" tu as une ligne de plus 80 - 100 lignes en omettant les accolades ouvrantes/fermantes (je l'ai met toujours).

    Édit: j'ai lu ta remarque à l'envers

  4. #4
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 459
    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 459
    Points : 6 060
    Points
    6 060
    Par défaut
    foetus,
    On n'a pas interprété utiliser les lignes de commandes plutôt que les interfaces graphiques (GUI) de la même manière.
    Je l'avais compris comme, par exemple, utiliser SVN en ligne de commande au lieu d'utiliser un logiciel comme Tortoise SVN.
    Par contre, pour un outil que l'on code soi-même, j'entends qu'on n'a pas toujours le temps de coder une interface graphique, ce qui, de toute façon, n'est pas incompatible avec le fait de pouvoir utiliser l'outil directement en ligne de commande.

    Citation Envoyé par foetus Voir le message
    Pas d'accord dans ton exemple "lisible" tu as une ligne de plus
    Ce n'est pas une question de lisibilité.
    Dans mon exemple avec if(entier1 + entier2 < entier3), quand on arrive à cette ligne, on peut connaître directement la valeur de ces trois entiers, par exemple en passant la souris dessus (avec un bon débogueur).
    Par contre, dans mon autre exemple avec if(uneFonctionQuiRetourneUnEntier(param1) + uneFonctionQuiRetourneUnEntier(param2) < uneFonctionQuiRetourneUnEntier(param3)), pour connaître les valeurs des entiers retournés, il faut entrer dans la fonction, ce qui est moins pratique.

  5. #5
    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 044
    Points
    32 044
    Par défaut
    J'ai voté pour 3 grands classiques, on dirait : coder aussi simple que possible, coder aussi lisible que possible, et faire des tests unitaires. Ce que Kathy Sierra appelle du Girl Code.
    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.

  6. #6
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Et vous ?

    Quelles sont les petites habitudes de programmation qui peuvent faire de vous un bon développeur ?
    Expliquez les avantages que vous en avez tirés.
    Ne pas utilisez que des modèles ou méthodes enseignés lors de formations ou études. Chose qui n'est pas apprécié mais ouvre des types d'usages quelques peu différentes.

    Exemple d'exploitation de middleware, la liaison entre une base de données et "son interface graphique" via un réseau ou 127.0.0.1, interface généré automatiquement parce que le modèle d'interface est inclus à la base de données avec les modèles informations.

    La seule fois où j'ai voulu appliquer, cela j'ai réussi à intrigué les puristes du tutoriel.
    Dernière modification par dourouc05 ; 13/06/2016 à 10h03.

  7. #7
    Membre habitué Avatar de bclinton
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    47
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 47
    Points : 152
    Points
    152
    Par défaut
    Écrire du code simple et compréhensible.

    Bien gérer les cas d'erreur (exceptions...).

    Écrire des tests unitaires.

    Utiliser un gestionnaire d'intégration continue et suivre les indicateurs quotidiennement (sonar, jenkins).

    Ne pas hésiter à se remettre en question (refactoring, évolutions techniques)

  8. #8
    Membre émérite
    Avatar de VivienD
    Homme Profil pro
    Développeur logiciel
    Inscrit en
    Octobre 2009
    Messages
    523
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Développeur logiciel
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Octobre 2009
    Messages : 523
    Points : 2 278
    Points
    2 278
    Par défaut
    À mon sens, il manque un choix dans la liste, et pourtant! je trouve que c'est LA qualité essentielle à tout développeur: je veux parler de l'organisation. En effet, ça ne sert d'essayer de concevoir ou de coder un projet, si on ne se montre pas un tant soit peu structuré(e) dans son travail; sinon ça part dans tous les sens et une bonne partie des modules, si ce n'est la majorité, reste bloquée à l'état d'ébauche bancale, du moins dans le meilleur des cas.

    Malheureusement, il m'arrive de me disperser, donc le fait que ça peut partir dans tous les sens puis en sucette ne m'est pas inconnu, loin s'en faut...
    De retour, plus sportif mais toujours aussi moche.
    _____________
    Pro: Programmation en C/C++ (embarqué ou non)
    Loisir: Programmation en C++11/14/17 avec la STL ou Qt 5

  9. #9
    Membre confirmé

    Profil pro
    Développeur .NET
    Inscrit en
    Août 2004
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Août 2004
    Messages : 178
    Points : 645
    Points
    645
    Par défaut
    Privilégiez d'abord des qualités humaines avant la technique: curiosité et communication.

    Car un projet informatique est avant tout une discussion entre humain avant d'être une discussion entre ordinateurs...

    Sans ça, même avec un bagage technique conséquent, vous pouvez toucher une cible oui. Mais sera-t-elle la bonne cible ?

  10. #10
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    En utilisant un coding standard avec la concertation de l'équipe.

    L'inconvénient d'un bon développeur c'est qu'il est facilement remplaçable, une personne programmant et indentant n'importe comment et sans commentaire, créant ces propres outils maisons/bibliothèques au lieu d'utiliser des bibliothèques existante et "universelle", c'est plus facile ensuite pour négocier une augmentation

    utiliser un IDE performant
    Je dirais plutôt utiliser un ordinateur performant, Visual Studio et mon IDE préférer mais je dirais pas qu'il est performant, il est très lourd (plus de 15Go) et peut être long à démarrer si t'as pas un I5, 8Go de ram et un SSD.
    Les développeurs avec de mauvais outils (un Pentium ou un celeron avec 2-4Go de ram) sa existe encore malheureusement.

  11. #11
    Membre confirmé
    Avatar de vinmar
    Homme Profil pro
    Développeur Web
    Inscrit en
    Août 2012
    Messages
    139
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Service public

    Informations forums :
    Inscription : Août 2012
    Messages : 139
    Points : 516
    Points
    516
    Par défaut
    Le bon développeur, il va coder, il va tester unitairement et il va commiter. Le mauvais développeur... il va coder, il va tester et il va commiter... mais c'est un mauvais développeur.

    Donc :
    1. Ecrire du code simple et lisible et être à l’affût de simplifications (+commentaires, etc).
    2. Ecrire des tests unitaires.
    3. Avoir un environnement d'intégration continue.
    M. Lebowski : Avez-vous un emploi, monsieur ?
    Le Duc : Un emploi ?
    M. Lebowski : Ne me dites pas que vous cherchez un emploi dans cette tenue un jour de semaine ?
    Le Duc : Un jour de… Quel jour on est ?

  12. #12
    En attente de confirmation mail
    Homme Profil pro
    Chef de projet
    Inscrit en
    Décembre 2005
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chef de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2005
    Messages : 24
    Points : 58
    Points
    58
    Par défaut
    J'ai voté autre (et d'autres points également): organisation et communication.

    Il faut penser à l'organisation de son travail/code, de l'équipe et du travail de l'équipe, la communication est également très importante (voir essentielle).

  13. #13
    Membre régulier
    Profil pro
    Spleen
    Inscrit en
    Mai 2013
    Messages
    78
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Spleen

    Informations forums :
    Inscription : Mai 2013
    Messages : 78
    Points : 89
    Points
    89
    Par défaut
    Fruit d'une formation aride et technique... nous retrouvons des solutions arides et techniques... logique.
    Avec l'expérience, c'est surtout la qualité des échanges qui fait avancer les projets, le pair programming, la revue de code, synchro avec les besoins clients, savoir dire "ton code j'y comprends rien", "refaisons cette merde c'est inbitable"

    Tout documenter et commenter => complètement idiot. À NE JAMAIS FAIRE. Le chapeau et rapidement ce que font les méthodes/fonctions. Une partie du code retord (pas par sa complexité algorithmique mais par les concepts qu'elles soulèvent derrière)
    Parcourir toute la documentation => grosse perte de temps. Je vire celui qui me fait ça. Il ne sait pas gérer son temps.

  14. #14
    Membre averti
    Avatar de mrqs2crbs
    Profil pro
    LEAD DEV
    Inscrit en
    Juin 2013
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : LEAD DEV

    Informations forums :
    Inscription : Juin 2013
    Messages : 105
    Points : 398
    Points
    398
    Billets dans le blog
    2
    Par défaut autonomie
    salut à tous,

    j'ai répondu au questionnaire avec une autre question en tête :
    "qu'est-ce qui me fait le plus progresser comme développeur?"

    pour ma part c'est la curiosité: tester et apprendre de nouvelles technos, d'autres paradigmes, lire le code des autres, ...

    Maintenant pour revenir à la question d'origine, je me la suis posée lorsque l'on prend des stagiaires dont j'ai la charge.
    et au final ce qui est complétement rédhibitoire, c'est le manque d'autonomie:
    quelqu'un qui va vouloir se faire aider sans essayer de chercher la solution par soi même, ça ne marchera pas

    au final, je dirais que le bon développeur doit-être :
    - relativement autonome,
    - et doit pratiquer une veille assidu.

    Cordialement

  15. #15
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2014
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2014
    Messages : 6
    Points : 14
    Points
    14
    Par défaut Communication
    Citation Envoyé par Pyramidev Voir le message
    Bonjour,
    [*]communiquer avec les autres développeurs
    Dommage que celui ci ne fasse pas partie de la liste car c'est certainement le plus important, d'autant plus que sans la communication, la factorisation du code est impossible puisque chacun redéveloppe la fonctionnalité dont il a besoin dans son coin.

  16. #16
    Membre du Club Avatar de dom_beau
    Homme Profil pro
    Développeur scientifique
    Inscrit en
    Août 2013
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur scientifique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2013
    Messages : 10
    Points : 57
    Points
    57
    Par défaut Trois points importants...
    Allô!

    Je peux voir trois points importants:

    1) Documenter le code.
    2) Documenter le code.
    3) Documenter le code.

    Tout le reste, aussi bien le développement de tests unitaires, l'utilisation d'un bon IDE ou la communication à l'intérieur de l'équipe ne relève pas du programmeur mais du gestionnaire.

    Mais ce n'est qu'un avis personnel, je ne prétends pas à la vérité...

  17. #17
    Membre éclairé
    Homme Profil pro
    Inscrit en
    Juin 2010
    Messages
    319
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Juin 2010
    Messages : 319
    Points : 843
    Points
    843
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Ne pas chercher à préoptimiser le code en vue de faire face à toutes sortes de scénarios qui pourraient se produire
    Je suggérerai plutôt de mettre :
    Ne prendre en compte que les scénarii identifiés et utilisés par l'utilisateur.

    Rien ne sert en effet de prendre en compte les cas sensés être improbable et résultant d'une utilisation délibérément mauvaise. Sauf s'il y a une stratégie voulue par l'entreprise (réputation / robustesse / ...) ou d'une question de sécurité, comme la construction de requête SQL à partir de formulaires.
    "Donnez un poisson à un Homme, et il mangera un jour. Apprenez-lui à pêcher, et il mangera tous les jours."

  18. #18
    Membre confirmé
    Inscrit en
    Octobre 2005
    Messages
    239
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 239
    Points : 539
    Points
    539
    Par défaut Non
    Citation Envoyé par dom_beau Voir le message
    Allô!

    Je peux voir trois points importants:

    1) Documenter le code.
    2) Documenter le code.
    3) Documenter le code.

    Tout le reste, aussi bien le développement de tests unitaires, l'utilisation d'un bon IDE ou la communication à l'intérieur de l'équipe ne relève pas du programmeur mais du gestionnaire.

    Mais ce n'est qu'un avis personnel, je ne prétends pas à la vérité...
    Documenter les méthodes oui.

    Par contre si tu passes ton à documenter tout ton code, c'est que potentiellement plusieurs choses ne vont pas :
    - Tes méthodes sont trop longues (complexité)
    - Ton code est peu lisible (mauvais nommage des variables, trop de boucles...)

  19. #19
    Membre confirmé
    Inscrit en
    Octobre 2005
    Messages
    239
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 239
    Points : 539
    Points
    539
    Par défaut
    Personnellement (j'insiste) et par expérience,
    je trouve que les tests unitaires automatisés peuvent être utiles mais à petit dose car ils souffrent à mon sens de gros points négatifs :
    - Chronophage (peut-être plus longs à écrire que l'appli elle-même).
    - Complexe à écrire (en tout cas PHPUnit c'est chiant :p).
    - Peut allégrement servir de cache misère ("ah ben non nos tests unitaires sont bons").
    - Ne reflète pas, mais alors pas du tout, la qualité intrinsèque du code.

    Si on maitrise vraiment le langage et qu'on teste vraiment unitairement ce qu'on fait, on ne devrait pas avoir besoin d'écrire des tests unitaires (techniques en tout cas) supplémentaire.

  20. #20
    Membre actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juin 2011
    Messages
    95
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2011
    Messages : 95
    Points : 264
    Points
    264
    Par défaut
    Bonjour à tous,

    Je trouve que tous ces arguments sont sensés (sauf un), mais après cela reste une question de point de vue : je connais des gens très bons n'étant pas actifs sur les forums techniques (je ne m'estime pas exceptionnel techniquement, et je suis justement peu actif, je devrais l'être plus...), je connais des gens ayant des années d'expériences en .NET sans maîtriser les bases du Framework (LINQ, si tu me regardes ), etc.

    On connait tous des personnes qui s'identifieront à ces points. Le point qui me dérange le plus est le premier, "Coder intensivement". Comment interpréter "intensivement"? Pour moi la programmation est une passion, à partir de là il a pas une notion d'intensif vu qu'il y a pas une notion d'effort, même lorsque je code jusque 1h du matin. Certains peuvent coder 7h30 par jour, d'autres 12h, ce n'est pas ça qui fait un bon développeur, avec l'effet burn-out. Et inversement, quand je code c'est pour un besoin (suivre mon traitement médical, faire un logiciel pour les études de ma copine, etc). Comment on peut développer intensivement sans but? En rejoignant X projets? ...

    Il ne faut pas oublier notre passion, et se ménager je pense (après, ce n'est que mon avis, je n'ai pas la science infuse! )

Discussions similaires

  1. Quelles sont les phases d'un programme?
    Par patchi225 dans le forum Débuter
    Réponses: 3
    Dernier message: 01/07/2011, 18h33
  2. [TASM] Quelles sont les erreurs dans ce programme ?
    Par S.H dans le forum x86 16-bits
    Réponses: 7
    Dernier message: 25/12/2007, 23h05
  3. quelles sont les SSII qui font du forfait
    Par coax81 dans le forum SSII
    Réponses: 11
    Dernier message: 12/10/2007, 15h49
  4. Réponses: 6
    Dernier message: 03/07/2007, 11h34

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