Les 6 vérités de la programmation
Se vérifient-elles autour de vous ?

Le , par Katleen Erna, Expert éminent sénior
Les 6 vérités de la programmation, se vérifient-elles autour de vous ?

Un développeur américain explique sur son blog que son expérience professionnelle dans le domaine de la programmation lui a permis de faire quelques constatations à propos des professionnels de l'IT et de leur manière d'écrire du code.

Les voici :

- Un programmeur passe entre 10 et 20% de son temps à coder, et écrit en moyenne 10 à 12 lignes de code par jour qui seront incluses dans le produit final (peut importe leur niveau). Les bons programmeurs utilisent le temps qu'il leur reste à penser, rechercher et faire des tests pour parvenir au meilleur design possible. Les mauvais quant à eux passent ces 80 à 90% de temps à debugger leur code en faisant des essais au hasard puis en regardant si cela fonctionne.

- Un bon programmeur est dix fois plus productif qu'un programmeur lambda. Un excellent programmeur, lui, est de 20 à 100 fois plus productif que ce dernier. Des études l'ont montré, et ce, depuis les années 60. Un mauvais programmeur quant à lui, n'est pas seulement non productif, en plus de ne rien créer d'utile, il génère des heures de travail et de maux de tête pour ses collègues (qui devront réparer ses erreurs).

- Les programmeurs très compétents passent très peu de leur temps à écrire du code (du moins du code qui se retrouvera à la fin dans le produit fini). Ceux qui passent la majeure partie de leur temps à coder sont trop fainéant, trop ignorants ou encore trop arrogants pour trouver des solutions existantes à d'anciens problèmes. Les programmeurs très compétents sont maîtres dans l'art de reconnaître et de réutiliser des schémas communs. Les bons programmeurs n'ont pas peur de réécrire leur code constamment pour atteindre le design idéal. Les mauvais, eux, écrivent du code qui manque d'intégrité conceptuelle, de hiérarchie et de schémas, et dans lequel se trouvent trop de répétitions. Du coup, c'est dur à réécrire, et il est plus rapide de se débarrasser d'un mauvais code pour repartir de zéro, que de le modifier.

- Une étude de 2004 a démontré que 51% des projets de logiciels connaîtront des échecs sur quelque chose de critique, et 15% connaîtront un échec tout court.
C'est mieux que 1994, où on notait 31% d'échecs.
Cependant, la plupart des programmes sont faits par des équipes dans une ambiance non démocratique. Une seule personne est responsable du design, tandis que les autres peaufinent les détails.

- Programmer, c'est du boulot. C'est une activité mentale intense. Les bons programmeurs pensent à leur travail tous les jours, 24 heures sur 24. Ils écrivent leurs codes les plus importants sous la douche ou dans leurs rêves. Parce que le travail le plus important est réalisé loin d'un clavier. Donc, la finalisation d'un projet ne peut pas être accélérée en passant plus de temps au bureau, ou en ajoutant plus de monde au projet.

- Les programmes obéissent aux lois de l'entropie, comme beaucoup d'autres choses. De ce fait, des changements perpétuels causent des erreurs, ce qui érode l'intégrité conceptuelle du design original.
C'est inévitable d'en arriver là, mais les programmeurs qui oublient de prendre l'intégrité conceptuelle en considération créent des programmes qui se dégradent si vite qu'ils deviennent inutiles avant même d'être achevés. Les problèmes d'entropie de ce type sont certainement la plus grande cause d'échec dans ce domaine.

Source : Le blog de David Veksler

Ces vérités se vérifient-elles autour de vous ? Les approuvez-vous ? Les reconnaissez-vous dans votre expérience ?

