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

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

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

    156 83,42%
  • Ne pas optimiser le code au début

    62 33,16%
  • Se concentrer sur la tâche la plus importante

    53 28,34%
  • Tout documenter et commenter

    60 32,09%
  • Faire des pauses régulièrement

    55 29,41%
  • Maîtriser parfaitement ses outils

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

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

    144 77,01%
  • Lire les codes source des projets

    42 22,46%
  • Utiliser un EDI performant

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

    74 39,57%
  • Écrire des tests unitaires

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

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

    67 35,83%
  • Parcourir toute la documentation

    23 12,30%
  • Autres (à préciser dans les commentaires)

    11 5,88%
  • Pas d'avis

    0 0%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 4 sur 4 PremièrePremière 1234
  1. #61
    Membre expérimenté
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    365
    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 : 365
    Points : 1 590
    Points
    1 590

    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
    644
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations forums :
    Inscription : avril 2004
    Messages : 644
    Points : 921
    Points
    921

    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 642
    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 642
    Points : 6 448
    Points
    6 448

    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 : 41
    Points
    41

    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 157
    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 157
    Points : 11 773
    Points
    11 773

    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"

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