Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Katleen Erna

0PARTAGES

4  3 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Mens Pervincet
Membre habitué https://www.developpez.com
Le 24/08/2010 à 1:04
C'est intéressant globalement, mais ça manque beaucoup de nuance... Un bon programmeur sait aussi évaluer le rapport cout/retours sur investissements, et ne va pas concevoir un design générique, modulable, une machine de guerre qui accouchera ensuite d'une souris...
J'ai souvent vu des types (moi y compris) s'embarquer dans des trucs très complexes qui n'avaient pas lieu d'être, du genre développer le proto jetable d'une IHM en utilisant MVC Visitor et toute la clique...

Si l'on n'utilise pas le dernier framework JEE qui tue pour développer le site web de madame michou, c'est pas par fainéantise "arrogance" ou parcqu'on est un mauvais programmeur, c'est juste parcqu'on arrive à décoller 2 secondes de la bulle "d'autiste architecte qui rêve de code et conçoit son appli aux chiottes", et qu'on a conscience qu'une appli si on la code c'est pas pour faire avancer la recherche ou transcender les frontières des design pattern, c'est avant tout pour qu'elle soit utilisée. Et si madame Michou a juste besoin d'un lien vers son site de cuisine préféré et d'une image de son chat, je vais pas lui coder une architecture 3 tiers.
30  3 
Avatar de mabdylon
Nouveau membre du Club https://www.developpez.com
Le 23/08/2010 à 23:53
Je trouve son approche vaniteuse et hors contexte.

Quels sont les moyens donnés aux "mauvais développeurs" selon lui ?

Je manque surement d'expérience en équipe, mais celles qui me sont relatés, ou celles que je lis, me laissent clairement penser qu'il y a du progrès à faire lorsqu'on localise une "bête noire" qui nuit à la productivité du troupeau.

Je pencherai plus pour dire que du potentiel est souvent inexploité par faute de confiance/moyen/innovation.

Mais bon c'est son blog, son opinion, quoique assez tranché "blanc ou noir".

Sujet à Troll, certainement
13  3 
Avatar de Firwen
Membre expérimenté https://www.developpez.com
Le 24/08/2010 à 8:44
Il y a les mêmes différences entre un bon programmeur et un mauvais programmeur que entre un bon chasseur et un mauvais chasseur
7  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 24/08/2010 à 15:18
Quoi qu'il en soit, je trouve que mesurer sa contribution à un projet en lignes de code c'est juste débile. En plus avancer un chiffre c'est assez gonflé.

Et employer des solutions existantes pour ne pas avoir besoin de réinventer la roue c'est bien, cependant quand je vois des sites web tout simples de gestion de contacts faits avec plein de frameworks qui font de la réflexion, de l'injection de dépendances, des trucs qui confinent à la magie noire et qui laissent des stacktrace de 25m incompréhensibles en cas d'erreur d'initialisation, ça me fait doucement rire.

En bref cet article, je le trouve assez bof finalement, c'est un peu catégorique de dire "les bons y font comme ça" "les mauvais y font comme ci".
Pour moi, si l'application remplit le besoin du client, respecte les délais tout en étant simple à maintenir, c'est que le développeur a bien bossé.

Ce ne sont pas les kilomètres de diagrammes au crayon papier ou le fait qu'on ait eu ses idées sous la douche ou devant son IDE qui y changent grand-chose. Pas plus que le fait d'avoir suivi à la lettre les design patterns ou architectures X tiers, d'avoir écrit ses tests unitaires avant ou après l'implémentation, d'avoir dépassé l'apport journalier moyen de X lignes de code par jour et j'en passe.

En gros je me méfie de ces super-programmeurs qui assènent leur vision des choses sur leur blog sans aucune nuance, telle la vérité absolue.
8  1 
Avatar de Ivelios
Membre expérimenté https://www.developpez.com
Le 24/08/2010 à 0:05
ça me rassure, il n'y a pas que moi qui tourne en rond dans mon lit en pensant au futur ligne de code à écrire
ça me rassure aussi de savoir que je ne fais pas du mauvais boulot si je réfléchis pendant 2 heures avant d'attaquer le code
6  0 
Avatar de Julien_G
Membre averti https://www.developpez.com
Le 24/08/2010 à 9:02
J'ai remarqué qu'un bon programmeur fait des IHM très laides aussi
6  0 
Avatar de davcha
Membre expérimenté https://www.developpez.com
Le 24/08/2010 à 9:59
Citation Envoyé par keskispas Voir le message
12 lignes/jour ??? J'avoue que c'est la phrase qui m'a le plus surpris. Peut être ne travaillait-t'il que sur des réécritures ou il disposait d'une énorme bibliothèque. Mais il a bien fallu l'écrire ce code de base : c'est le boulot des mauvais programmeurs ?
C'est les joies de l'open-source :

Des gens peu scrupuleux débutent un projet open-source, font un gros buzz dessus, d'autres personnes naïves viennent leur prêter main forte et font tout le boulot.
Mais au final ils sont tellement nombreux que chacun d'entre-eux a peut-être écrit 60 lignes de code au total dans ce projet, étalé sur 5-6 jours, entre midi et deux ou le soir en compagnie de leur femme qui regarde secret story à la télé.

Plus tard, le projet est mature, les gens peu scrupuleux du début récupèrent tous les lauriers, grâce à leurs adeptes fanboys qui les ont aidés.

A ce moment là, les gens peu scrupuleux attrapent la grosse tête (si c'était pas déjà fait) et trollent sur des newsgroups dont tout le monde se fout à propos de leurs choix de design sans forcément savoir de quoi ils parlent (comme le choix de C parce que C++ "c'est de la merde pour mauvais programmeur".

S'en suit une guerre contre les modèles propriétaires qui pompent tout ce travail de chinois pour des clopinettes (c'est à dire rien, puisque c'est open-source, et que de toute façon, les licences GPL on s'en fout ).

[/humour] :p
5  0 
Avatar de Thorna
Membre éprouvé https://www.developpez.com
Le 24/08/2010 à 7:27
Les programmeurs très compétents sont maîtres dans l'art de reconnaître et de réutiliser des schémas communs.
Bon, ok, beaucoup de choses sont déjà écrites, mais pour les retrouver, ce n'est pas d'un programmeur dont on a besoin, mais d'un documentaliste !
Les bons programmeurs n'ont pas peur de réécrire leur code constamment pour atteindre le design idéal.
Le "bon" ne deviendra alors jamais "compétent", parce qu'entre ces 2 idées, c'est un revirement non ? A quoi bon passer 80% de son temps à trouver ce qui existe déjà pour gaspiller "constamment" son temps à le réécrire ?
4  0 
Avatar de maske
Membre éprouvé https://www.developpez.com
Le 24/08/2010 à 12:15
C'est un petit peu n'importe quoi ce post - selon moi déconnecté de la réalité et très caricatural.

C'est qui ce type qui sort la vérité moulée dans un blog avec autant de confiance en soi ?

Il ne me paraît pas important d'argumenter, tant chaque élément, caricature et amalgame à la fois des "bons" et "mauvais" programmeurs, parle de lui même.

Sans déconner, c'est ce que vous voyez dans votre vie professionnelle de tous les jours ?

Je répondrais simplement sur une chose : 12 lignes de code effectives incluses dans le projet final par jour ?

Mais euh sur des projets de plusieurs milliers de lignes, qui c'est qui programme alors ? Le mauvais programmeur, parce que le bon est occupé à réfléchir sur ses 12 lignes ?

Si on compte rapidement, 12 000 lignes de code (un petit projet donc), à 12 lignes par jour, ça fait 1000 jours pour avoir le projet complet ?

Est-ce que ça serait pas un peu débile ?

Pour ceux qui diraient qu'on utilise des librairies externes open-source-machin-truc-etc., on ne les comptes pas dans le nombre de lignes produites dans un projet (sinon je vois pas comment on évalue ce qui a été produit en terme de volume de code).
4  0 
Avatar de davcha
Membre expérimenté https://www.developpez.com
Le 24/08/2010 à 13:19
Citation Envoyé par maske Voir le message
Si on compte rapidement, 12 000 lignes de code (un petit projet donc), à 12 lignes par jour, ça fait 1000 jours pour avoir le projet complet ?

Est-ce que ça serait pas un peu débile ?
Non, parce quand t'es un excellent programmeur, tu te débrouilles pour refiler le boulot à quelqu'un d'autre. Que ça soit un générateur de code auquel tu comprends rien, ou un mec lambda qui veut absolument participer à ce mouvement humanitaire qu'est l'open-source
3  0