Avez-vous quelques anecdotes à raconter qui illustrent ou au contraire contredisent les affirmations de David Veksler ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Xper4net Xper4net - Futur Membre du Club https://www.developpez.com
le 31/08/2010 à 11:11
Citation Envoyé par popo Voir le message
ça me rappelle qu'il y a deux gros boulets dans la boîte ou je suis.
Pour l'anecdote. Je regardais le travail d'une autre équipe de Dev. sur un source commun et là je remarque que l'un des développeur à livré une fonction identique au LeftStr de Delphi. En fait, la seule chose qui changeait était les nom des variables sinon c'était rigoureusement la même. J'envoie donc un mail à cette personne en mettant les forme afin de ne pas le contrarier pour lui dire que la fonction qu'il avait codé était déjà native à Delphi. Il me répond que ce n'est pas lui qui avait codé cette fonction, mais qu'il s'était contenté de déplacer cette fonction du source d'un autre collègue parce que l'unité où elle se trouvait avait de l'IHM et que son plugin ne compilait plus.
ça fait donc deux boulets, un qui s'amuse à recoder les fonctions de bases incluses dans delphi et un autre qui l'utilise dans plusieurs de ces sources en ajoutant pour l'occasion des tonnes de uses inutiles !
Cette anecdote est un cas d'école, non pas pour stigmatiser l'incompétence d'un tel ou un tel, mais parce qu'elle témoigne d'une organisation particulièrement défaillante, sans aucun processus de contrôle.
Ce type d'erreur n'aurait en effet pas pu se produire si les projets avaient mis en place des relectures croisées et des revues de design. Vous êtes loin du CMMI2 dans ta boîte.
Et faut pas venir me dire "on peut pas faire ça, on nous pousse au cul et on n'a pas le temps". Car l'effort de qualité qu'on ne fait pas pendant les dev, on le paye puissance 10 sur les dernières fonctionnalités, les intégrations, et surtout en alpha tests avec une déferlante de bugs, qui de surcroît deviennent au fur et à mesure de plus en plus compliqués à corriger. Vous avez sans doute tous pu constater que c'est là que les plus gros retards sont pris.
Soit dit en passant, l'erreur initiale la plus grave n'est pas la duplication de fonction native, mais sa dépendance par rapport à un module de présentation.
Avatar de Pergos Pergos - Membre habitué https://www.developpez.com
le 31/08/2010 à 15:10
Citation Envoyé par Katleen Erna Voir le message
Ces vérités se vérifient-elles autour de vous ? Les approuvez-vous ? Les reconnaissez-vous dans votre expérience ?
Il faudrait être sacrément vaniteux pour pouvoir dire de soi-même qu'on est un bon développeur, et encore plus sacrément chanceux pour que ce soit vrai...

