Quelles règles les programmeurs débutants devraient-ils toujours respecter ?

Un développeur expérimenté livre ses 7 règles d'or

A ses débuts, le programmeur inexpérimenté a tendance à fixer son attention sur la fonct
ionnalité à produire, quelque soit la quantité de ligne de code, les procédures et les f
onctions utilisées pour produire le résultat final. Et ceci sans comprendre (parfois
) ce qu'il fait vraiment ou les spécificités du langage.
Paul Vick, un développeur reconnu et spécialisé dans les bases de données et les langage
s, a travaillé sur plusieurs produits Microsoft dont SQL Server, Visual Basic ou l
e runtime .NET. Dans un billet de blog, il s'est inspiré des « sept règles pour les écri
vains débutants » pour en proposer une version aux jeunes développeurs et leur éviter de
faire trop d'erreurs.
Les voici.
Règle numéro 1, le programmeur débutant ne doit pas écrire de longues procédures. Une procé
ure ne devrait pas avoir plus de dix ou douze lignes de code.
Deux, chaque procédure doit avoir un objectif clair. Un bon programme doit avoir d
es procédures claires, sans cumul.
Trois, les programmeurs débutants ne doivent pas utiliser les fonctions fantaisist
es du langage. Pour Paul Vick, il est mal pour un débutant d'utiliser autre chose
que des déclarations de variables, les appels de procédures, des opérateurs (arithmétiqu
es, comparaisons, etc.) et les fonctions de contrôle de flux. Selon lui, l'utilisa
tion des fonctions simples oblige à réfléchir à ce que l'on écrit.
Règle numéro quatre, ne jamais utiliser les fonctionnalités du langage dont vous n'êtes
pas sûr(e) du résultat ou du rôle. Une règle d'or indépassable pour Paul Vick, qui estime
que si elle n'est pas respectée par un débutant, il devrait purement et simplement c
hanger de métier.
Règle numéro cinq, les débutants doivent à tout prix éviter le copier/coller. Sauf, évidemm
nt, s'ils veulent copier le code d'un programme qu'ils ont écrit.
Six, le débutant doit éviter l'abstrait, et toujours opter pour le concret.
Et enfin la règle numéro sept : applique les six règles ci-dessus chaque jour pendant
au moins six mois.
La pratique de la programmation en suivant ces 7 règles d'or peut s'avérer très gênant r
econnaît Paul Vick. Mais pour lui, c'est un excellent moyen d'apprendre un langage
de programmation.
Et pourrait même permettre, conclut-il avec humour, de se débarrasser des mauvaises
habitudes acquises à l'Université.

Quel conseil donneriez-vous à un débutant en développement ?

Et lequel auriez-vous aimé recevoir quand vous avez commencé à programmer ?
Le développement est un métier riche et passionnant, mais aussi dur et souvent diffi
cile d'accès.
S'il n'est pas correctement orienté lors de ses études par des enseignants passionnés
ou s'il est autodidacte par un parrain compétent, le débutant peut vite se perdre, s
e lasser et changer de cap vers d'autres métiers de l'informatique, jugés moins « pris
e de tête ».
Bryan Woods, un développeur américain a posté sur son blog quelques excellents conseil
s aux débutants. En fait, des conseils qu'il s'adresserait à lui même s'il pouvait rem
onter le temps.
Le premier conseil qu'il donne, c'est de ne pas sous-estimer le développement et d
'admettre une bonne fois pour toute que c'est un métier difficile, qui nécessite bea
ucoup d'efforts et de détermination afin d'être cerné et maîtrisé.
Sans quoi, à la rencontre de chaque nouveau concept qui semble étrange, difficile ou
non-intuitif, le débutant remettra en question son intelligence et sa capacité à cern
er le domaine.
"Pas grave, le développement c'est dur" est beaucoup moins négatif que "je suis nul"
ou "le développement c'est pas mon truc".
Le deuxième conseil que donne Woods est de bien choisir le premier langage à apprend
re. Car ce choix est capital dans la mesure où il conditionne la base du développeur
pour comprendre tous les autres langages.
De même qu'on ne peut "avoir des pensées" que dans sa langue maternelle, il n'y a se
lon Woods aucune raison pour que ce ne soit pas le cas avec les langages informa
tiques.
Un autre conseil : la meilleure manière d'apprendre le développement est de ... dévelo
pper.
Apprendre par la pratique permet de mémoriser rapidement les concepts du développeme
nt et les spécificités des langages. Ce qui permet d'apprendre à s'exprimer mieux et d
e plus en plus vite avec la machine.
Sans pratique au quotidien, tout le reste est inutile.
En revanche, ne pas être fort en math n'est, selon Woods pas un problème. Il admet a
voir été surpris à ses débuts, de constater à quel point les math sont si peu présentes dan
ses développements quotidiens.
Finalement, il donne un dernier conseil aux débutants, peut-être le plus important :
celui d'apprendre à apprécier l'apprentissage du développement, car ils ne finiront j
amais d'apprendre.
Et vous ? Quel conseil donneriez-vous à un débutant ?
Et quel conseil auriez-vous aimé que l'on vous donne quand vous avez commencé à progra
mmer ?

