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

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

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

    153 83,61%
  • Ne pas optimiser le code au début

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

    51 27,87%
  • Tout documenter et commenter

    59 32,24%
  • Faire des pauses régulièrement

    53 28,96%
  • Maîtriser parfaitement ses outils

    53 28,96%
  • Utiliser les lignes de commandes plutôt que les interfaces graphiques

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

    141 77,05%
  • Lire les codes source des projets

    40 21,86%
  • Utiliser un EDI performant

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

    73 39,89%
  • Écrire des tests unitaires

    83 45,36%
  • Taper sur Google et être actif sur les forums techniques

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

    66 36,07%
  • Parcourir toute la documentation

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

    10 5,46%
  • 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 éprouvé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    305
    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 : 305
    Points : 1 255
    Points
    1 255

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

    Informations forums :
    Inscription : avril 2004
    Messages : 640
    Points : 909
    Points
    909

    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 641
    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 641
    Points : 6 432
    Points
    6 432

    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 000
    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 000
    Points : 11 254
    Points
    11 254

    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, 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