Discussion :

[Hinault Romaric]

Qu'est-ce qui fait un bon programmeur ?
Un senior liste cinq caractéristiques d'un bon programmeur

Quand peut-on dire que l'on est un bon programmeur ? Quels sont les éléments distinctifs d'un bon programmeur ? Certains d'entre nous se sont probablement déjà posés la question ou ont eu l’occasion d'en débattre.

Henrik Warne, un développeur senior, dans son blog « réflexion sur la programmation », liste cinq points clés qui permettent de distinguer ou de se définir comme un bon programmeur. Les points qu'il évoque sont les suivants :


1 - Décomposition du problème

Selon Warne, l'objectif de la programmation est de résoudre des problèmes. Ainsi, « avant d’écrire le code, le programmeur doit avoir une idée claire sur la démarche pour résoudre le problème ». Un bon programmeur sera donc celui qui sera capable de décomposer son problème au point d'aboutir à des petits éléments pouvant être résolus facilement. « Il ne s'agit pas simplement de résoudre le problème. Un bon programmeur trouve le moyen de modéliser le problème de façon à ce que le programme à mettre sur pied soit facile à implémenter et à tester », explique Warne.

2 – Analyse du scénario

Warne explique dans son billet de blog qu'un bon programmeur est celui qui a la capacité d’anticiper tous les scénarios possibles dans son programme (logique du programme, événements internes et externes qui peuvent se produire). « Pour tenir compte des différents chemins dans la logique, il se pose les questions : qu'est-ce qui se passe si cet argument est nul ? Et si aucune de ces conditions n'est vraie, etc. », affirme-t-il, concluant que le bon programmeur a la capacité de penser comme un testeur.

3 – Nommage

Le nommage des variables, des classes et des méthodes est un aspect clé de la programmation. Lorsque cela est bien fait, le programme « devient en grande partie autodocumenté, ce qui signifie que la fonction du programme est tout à fait claire à la moindre lecture du code », explique Warne.

Cependant, le nommage en programmation est l'une des activités les plus difficiles pour le programmeur, selon lui.

4 – Cohérence

« Le plus grand défi dans la programmation est probablement la gestion de la complexité. La cohérence est un moyen de gérer la complexité. Il réduit une partie de la complexité en nous permettant de voir les modèles et déduire comment les choses sont nommées, utilisées et manipulées », affirme Warne, qui explique que la cohérence permet au développeur de ne pas avoir à utiliser la puissance du cerveau pour se rappeler des exceptions et des variables aléatoires. Au lieu de cela, il peut se concentrer sur la « complexité essentielle et la complexité non accidentelle. »

D'après Warne, la cohérence est importante dans tous les aspects de la programmation. Elle s'applique aux noms de variables, méthodes, structures, interfaces utilisateur, gestions des erreurs, documentations, etc.

5 – L'apprentissage

Le développeur apprend constamment. « Avant d’intégrer une nouvelle fonctionnalité, il doit comprendre ce qu'elle est censée faire. Avant de modifier un code existant, il doit comprendre le fonctionnement de celui-ci, pour adapter ce qui doit être ajouté », explique Warne, pour qui l'apprentissage rapide rend un développeur plus efficace.

Au vu de l'évolution des plateformes et des langages, Warne conclut que la vie d'un programmeur n'est jamais ennuyeuse. Une situation qui convient parfaitement au geek qu'il est.


Source : blog Henrik Warne


Et vous ?

Selon vous, qu'est-ce qui fait un bon programmeur ? Êtes-vous d'accord avec Warne ?

[Potomac]

tiens encore une énième variation sur le thème "qu'est-ce un bon développeur/mouton à 5 pattes ?"

la dernière news de ce type remontait à il y a quelques jours :

http://www.developpez.com/actu/72719...us-productifs/

je pense qu'il y a plusieurs échelons à gravir, on ne nait pas "bon développeur" mais on le devient petit à petit, et souvent dans la douleur :

- échelon zéro: le point de départ, décrocher son diplôme en maitrisant certains points : l'algorithmie, les concepts de la programmation objet, un peu de base de données ( SQL ), un peu de web, un peu de UML, ça donne un développeur bac+2,

- échelon un: on a le diplôme, quelques stages et CDD, on est tout content mais on code comme un débutant en faisant plein d'erreurs, et en plus l'entreprise ne fait rien pour nous mettre dans le droit chemin ( c'est même l'inverse qui se produit ! Ah les SSII... ), le code n'est pas optimisé, on se rend compte que l'école ne nous a pas appris à faire des tests unitaires, ni à programmer en modèle-vue-contrôleur ( MVC ), et pire on ne connait pas les principaux framework de développement web, du coup on réinvente sans cesse la roue

