Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ? Expliquez les avantages que vous en avez tirés 78PARTAGES 15 2 Quelles sont les habitudes de programmation qui caractérisent un bon développeur ? 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. 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 :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.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. Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 69 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Membre actif https://www.developpez.com

Mais pour moi voici les grands absents :



* respecter et écouter les gens (étonnamment rare)

* se remettre en cause et s'améliorer (techniquement comme humainement)

* prendre soin de sa santé (mal dormir, manger, boire et la machine s'enraye)

* communiquer efficacement (communication non violente, savoir où est sa place et les contraintes au-dessus et en dessous, comme on connaît sa stack)

* s'attacher à livrer de la valeur : les trade-offs du code (simple/complexe, propre/rapide, abstrait/hardcodé) sont ou devraient être des arbitrages métier 7 1 Je comprends que ce sont des astuces "de programmation" et que je propose autre chose.Mais pour moi voici les grands absents :* respecter et écouter les gens (étonnamment rare)* se remettre en cause et s'améliorer (techniquement comme humainement)* prendre soin de sa santé (mal dormir, manger, boire et la machine s'enraye)* communiquer efficacement (communication non violente, savoir où est sa place et les contraintes au-dessus et en dessous, comme on connaît sa stack)* s'attacher à livrer de la valeur : les trade-offs du code (simple/complexe, propre/rapide, abstrait/hardcodé) sont ou devraient être des arbitrages métier Expert confirmé https://www.developpez.com



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.

Selon le dictionnaire de l'Académie française, 9e édition, signifie . 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.

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.

: Ç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.

Je l'aurais reformulé en . 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.

C'est dommage que le mot 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 et qui ne commentaient 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.

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.

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 ?

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.

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.

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.

: 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.

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.

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é.

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 . Dans ce cas, j'aurais coché. veille technologique : suivre régulièrement les technologies utilisées et leurs alternatives

Oui.

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.

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.

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.

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.

Voir le point précédent. écrire du code facile à déboguer pas à pas

Par exemple, en C++, le code

Code : Sélectionner tout 1

2

3

4

5

int entier1 = uneFonctionQuiRetourneUnEntier(param1); int entier2 = uneFonctionQuiRetourneUnEntier(param2); int entier3 = uneFonctionQuiRetourneUnEntier(param3); if(entier1 + entier2 < entier3) doSomething();

Code : Sélectionner tout 1

2

if(uneFonctionQuiRetourneUnEntier(param1) + uneFonctionQuiRetourneUnEntier(param2) < uneFonctionQuiRetourneUnEntier(param3)) doSomething(); 7 2 Bonjour,Mes remarques point par point :J'ajoute aussi : Membre habitué https://www.developpez.com



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) 5 0 É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) Membre chevronné https://www.developpez.com 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... 5 0 À mon sens, il manque un choix dans la liste, et pourtant! je trouve que c'estqualité essentielle à tout développeur: je veux parler de l'. 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... Expert éminent https://www.developpez.com Envoyé par fodger Envoyé par 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.

On est rarement seul sur un projet et de même, on est rarement présent à 100% sur toute la durée de vie d'un projet.

C'est la même chose que pour la documentation.

Un TU, c'est un peu une doc technique ++ sur la manière dont a été testée et validée une fonction.



Pour en revenir au topic, je pense qu'une bonne habitude de programmation est de savoir s'approprier et se fondre dans la conception d'un programme.

Même si on est pas d'accord avec les choix effectués.

Même si on est pas en phase avec les normes mises en place.

On s'y astreint quand même.

Car sans cela, l'application au global devient rapidement un cauchemar de maintenabilité.

Je me suis trop souvent retrouvé sur des projets où chaque développeur avait voulu imposer "sa patte" ou "sa signature" et cela donnait un tout totalement incohérent. 5 0 Quand on écrit des tests unitaires, ce n'est pas que pour soi.On est rarement seul sur un projet et de même, on est rarement présent à 100% sur toute la durée de vie d'un projet.C'est la même chose que pour la documentation.Un TU, c'est un peu une doc technique ++ sur la manière dont a été testée et validée une fonction.Pour en revenir au topic, je pense qu'une bonne habitude de programmation est de savoir s'approprier et se fondre dans la conception d'un programme.Même si on est pas d'accord avec les choix effectués.Même si on est pas en phase avec les normes mises en place.On s'y astreint quand même.Car sans cela, l'application au global devient rapidement un cauchemar de maintenabilité.Je me suis trop souvent retrouvé sur des projets où chaque développeur avait voulu imposer "sa patte" ou "sa signature" et cela donnait un tout totalement incohérent. Membre confirmé https://www.developpez.com



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 ? 5 1 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 ? Membre confirmé https://www.developpez.com



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. 5 1 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. Expert confirmé https://www.developpez.com Envoyé par Pyramidev Envoyé par Je pense que le même bout de code sera plus lisible et plus commode à maintenir sous cette forme :



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. 4 0 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. Responsable Office & Excel https://www.developpez.com 4 0 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 Expert confirmé https://www.developpez.com

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.



Envoyé par foetus Envoyé par dans ton exemple "lisible" tu as une ligne de plus Pas d'accorddans ton exemple "lisible" tu as une ligne de plus

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. 3 0 foetus,On n'a pas interprété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.Ce n'est pas une question de lisibilité.Dans mon exemple avec, 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, pour connaître les valeurs des entiers retournés, il faut entrer dans la fonction, ce qui est moins pratique. Poster une réponse Signaler un problème