Quelle est votre définition du « vrai développeur » et comment le trouvez-vous ?

Un blogueur expose son point de vue
Mise à jour du 23/11/2010
Nous avons passé en revue hier (lire ci-avant) un billet du blogueur Steven Benner
. Son article a suscité sur Développez.com de nombreuses réactions et un débat intéressant
.
Mais il a une suite.
Après s'être attaqué (d'une manière assez caricaturale) aux catégories des développeurs, l'
uteur expose, dans un billet plus recherché, sa propre définition du « vrai développeur »,
comprendre les qualités qui doit réunir un bon développeur.
Selon lui, les vrais développeurs sont ceux qui peuvent apprendre vite, apprendre
par la pratique, et ne jamais arrêter d'apprendre.
La définition de Benner ne serait donc pas incompatible avec les développeurs qui ut
ilisent du code trouvé sur Google (ou Bing). Bien au contraire.
Ces développeurs, en arrivant à trouver et à adapter rapidement des solutions à leur tra
vail font justement preuve de capacités d'apprentissage et d'adaptation.
Pour trouver les vrais développeurs, Benner donne quelques pistes. Parmi lesquelle
s, il recommande de mettre les candidats à l'épreuve mais sur des compétences de haut-
niveau, non pas sur des patrons de conceptions ou d'obscures problèmes algorithmiq
ues.
Des problèmes théoriques, utilisés par certains recruteurs pour départager les candidats
, feraient passer à côté de certains "vrai développeurs". Car ces derniers peuvent de ne
pas arriver à se rappeler de solutions à des problèmes qu'ils ne rencontrent que rare
ment, voire jamais.
En revanche, il déconseille de recruter les développeurs qui s'intéressent plus à l'info
rmatique théorique qu'à l'expérience effective. Benner les considère même comme "une épine
erpétuelle dans le pied de l'industrie du développement".
Source : le blog de Steven Benner
Et vous ?
Êtes-vous d'accord avec la définition de Benner ?
Quelle est votre propre définition du vrai développeur et comment faites-vous pour l
es dénicher ?
Un blogueur classe les développeurs en cinq catégories
Êtes-vous d'accord avec son classement ? Et quelle catégorie vous correspond le plus
?
Steven Benner est un développeur Web californien qui blogue avec assiduité.
Parmi ses nombreux articles de fonds (et de qualité), il a récemment publié un article
dans lequel il classe les développeurs (selon son expérience) en 5 catégories. Une cl
assification forcément caricaturale mais néanmoins très intéressante.
La voici en réusmé.
En un : ceux qui sont efficaces, produisent des solutions rapides et robustes, m
ais pas vraiment élégantes.
En deux, les perfectionniste, qui ne se soucient aucunement des délais ni des budg
ets, seul le code parfait les intéresse et ils arrivent effectivement à faire des ch
ef d' uvres... mais souvent trop tard.
La troisième catégorie, selon Benner, est celle des anti-développeurs. Ceux qui refuse
nt de coder sous prétexte que quelqu'un a forcément déjà fait le code voulu, qu'il suffi
t tout simplement reprendre.
La 4ème catégorie, opposée à la 2ème, est celle des développeurs qui respectent toujours le
délais mais produisent du code "pourri". Les clients et les ressources humaines l
es adorent, les autres développeurs les haïssent.
Benner classe enfin en cinquième catégorie, les développeurs théoriciens qui passent le
plus clair de leur temps (80% selon Benner) à étudier les options possibles, 15% du
temps à pester contre les délais non raisonnable, 4% à raffiner les options et 1% du t
emps à coder réellement.
Trouvez-vous souvent le code des autres mauvais ?
Une développeuse décrit l'évolution de sa perception du travail des autres
Sara est une développeuse .NET qui se décrit comme une « Gerd » (Nerd au féminin).
Son blog est plutôt flashy mais le fond y est sérieux (pas triste, juste sérieux). Ell
e y parle de son expérience quotidienne du développement. Et parmi ses billets, l'un
d'eux est particulièrement pertinent. Sara y décrit l'évolution de sa perception du c
ode sources des autres.
Une expérience que de nombreux développeurs (et développeuses donc) ont déjà vécue.
Au départ, avoue Sara, elle trouvait systématiquement le travail des autres mauvais.
Elle reprenait le code « from scratch » dès le premier coup d' il.
Mais bien souvent, une fois le travail refait, son premier jugement devait être mo
déré. Ce n'est qu'après avoir tout ré-écrit qu'elle arrive à comprendre quelles contraintes
ont obligé ses prédécesseurs à coder d'une manière qu'elle avait, au premier abord, qualif
iée de mauvaise.
Avec l'expérience, nous dit-elle, elle a appris à ne jamais critiquer le travail des
autres. Tout du moins pas avant de comprendre le projet en entier et en cerner
toutes les contraintes.
Cette modération a du bon. Elle évite par exemple de se demander qui a bien pu coder
ce « truc horrible ». Avant de réaliser que c'est soi-même, quelques mois plus tôt.
Elle permet également de ne pas trop « avoir les chevilles qui gonflent » en se trouva
nt systématiquement meilleur que ses confrères.
Une modération qui se ferait (trop) rare ?