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

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

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

    162 83,08%
  • Ne pas optimiser le code au début

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

    53 27,18%
  • Tout documenter et commenter

    64 32,82%
  • Faire des pauses régulièrement

    57 29,23%
  • Maîtriser parfaitement ses outils

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

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

    151 77,44%
  • Lire les codes source des projets

    44 22,56%
  • Utiliser un EDI performant

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

    80 41,03%
  • Écrire des tests unitaires

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

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

    69 35,38%
  • Parcourir toute la documentation

    25 12,82%
  • Autres (à préciser dans les commentaires)

    11 5,64%
  • Pas d'avis

    1 0,51%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 4 sur 4 PremièrePremière 1234
  1. #61
    Membre chevronné
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    447
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 447
    Points : 1 960
    Points
    1 960

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Ce que j'ai pas mal pratiqué en bancaire, ce sont des traitements par nature très linéaires, ou tu fais des choses au kilomètre, que tu ne fais nulle part ailleurs, et qui sont juste en séquence. Il y a zéro valeur ajoutée à découper tout ça en rondelles.
    La valeur ajoutée serait de pouvoir faire plus facilement des grands sauts quand on débogue pas à pas.

    Au lieu de faire :
    "scroll, scroll, scroll, scroll, scroll, scroll, scroll, scroll, scroll, scroll, ajouter un point d'arrêt, avancer l'exécution jusqu'à ce point d'arrêt",
    il suffit de faire :
    "pas à pas sortant, avancer un peu, pas à pas entrant, avancer un peu".

    Remarque : A la place du scroll, on peut parfois faire Ctrl+F et entrer une chaîne qui va nous amener là où on veut mettre un point d'arrêt, mais ça suppose que l'on connaît déjà le code suffisamment bien pour savoir quelle chaîne rechercher.

  2. #62
    Membre éprouvé
    Profil pro
    Inscrit en
    avril 2004
    Messages
    653
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations forums :
    Inscription : avril 2004
    Messages : 653
    Points : 938
    Points
    938

    Par défaut savoir exactement ce que je veux faire

    L'entrée qui manque dans le sondage (trop évident peur-être) est : savoir exactement ce que je veux faire. Et donc commencer par l'écrire en français. Puis écrire en dessous les grandes étapes, puis les subdiviser en petites étapes, ajouter les détails essentiels (d'où je pars, où je vais). Quand cela est fait et stable, il est beaucoup plus facile de développer chaque ligne de commentaire en code (quelques dizaines de lignes max). Et il est aussi facile de maintenir le programme.
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  3. #63
    Membre à l'essai
    Homme Profil pro
    Responsable d'exploitation informatique
    Inscrit en
    mars 2015
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Responsable d'exploitation informatique
    Secteur : Transports

    Informations forums :
    Inscription : mars 2015
    Messages : 5
    Points : 12
    Points
    12

    Par défaut Rendre une procédure la plus universelle possible

    Lorsque je développe un logiciel, je ressens toujours une grande satisfaction lorsque j'écris des procédures qui peuvent s'appliquer à presque n'importe quel logiciel. Bien sût cette universalité est relative au champ d'application. Par exemple une procédure pour la gestion de l'affichage à l'écran peut être utilisée dans n'importe quel logiciel dans les capacités limites de cet affichage. Les procédures souvent universelles sont des solutions mathématiques. Mais les procédures en lien avec la réalité humaine comme la gestion et l'administration sont plus difficiles à rendre universelles car il y a tellement de possibilités, et souvent on arrive pas à tout prévoir au moment de la conception. Quoiqu'il en soit, construire des procédures le plus universelles possibles est l'une des caractéristiques qui contribuent à faire de la programmation un outil puissant.

  4. #64
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    1 700
    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 : 1 700
    Points : 6 733
    Points
    6 733

    Par défaut

    Citation Envoyé par progfun Voir le message
    Quoiqu'il en soit, construire des procédures le plus universelles possibles est l'une des caractéristiques qui contribuent à faire de la programmation un outil puissant.
    Si et seulement si tu références tes procédures "universelles" dans une API que tu peux importer facilement dans un autre projet.
    Sinon, je trouve que c'est se prendre la tête pour pas grand chose.

    Par expérience, j'ai rarement eu besoin de coder ce genre de procédure car elles existent souvent déjà.
    Note : je bosse en Java et vu le nombre de framework existants, c'est vraiment rare de trouver une fonction générique jamais développée ailleurs.

  5. #65
    Membre à l'essai
    Homme Profil pro
    Responsable d'exploitation informatique
    Inscrit en
    mars 2015
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Responsable d'exploitation informatique
    Secteur : Transports

    Informations forums :
    Inscription : mars 2015
    Messages : 5
    Points : 12
    Points
    12

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Si et seulement si tu références tes procédures "universelles" dans une API que tu peux importer facilement dans un autre projet.
    Sinon, je trouve que c'est se prendre la tête pour pas grand chose.

    Par expérience, j'ai rarement eu besoin de coder ce genre de procédure car elles existent souvent déjà.
    Note : je bosse en Java et vu le nombre de framework existants, c'est vraiment rare de trouver une fonction générique jamais développée ailleurs.
    En effet, l'informatique a bien évolué et aujourd'hui on retrouve beaucoup de librairies, de bibliothèques qui offrent justement des procédures génériques qui illustrent l'idée que je veux exprimer. Et comme l'expression le dit, "on ne veut pas réinventer la roue". Mais même lorsqu'on utilise ces librairies dans notre programmation, on les utilise pour construire des procédures propre à notre application (par exemple un système de paie, de gestion du transport, etc.) et encore à ce niveau, on peut rechercher à "universaliser" la procédure créée, si c'est possible bien sûr.

  6. #66
    Membre du Club
    Profil pro
    Inscrit en
    avril 2010
    Messages
    21
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2010
    Messages : 21
    Points : 43
    Points
    43

    Par défaut

    - Faire une bonne architecture, découpage en classe, module, etc.
    - Chaque module doit être testé unitairement, avoir une bonne couverture de test (au moins 90 %), et aussi être testé rapidement et fréquemment pour éviter les regressions.
    - Faire simple, limiter la longueur des fonctions ou méthodes (pas plus de deux pages écran).
    - Réutiliser au maximum, ne jamais au grand jamais dupliquer du code (duplication code = duplication bug, duplication des modifications, et immanquablement on oublie de faire les évolutions à tous les endroits).
    - Documenter le code pour l'utilisateur (si ce sont des librairies utilisateurs), exemples d'utilisation (et cela n'a rien à voir avec du test), tutoriaux, une bonne documentation demande de gros effort, mais elle est nécessaire si on veut que les utilisateurs puissent pleinement adopter le fruit de votre travail.
    - Documenter le code pour le mainteneur ou pour soit même (reprendre du code 5 ans après est fréquent, et on a complètement oublié comment il fonctionne)
    - Avoir une mise en page du code aéré, correctement tabulée (pour apprendre à faire propre, rien ne vaut l'utilisation de python qui oblige une indentation irréprochable).
    - Bien sur git ou autre gestionnaire de version, et base de bug (jira par exemple).

  7. #67
    Membre à l'essai
    Homme Profil pro
    Responsable d'exploitation informatique
    Inscrit en
    mars 2015
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Responsable d'exploitation informatique
    Secteur : Transports

    Informations forums :
    Inscription : mars 2015
    Messages : 5
    Points : 12
    Points
    12

    Par défaut

    Citation Envoyé par remi_inconnu Voir le message
    - Faire une bonne architecture, découpage en classe, module, etc.
    - Chaque module doit être testé unitairement, avoir une bonne couverture de test (au moins 90 %), et aussi être testé rapidement et fréquemment pour éviter les regressions.
    - Faire simple, limiter la longueur des fonctions ou méthodes (pas plus de deux pages écran).
    - Réutiliser au maximum, ne jamais au grand jamais dupliquer du code (duplication code = duplication bug, duplication des modifications, et immanquablement on oublie de faire les évolutions à tous les endroits).
    - Documenter le code pour l'utilisateur (si ce sont des librairies utilisateurs), exemples d'utilisation (et cela n'a rien à voir avec du test), tutoriaux, une bonne documentation demande de gros effort, mais elle est nécessaire si on veut que les utilisateurs puissent pleinement adopter le fruit de votre travail.
    - Documenter le code pour le mainteneur ou pour soit même (reprendre du code 5 ans après est fréquent, et on a complètement oublié comment il fonctionne)
    - Avoir une mise en page du code aéré, correctement tabulée (pour apprendre à faire propre, rien ne vaut l'utilisation de python qui oblige une indentation irréprochable).
    - Bien sur git ou autre gestionnaire de version, et base de bug (jira par exemple).

    Je suis tout à fait d'accord avec cela. Je pense que ces principes et techniques de travail sont incontournables.

  8. #68
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 309
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 309
    Points : 12 359
    Points
    12 359

    Par défaut

    Citation Envoyé par remi_inconnu Voir le message
    - Faire une bonne architecture, découpage en classe, module, etc.
    -
    +1000
    c'est la première des habitudes que devrait avoir un bon développeur...mais ce n'est pas cité dans la liste donc le créateur de ce fil de discussion devrait le rajouter
    Citation Envoyé par micka132 Voir le message
    Pour une petite fonction ca peut passer, mais après c'est juste immonde!
    Je me suis déjà retrouver à devoir modifier une fonction de plus de 3500 lignes...
    Ben franchement j'aurais mis beaucoup moins de temps si c'était éclaté en 10 méthodes elles même divisé en 10 méthodes.
    cela semble être un problème malheureusement souvent rencontré dans les projets: soit la personne ne sait pas refactoriser soit le projet est bâclé.
    Ou bien la plupart du temps c'est qu'il y a zéro architecture de projet

    De toute façon avant d'apprendre à programmer on devrait obligatoirement apprendre à architecturer un programme
    * Descartes: "je pense donc je suis"
    * Bob l'éponge : "je pense donc j'essuie"
    * l'infirmière : "je panse donc je suis"

  9. #69
    Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    janvier 2012
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

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

    Informations forums :
    Inscription : janvier 2012
    Messages : 2
    Points : 3
    Points
    3

    Par défaut

    Etre curieux, comprendre l'anglais, être bien en algorithme, beaucoup pratiqué essayer aux moins de maîtriser un langage sans oublier les méthodologies des développement (SRUM OU AGILE...)

  10. #70
    Responsable
    Office & Excel

    Avatar de Pierre Fauconnier
    Homme Profil pro
    Formateur et développeur informatique indépendant
    Inscrit en
    novembre 2003
    Messages
    10 878
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur informatique indépendant
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 10 878
    Points : 27 314
    Points
    27 314
    Billets dans le blog
    5

    Par défaut

    Au vu de certaines discussions, notamment sur le forum VBA Excel, je dirais qu'une qualité d'un programmeur, c'est de pouvoir se remettre en question lorsqu'on lui met le nez dans son caca parce qu'il a codé comme un goret
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Vous souhaitez rédiger pour DVP? Contactez-moi
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    Vous avez apprécié l'intervention => Merci pour le
    ---------------

Discussions similaires

  1. Quelles sont les phases d'un programme?
    Par patchi225 dans le forum Débutant
    Réponses: 3
    Dernier message: 01/07/2011, 17h33
  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, 22h05
  3. quelles sont les SSII qui font du forfait
    Par coax81 dans le forum SSII
    Réponses: 11
    Dernier message: 12/10/2007, 14h49
  4. Réponses: 6
    Dernier message: 03/07/2007, 10h34

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