- échelon deux : on a corrigé les manquements de la formation, on ne réinvente plus la roue grâce à la maitrise d'un ou deux framework à la mode, on produit du code plus ou moins optimisé mais on sent qu'on peut encore mieux faire,

- échelon trois : on a découvert l'existence des design pattern, l'extreme programming, ça a été un long chemin de croix pour tout maitriser mais ça va beaucoup mieux, on peut enfin s’auto-proclamer "développeur 5 étoiles"

[asgard20032]

Selon moi, le bon developpeur est celui qui est capable de faire un code auto descriptif et modulaire aisement, et qui met plus l'emphase sur la qualiter du code que sur son optimisation, lorsque loptimisation est negligable.

[smarties]

Des outils de qualité de code (comme SonarQube aident a devenir un meilleur développeur.

Le bon développeur utilise aussi un GIT ou similaire et décrit bien les changements.

L'UML, ça aide au début pour avoir une vison d'ensemble du projet et sur les points compliques (il faut pas tomber dans l'excès, ça prend du temps mine de rien).

[Zefling]

Selon moi, le bon developpeur est celui qui est capable de faire un code auto descriptif et modulaire aisement, et qui met plus l'emphase sur la qualiter du code que sur son optimisation, lorsque loptimisation est negligable.

Oui, ça serait vrai sur du code fait par une seule personne. Dans la réalité c'est rarement le cas. T'as 10 personnes qui sont passées sur le code que le dév doit modifier et t'as rarement le temps de tout remettre en ordre. De plus, tout le monde n'a pas la maîtrise parfaite de n frameworks utilisés sur l'ensemble des projets.

J'ai l'impression que le type décrit un dév parfait dans un monde parfait. Sauf que le monde ne l'est pas, et je dirais que une bonne qualité, c'est de savoir demander de l'aide quand on sait pas ou que l'on ne comprend pas plutôt que de faire n'importe quoi.

En tout cas, le point 2 me semble utopiste. Personne peux tout prévoir, sinon c'est un dieu. Et une très grande modularité du code prend énormément de temps que l'on a rarement sauf si on fait de la R&D, et encore ça ne sera jamais parfait.

[Heptaeon]

J'entends toujours qu'un bon code est modulaire, lisible, testé, optimisé, mais le meilleur n'est il pas le code suffisant ? Il y à la théorie de la bonne programmation et les moyens qu'elle nécessite. N'avons nous pas toujours des contraintes matériels au delà de ce qu'est théoriquement un "bon code".

Je crois qu'on a tous déjà fait de petits projets dans l'urgence "mal codé". Souvent on ne les retouchent pas pendant des années, car ils font ce qu'on leur demande. Au final on ne les change que quand les technologies ont évolué d'une manière qu'on aurait pas pu prévoir (breaking change, faillite d'une techno, etc...).

Les développeurs ne se perdent ils pas trop dans des considération technique ? Alors que ce qu'on leur demande la plupart du temps c'est de répondre "rapidement" a un besoin ? Je ne dit pas de faire de très gros projet en free-style non plus => la notion de "suffisant". Parfois ne faut il pas "mal programmer" pour être un "bon programmeur" ?

Selon Warne, l'objectif de la programmation est de résoudre des problèmes.

Je suis bien d'accord avec ce point, mais résoudre des problèmes techniques ou ceux de l'entreprise ?

[Potomac]

oui ce genre d'article oublie souvent que les développeurs sont avant tout au service de l'entreprise, avec des contraintes, un contexte qui fait que tous ces bons conseils ne sont pas toujours applicables dans la vie réelle

[koyosama]

Mouais le bon développeur se sera toujours la personne parmi ceux te ressemble parce que tu penses toujours que tu es le meilleur développeur.

Enfin avec l’expérience, le meilleur développeur c'est toujours celui qui est capable de se remettre en question.
Ceux qui évolue qui aime développer pour les autres.

[tatayo]

Le mauvais développeur, il prends son cahier des charges, l'analyse, puis développe. OK.

Le bon développeur, il prends son cahier des charges, l'analyse, puis développe. Mais c'est pas pareil...

[macslan]

Le mauvais développeur, il prends son cahier des charges, l'analyse, puis développe. OK.

Le bon développeur, il prends son cahier des charges, l'analyse, puis développe. Mais c'est pas pareil...

Quelqu'un a regardé Papy Grenier

[FaridM]

C'est moi ou ce type d'article revient tous les mois pour dire exactement la même chose ? (Nommage, analyser le problème, apprentissage constant...)

Une chose appréciable serait que les blogueurs qui pondent se genre d'article chacun leur tour nous donnent quelques conseils pour les mettre en application.

Le nommage. Comment bien nommer une variable ? numeroDeTelephone, numTel, ndt, phoneNumber ?

Pour la personne qui dit qu'il faut avant tout être passionné,
Pourquoi est-ce qu'un développeur doit être passionné pour bien faire son travail?
Est-ce qu'on en ai encore à se dire que le meilleur c'est celui qui code toute la nuit et qui à 15 projets perso en cours?
Un déménageur peut parfaitement faire son boulot sans être passionné, pourquoi ça ne pourrait pas être le cas dans le développement informatique?

[Invité]

Après avoir bien réfléchit, je pense qu'un bon programmeur est un programmeur qui se sent alaise dans ce qu'il fait.

Sa manière de nommer les variables et fonctions importe peu, logiquement il n-y a pas de bonne manière pour nommer les variables et fonctions puisque tout est relatif et dépend de la personne.

Ce qui est difficile pour les uns ne l'est pas forcement pour les autres.

Et de toute façon il n-y a pas de bon ou de mauvais programmeur, il y-a juste des programmeurs meilleurs que les autres.

[Saverok]

Un bon développeur sait travailler en équipe
La qualité d'une équipe se mesure à la satisfaction des utilisateurs du programme produit

[pmithrandir]

C'est moi ou ce type d'article revient tous les mois pour dire exactement la même chose ? (Nommage, analyser le problème, apprentissage constant...)

Une chose appréciable serait que les blogueurs qui pondent se genre d'article chacun leur tour nous donnent quelques conseils pour les mettre en application.

Le nommage. Comment bien nommer une variable ? numeroDeTelephone, numTel, ndt, phoneNumber ?

Pour la personne qui dit qu'il faut avant tout être passionné,
Pourquoi est-ce qu'un développeur doit être passionné pour bien faire son travail?
Est-ce qu'on en ai encore à se dire que le meilleur c'est celui qui code toute la nuit et qui à 15 projets perso en cours?
Un déménageur peut parfaitement faire son boulot sans être passionné, pourquoi ça ne pourrait pas être le cas dans le développement informatique?

Je pense que la programmation demande une part importante de créativité.
On trouve peu de personne qui n'aiment pas leur métier et qui continu à faire preuve de créativité.

[Bestel74]

C'est moi ou ce type d'article revient tous les mois pour dire exactement la même chose ? (Nommage, analyser le problème, apprentissage constant...)

Une chose appréciable serait que les blogueurs qui pondent se genre d'article chacun leur tour nous donnent quelques conseils pour les mettre en application.

Le nommage. Comment bien nommer une variable ? numeroDeTelephone, numTel, ndt, phoneNumber ?

Pour la personne qui dit qu'il faut avant tout être passionné,
Pourquoi est-ce qu'un développeur doit être passionné pour bien faire son travail?
Est-ce qu'on en ai encore à se dire que le meilleur c'est celui qui code toute la nuit et qui à 15 projets perso en cours?
Un déménageur peut parfaitement faire son boulot sans être passionné, pourquoi ça ne pourrait pas être le cas dans le développement informatique?

Tu ne peux pas comparer 2 métiers aussi différents l'un de l'autre :
Un bon soldat est prêt à mourir pour sa patrie, est-ce que du coup un bon développeur doit-être prêt à mourir pour sa patrie aussi ?

Ce n'est pas parce que la caissière fait du bon travail sans être passionné, que c'est aussi vrai pour un développeur !

Je pense qu'il faut au être un minimum passionné, pourquoi ? Car ça permet de continuer son auto-formation, et de toujours vouloir faire mieux !

EDIT: Du coup sans passion pour moi, le développeur aura beaucoup plus tendance à rester du ses acquis... Si ils sont excellents il pourra faire du très bon travail, mais pour combien de temps ?

[redbullch]

Je pense qu'il est important de nuancer. Dire dans l'absolu que les développeurs passionnés sont plus compétents n'est pas vraiment exact.

Par contre, on peut prendre le risque d'assumer : P(bon développeur|passionné) > P(bon développeur|pas passionné).

[Zefling]

Quelqu'un a regardé Papy Grenier

Tu veux dire Les Inconnus ?

[macslan]

Tu veux dire Les Inconnus ?

Il me semblait bien qu'ils avaient repris ce truc de quelque part

[Zefling]

Il me semblait bien qu'ils avaient repris ce truc de quelque part

En même temps, c'est assez souvent repris. Il faut dire, quand on dit « qu'est-ce qu'un bon [placez-ici l'activité] ? ». C'est souvent ça qui vient à l'esprit.

[deusyss]

La difference entre le bon et le mauvais dev !!! C'est à ça aussi que je pensais

SInon, des choses interessantes, mais deja souvent vu. Ce qui varie c'est le point de vue de chaque auteur, inspiré de sa propre experience...

Une partie de cet article rentre en contradiction (je trouve) avec un ancien article ou l'auteur stipulait qu'il n'était pas un compilateur. Eh oui, c'est effectivement mieux d'anticiper un maximum, mais on ne peux jamais el faire à 100% malheureusement.