Pour moi, on ne peut vraiment être jugé sur ce point que par ses pairs, et encore, par ceux qui ont pu parcourir et expérimenté des pans de code suffisants dans ses applications...
(tellement jugent directement mauvais ou bon développeur des gens dont ils n'ont pas lu une seule ligne de code... Et ce sont des développeurs, en plus, la plupart du temps...)
Avatar de chaplin chaplin - Membre expérimenté https://www.developpez.com
le 31/08/2010 à 16:20
Citation Envoyé par Pergos Voir le message
Pour moi, on ne peut vraiment être jugé sur ce point que par ses pairs, et encore, par ceux qui ont pu parcourir et expérimenté des pans de code suffisants dans ses applications...
(tellement jugent directement mauvais ou bon développeur des gens dont ils n'ont pas lu une seule ligne de code... Et ce sont des développeurs, en plus, la plupart du temps...)
Sans parler de bon ou de mauvais développeur, s'il faut juger de l'architecture, la remarque en dessous est tout à fait justifiée.
Même si l'article est un peu caricatural, il y a des éléments positifs. Il est sûr que s'il faut "pisser" du code à l'arrache, s'il faut fournir un résultat rapidement, "ça se discute".
Je pense qu'il faut comprendre que le bon programmeur sait supprimer la redondance ("réutiliser des schémas communs").
C'est pour supprimer la redondance qu'il passe 80% de son temps à usiner son code.
Avatar de parou parou - Membre du Club https://www.developpez.com
le 01/09/2010 à 12:26
Dommage je fait donc partis des mauvais programmeur ´

- J'ai travaillé en Cobol (maintenant je fais du JAVA mais je traine certainement un arriéré de plusieurs centaines de millier de lignes)

- Je pars du principe que pour être bon un programmeur le point principal c'est comprendre les besoin de l'utilisateur (pouvoir se mettre à ca place) c'est déjà 75% de réussite sur un projet

- KISS Keep It Simple Stupid car 80% du travail sur un programme en 10 ans de vie c'est de la maintenance

- Les frameworkS avec leurs nombreux release, changement de version, incompatibilité réciproque, ... je m'en méfie il faut les choisir avec beaucoup de vigilance sinon au final ils peuvent apporter plus de problèmes que de solutions

- Remplacer les lignes de code par un nombre de click sur une interface graphique ou des fichierS XML ne simplifie pas forcement la vie

- Rajouter 587 couches d'indirection entre une application Front et une application backend alors qu'au final si l'ont ajoute une nouvelle zone elle devra être visible des 2 cotés juste au cas ou, est non productif

- Et surtout le travail d'un informaticien n'est pas de faire de l'informatique pour faire de l'informatique, en fin de journée regardé les 12 lignes de code et se dire wahoo quels sont jolie mes petites lines ne rapporte rien

- Au final il faut bien sur un temps de réflèction avant de se lancer dans le code mais la mesure de la qualité d'un programmeur ne se fait pas sur le nbr de lignes de code produite ou non, elle se base sur ca capacité à traduire des besoins utilisateur en solution informatique simple fiable et robuste
Avatar de Gouyon Gouyon - Membre éprouvé https://www.developpez.com
le 01/09/2010 à 19:14
Citation Envoyé par parou Voir le message

- Je pars du principe que pour être bon un programmeur le point principal c'est comprendre les besoin de l'utilisateur (pouvoir se mettre à ca place) c'est déjà 75% de réussite sur un projet

- Les frameworkS avec leurs nombreux release, changement de version, incompatibilité réciproque, ... je m'en méfie il faut les choisir avec beaucoup de vigilance sinon au final ils peuvent apporter plus de problèmes que de solutions

- Remplacer les lignes de code par un nombre de click sur une interface graphique ou des fichierS XML ne simplifie pas forcement la vie
Je suis assez d'accord là dessus bien que n'ayant jamais fait de Cobol

Citation Envoyé par parou Voir le message
- Et surtout le travail d'un informaticien n'est pas de faire de l'informatique pour faire de l'informatique, en fin de journée regardé les 12 lignes de code et se dire wahoo quels sont jolie mes petites lines ne rapporte rien
robuste
Pas d'accord ça rapporte une certaine satisfaction personnelle et des opportunités de se vanter auprès des collègues
Avatar de roudoudouduo roudoudouduo - Membre habitué https://www.developpez.com
le 01/09/2010 à 23:43
Pour moi un bon code doit exprimer :
- les intentions du programmeurs ;
- les intentions du fonctionnelles ;
- être bien tester et ETRE lisible. Ces deux éléments sont indispensables de mon point de vue. Les tests doivent permettent de vérifier le fonctionnelle et le technique.

Les langages comme Java sont suffisamment riche pour pouvoir les intentions et le besoins. La présence d'un architecte est indispensable (et ceux même sur des petits projets avec des interventions très courtes) : il permet d'assurer l'homogénéité (et un bon architecte doit être capable de s'adapter au niveau et à l'expérience de son équipe).

Récemment mon équipe vient de livrer une mise à jour d'un logiciel comprenant trois modules :
- un partie basé sur un existant codé salement et sans tests unitaires ;
- deux nouveaux modules codés proprement (bien que différemment ce qui est une tare car l'homogénéité est importante). Les tests ont été rédigés avec soin (pour le module sur lequel j'ai travaillé la couverture était >80%).

Suite à la phase de recette (première phase de test avec un ensemble de client sélectionne dans un environnement de test) nous avons constaté les éléments suivants :
- tous les bugs de la partie mal codé (80-90%) ont été atrocement compliqué à corriger et notre équipe a introduit au fur et à mesure des TU tout en nettoyant le code pour éviter que la prochaine mise à jour soit un cauchemar;
- tous les bugs des autres parties (quelques bug IHM + 3 bugs/fonctionnelles techniques) ont pris tres peu de temps à corriger. Des TU ont été rédigés afin de limiter les régressions.

En POO peu importe le nombre de lignes de code ce qui compte c'est que le code corresponde vraiment aux attentes et que les TU valident les comportements attendus. Trop de réflexion préalable (et surtout trop détaillé) est complètement improductif. Le système doit être vu à très haut niveau. Une fois les composants Macro établis, la conception détaillée de chaque module doit êtrevivante et evolutive. Le découplage est important. Mais il est illusoire de croire qu'une analyse sera définitive et bonne. La qualité du code est essentielle et le refactoring est un outil permettant de l'améliorer constamment. Bien sur il ne faut pas se focaliser sur un modele et l'améliorer jusqu'à l'extrême mais fixer la regle suivante permet d'éviter le phénomène de dégradation continue des codes : lorsque vous effectuer une modification, le code doit être meilleur à la fin.

Enfin les critères de "bon" et de "mauvais" doivent être fixés avec l'équipe avec l'aide d'un architecte qui doit être capable de s'adapter au niveau de son équipe sans remettre en cause la pérennité d'un projet.
Avatar de Marco46 Marco46 - Expert éminent https://www.developpez.com
le 02/09/2010 à 10:04
@roudoudouduo : un gros +1 avec en gras en italique et souligné.

Mais comment faire comprendre à des décisionnaires qui ne connaissent pas la POO (à peine de nom) quels en sont les intérêts ? Comment faire voir à un vieux développeur l'intérêt qu'il aurait à se mettre à jour du procédural vers la POO alors qu'il ne comprends pas la POO ???

Il suffit de lire certains commentaires de certains de nos anciens ici pour voir que même des gens qui se sentent concernés par l'évolution de leur métier restent hostile à la POO. Pourtant elle est bien mieux adaptée à l'info de gestion que le procédural, c'est juste indiscutable.

Ça me mine ce problème parce que j'ai l'impression que c'est partout pareil, et que comme les décisionnaires (chefs de groupes, patrons, ...) ont plus de 40/50 ans et qu'ils ont globalement réussis ils n'écoutent pas les jeunes qui veulent faire évoluer les pratiques et que la situation est bloquée tant que ces boulets ne partent pas à la retraite.

C'est pareil avec les analyses de BDD, faut s'y prendre longtemps pour expliquer ce que c'est qu'une transaction, que non c'est pas possible de tolérer qu'une micro-coupure réseau empêche la facture de s'écrire en totalité, que si il faut mettre des clefs primaires avec id auto partout, que les règles d'intégrité ça fait économiser des lignes de code etc ...
Avatar de roudoudouduo roudoudouduo - Membre habitué https://www.developpez.com
le 02/09/2010 à 10:43
Il m'arrive régulièrement de recevoir le soutien de décisionnaire qui appuie ou au moins sont intéressés par ma façon de travailler. Ce n'est pas forcément une règle général.

Mais il ne faut pas négliger que les jeunes sont pour la plupart deja vieux, et que dés qu'ils ont acquis une expérience et une technique minimale ne veulent plus la faire évoluer et ne supporte pas ceux qui le font. Combien ai-je de collègue qui ne comprenne pas qu'un nombre de classe + eleve mais un code beaucoup plus simple et bien plus facile à généraliser, à mutualiser etc... En vérité la différence vient souvent d'un constat simple : les passionnés souhaitent faire évoluer les choses et s'investissent, et ceux pour qui travailler est simplement vital ou alors pour qui la technique est un simple tremplin vers chef de projet ne vont pas réaliser d'excellent produit.

Pour faire évoluer les seconds (qui constitue bon nombre du corps des développeurs), il faut des appuis des décisionnaires, des encadrant techniques charismatiques et apréciés.

En vérité la plus grande qualité et difficulté d'un expert en technique n'est pas la technique (souvent il est doué dans ce domaine), mais plutot l'adaptation de la technique aux commerces (par la qualité) et à ces collaborateurs. Quand un expert réussit à réunir toutes ces qualités alors c'est l'eldorado.

Après il faut bien comprendre qu'une belle conception que des tests bien réalisés n'amusent pas tout le monde. Bien sur pour ma part cette créativité constante est passionnante.
Avatar de sshpcl2 sshpcl2 - Membre régulier https://www.developpez.com
le 02/09/2010 à 12:08
et puis au bout de 10 ans le bon programmeur qui à pensé a sont programme partout meme dans les chiottes (ce qui est trés poutinien comme façon de faire) vivant dans la total dictature de la productivité absolu ..

ben le bon programmeur il a mal au dos mal a la tete il deviens soulant et iritable mais il continu a avoir reponse a tout ...

un corps deseché ..

du coup tu sort tu lache le micro c'est le meilleur moyen d'avoir de l'energie et reflechir mieux et de faire ca bien de 7 a 77 ans .. mieux sa veux dire prendre tout en compte ..
Avatar de bruneltouopi bruneltouopi - Membre confirmé https://www.developpez.com
le 03/09/2010 à 16:29
Le concept de mauvais programmeur est vérifiable mais en fait tout le monde a la possibilité de rêver du code car cela dépend de la pression qui vous ai mise ou chacun dans son subconscient peut avoir un éclair de génie.
Maintenant la personne qui se transcende pour avoir une vision globale d'un projet qui se projete dans le futur.Ou qui se donne les moyens de sortie et des méthodes en V est là un bon programmeur je dirai à la mésure un concepteur
Avatar de Jomtek Jomtek - Membre à l'essai https://www.developpez.com
le 21/04/2017 à 19:55
C'est vraiment n'importe quoi ce qui est écrit sur cet article..

Je programme environ 300 lignes de code par jour, je passe 40% de mon temps à programmer et je pense qu'un "bon programmeur" n'est pas un programmeur qui fait des scripts courts.. Je pense que passer beaucoup de temps à bidouiller son code (même quand on sait à l'avance que c'est inutile) peux apprendre au programmeur les erreurs qu'il fait, il peux aussi en apprendre plus sur la méthode dont son script se déroule afin de corriger d'éventuelles "fautes"..
Offres d'emploi IT
RESPONSABLE WEB ANALYTICS F/H
VACALIANS GROUP - Languedoc Roussillon - SETE (34)
Développeur Web FULL-STACK
VACALIANS GROUP - Languedoc Roussillon - SETE (34)
Développeur WEB PHP F/H
VACALIANS GROUP - Languedoc Roussillon - SETE (34)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil