Discussion :

[fkylol]

Réinventer la roue, refaire un existant à sa propre sauce, c'est tellement jouissif!
Problème : ça n'apporte rien à l'utilisateur. Le développeur qui fait ça est donc un mauvais développeur. En tout cas c'est ce qui sera retenu.

[eric.quinton]

Bah, il suffit de lire le manifeste agile, qui permet de répondre à ces assertions. Il a au moins le mérite de parler du projet, et pas seulement du développeur, qui n'en est qu'un maillon. Et de là à classer les développeurs entre très bons (forcément moi ) et les mauvais (les autres )...
http://agilemanifesto.org/

[reffadi]

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 ?

[Excellion]

Rien à redire sur cette étude.

Sauf peut-être que les entreprises préfèrent les mauvais développeurs, qui donnent l'impression de toujours travailler, en massacrant leurs claviers, aux bons développeurs qui cherchent des solutions.

Une histoire de culture, vraisemblablement...

[Gouyon]

Bah, il suffit de lire le manifeste agile, qui permet de répondre à ces assertions. Il a au moins le mérite de parler du projet, et pas seulement du développeur, qui n'en est qu'un maillon. Et de là à classer les développeurs entre très bons (forcément moi ) et les mauvais (les autres )...

Oui j'ai vu une présentation sur cette manière de travailler qui est assez originale et plutôt intéressante. Par contre ça va actuellement à l'encontre de toutes les doctrines managériales actuelles . Maintenant il faut voir ce que ça va donner dans le futur mais ça a le mérite de responsabiliser chacun. J'aime bien aussi le petit coté pervers de cette méthode où chacun se met sa propre pression

[maske]

Rien à redire sur cette étude.

Sauf peut-être que les entreprises préfèrent les mauvais développeurs, qui donnent l'impression de toujours travailler, en massacrant leurs claviers, aux bons développeurs qui cherchent des solutions.

Une histoire de culture, vraisemblablement...

Quelle étude ?

[jsnooper]

... sont probablement ceux qui se refusent à l'affirmer haut et fort ?

[fkylol]

Par contre ça va actuellement à l'encontre de toutes les doctrines managériales actuelles

Il faut croire que non étant donné le nombre d'adeptes.

[susanoo]

Je pense qu'il ne s'agit là que d'un avis personnel, pas d'une vérité générale!
Celà devrait surtout nous amener à nous remmettre un peu en question sur nos pratiques et plus que de se focaliser "bon" ou "mauvais" programmeur, il est plus important de

chercher perpétuellement à s'améliorer, c'est ça le crédo

[jsnooper]

Effectivement, que veulent réellement signifier les concepts d'être "bon" ou "mauvais" ?

Des personnes compétentes peuvent très bien être qualifiées de "mauvais" programmeurs pour diverses raisons, comme par exemple:

• La difficulté de s'intégrer dans une équipe ou se sont formés des clans,
• La préocupation unique de la hiérarchie ou du chef de projet de l'aspect financier d'un projet,
• La différence de culture au sein d'une équipe (ce qui revient à trahir un manque de management pour garder la cohésion de son équipe),
• Le fait que personne n'est parfais, mais jusqu'à quel point est-ce acceptable ?
• ...

Dans mon expérience, j'ai maintes fois remarqué des "bons" et des "mauvais", mais très souvent j'ai aussi constaté que les "bons" ne savent pas toujours qu'ils le sont et que les "mauvais" n'aspirent sincèrement qu'à mieux faire. Or, dans une organisation, la définition du "bon" et du "mauvais" peut être très facilement remise en cause, puisque ce n'est pas une notion qui semble être très bien définie en fonction des individus...

On peut donc se rabattre sur des critères dits "objectifs" en alignant des chiffres du nombre de lignes à coder, etc... Mais entre-nous, dites-moi entre ces 2 exemples (si l'on retient le critère du nombre de lignes de code), lequel est un code de "bon" programmeur et lequel est un code de "mauvais" programmeur (les exemples sont donnés en java et non commentés volontairement !) ?

A l'intention des non javaistes !
Cette méthode contrôle si un nombre quelconque entier est pair ou impair. Si le nombre est pair, la méthode retourne "true" donc la valeur booléenne "vrai", sinon elle retourne "false", donc la valeur booléenne "faux".

Exemple 1:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public boolean isEven(int number)
{
  int _val = number % 2;

  if(_val == 0)
   {
      return true;
   }

  return false;
}

Exemple 2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public boolean isEvent(int number)
{
   return (number % 2) == 0;
}

Merci pour vos commentaires.

[Xper4net]

Je n'ai pas compris ça (j'imagine que je suis un bleu donc...).

C'est pas une tare... Je considère que dans ce métier, on est "bleu" pendant au moins dix ans (pour les meilleurs).

Ce que je comprend, c'est que quand on est placé sur un projet déjà en retard, avec un budget très restreint, on a pas forcément le temps d'être encadré, on ne fait pas des choses toujours très propres et on fait des heures sup' parce qu'on est en retard comme tout le monde.

En 25 ans de métier, j'ai pas connu bcp de projets faciles...mais j'ai compris que souvent, pour rattraper un retard, il fallait... prendre son temps. Prendre le temps de l'analyse, de la projection à long terme, et surtout, de la réorganisation en couches (au minimum métier /présentation/contrôle), car à partir de 50000 lignes, si le code ne respecte pas ça, on ne s'en sort pas, et les retards continuent de s'accumuler.

Ce que je comprend aussi, c'est que l'informatique, c'est ça : des projets en retard (et s'ils ne le sont pas encore, ils le seront, parce que de toutes façons les commerciaux promettent toujours plus que la Lune aux clients).

Ca n'a pas toujours été vrai. Pendant longtemps, les techniciens étaient impliqués dans la phase commerciale, et les évaluations étaient grosso modo réalistes. Mais on constate depuis qq années une dévalorisation technique de la phase commerciale. Elle est volontaire et touche tous les secteurs : les têtes pensantes du commerce on établi que c'était rentable de mentir... Nous, techniciens, devont nous battre contre ça, en disant dès le début d'un projet : voilà sur quoi je peux m'engager, et mes engagements, je les tiens, pas vos engagements. Ce discours a, au début, du mal à passer, mais comme il implique que tu t'engages sur qq chose, tôt ou tard il te rend crédible.

Dès lors, quand on embauche un ingénieur, on attend de lui qu'il soit capable de se débrouiller sans avoir à être constamment chapeauté par un "architecte" et qu'il soit naturellement bon. Comme il sera en retard, cette notion de "bon" ou "moins bon" sera forcément discutable.

Dans ce métier, on n'est pas bon tout seul, on doit être bon en équipe. Une solution technique peut te paraître bonne et élégante pour résoudre ce que tu as à faire, mais mauvaise quand elle va être intégrée au projet. Il faut donc OBLIGATOIREMENT un référent, un chef d'orchestre.
Le "débrouillard" qui fait tout dans son coin sans en parler peut donc être une véritable catastrophe dans un projet, j'en ai connu qquns, et la plupart étaient vraiment "bons" techniquement parlant.
Dans mes équipes, les programmeurs avaient pris l'habitude de :
-ne jamais perdre plus d'une journée à trouver une solution technique : au-delà, ils venaient me demander. Au début, par fierté, certains s'acharnaient pendant trois jours avant de jeter l'éponge. Quand ils voyaient ensuite que j'avais tout de suite la solution, t'inquiète pas, ils avaient compris.
-de me soumettre la solution avant de l'appliquer : 2 fois sur 3, c'etait la bonne, parfois même elle était meilleure que ce à quoi j'aurai pensé. Mais 1 fois sur 3, elle avait un défaut plus ou moins grave qui aurait tôt ou tard plombé le projet.
Ceux qui n'avaient pas le pli le prenaient vite, car je faisais des revues de code régulières et je leur expliquais pourquoi ils avaient pris un mauvais chemin, et je leur faisais refaire... mais tous finissaient par trouver ce mode de fonctionnement logique et confortable, à part 2 fois en 25 ans (des irréductibles qui ont par la suite été d'échecs en échecs).

Bref, faut arrêter avec les "bons" et les "mauvais", la vérité, c'est que, bien encadré, le niveau moyen est assez homogène. Il y a qq surdoués et qq sous-doués, mais ils sont très rares.
Mal encadrés, les comportements sont plus hétérogènes et sont en fait fonction de la personnalité, les fameux "débrouillards" ayant alors l'air de tirer leur épingle du jeu (tant que le projet n'est pas trop gros), tandis que d'autres peuvent carrément partir en panique et faire n'importe quoi. Mais si tu m'as compris, ça veut pas dire que les premiers soient bons, ni que les seconds soient mauvais...

[Xper4net]

On peut donc se rabattre sur des critères dits "objectifs" en alignant des chiffres du nombre de lignes à coder, etc... Mais entre-nous, dites-moi entre ces 2 exemples (si l'on retient le critère du nombre de lignes de code), lequel est un code de "bon" programmeur et lequel est un code de "mauvais" programmeur (les exemples sont donnés en java et non commentés volontairement !) ?

A l'intention des non javaistes !
Cette méthode contrôle si un nombre quelconque entier est pair ou impair. Si le nombre est pair, la méthode retourne "true" donc la valeur booléenne "vrai", sinon elle retourne "false", donc la valeur booléenne "faux".

Exemple 1:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public boolean isEven(int number)
{
  int _val = number % 2;

  if(_val == 0)
   {
      return true;
   }

  return false;
}

Exemple 2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public boolean isEvent(int number)
{
   return (number % 2) == 0;
}

Merci pour vos commentaires.

De mon point de vue : aucune importance. La seconde écriture témoigne simplement d'un peu plus d'expérience. Mais dans les deux cas la fonction fait le job, et c'est tout ce qu'on lui demande.
Ce qui serait grave, ce serait par exemple de créer qq part "IsEvent", et ailleurs "IsOdd", ou "IsNumberEvent", bref, plusieurs fonctions pour faire le même job, dégradant ainsi la maintenabilité du code.
Dans mes premières années de programmation, j'étais moi aussi attaché à l'efficacité et la concision. Je me suis rendu compte ensuite que c'était loin d'être primordial. C'est même carrément secondaire.
A noter quand même que la plupart des outils de vérification de code tiqueraient sur la première écriture (plus d'un return dans la fonction). A un moment, on utilisait ce type d'outil dans les process (me rappelle plus le nom, faudrait que je recherche) pour qualifier le code. Au final, bcp de temps passé, mais vraiment peu de retombées positives...
Faut vraiment rester concentré sur la conception et le respect des règles d'architecture (ISP, ADP, LSP, SDP, SAP, OCP, CCP, CRP, REP), c'est dix mille fois plus important.

[Gluups]

Tout-à-fait vrai (le texte en début de fil).

Vrai aussi que ça paraît incohérent de conseiller d'être prêt à réécrire constamment son code, après avoir consenti des efforts pour qu'il s'adapte partout.

Après qu'on ait dit "it is not a bug, it is by design", on ne va pas se gêner pour dire qu'il peut être bon d'adapter un code, sans pour autant que ça oblige à tout réécrire. D'ailleurs en faisant ça on doit être attentif à rester compatible avec les appels existants. Si je ne m'abuse Developpez a écrit une chronique là-dessus l'année dernière.

En étant attentif à écrire du code réutilisable et à le répertorier de façon à le retrouver, on élimine une bonne partie des causes d'échec. Ensuite, on ne se débarrasse pas des causes inhérentes au client, entre celui qui vous impose une méthode d'évaluation ultra-lourde reposant sur des indices impossibles à obtenir et qui ainsi vous empêche de travailler, celui qui n'a pas l'aval de sa hiérarchie et qui se fait taper sur les doigts à la fin du projet, n'ayant pas anticipé des changements dans l'énoncé du problème ...

Alors prendre de la hauteur, perte de temps ?
Il y a peu j'aurais pu engager une mise en cause sur la question, mais en ce moment, le marché de l'emploi étant ce qu'il est, je suis avec quelqu'un qui envisage sans sourciller de charger dix fichiers qui vont mettre deux heures à se charger et tout planter au moindre incident réseau, pour des informations dont seul le dernier dixième évolue, plutôt que de mettre sur pied un mode de mémorisation, et ça juste pour économiser une demi-journée de développement au début. Alors forcément, on gagne sa vie comme en Inde.

[maske]

C'est pas une tare... Je considère que dans ce métier, on est "bleu" pendant au moins dix ans (pour les meilleurs).

Ce qui est discutable en fait est surtout le lien de cause à effet du précédent post souligné par la citation que tu fais.

En 25 ans de métier, j'ai pas connu bcp de projets faciles...mais j'ai compris que souvent, pour rattraper un retard, il fallait... prendre son temps. Prendre le temps de l'analyse, de la projection à long terme, et surtout, de la réorganisation en couches (au minimum métier /présentation/contrôle), car à partir de 50000 lignes, si le code ne respecte pas ça, on ne s'en sort pas, et les retards continuent de s'accumuler.

Je pense que tout le monde est d'accord. Sauf les chefs (non techniques) bien souvent, donc le temps on ne l'a quand même pas. Rien ne change.

En outre, c'est bien gentil de compter les lignes de code, mais la complexité du système joue autant (voir plus).

Ca n'a pas toujours été vrai. Pendant longtemps, les techniciens étaient impliqués dans la phase commerciale, et les évaluations étaient grosso modo réalistes. Mais on constate depuis qq années une dévalorisation technique de la phase commerciale. Elle est volontaire et touche tous les secteurs : les têtes pensantes du commerce on établi que c'était rentable de mentir... Nous, techniciens, devont nous battre contre ça, en disant dès le début d'un projet : voilà sur quoi je peux m'engager, et mes engagements, je les tiens, pas vos engagements. Ce discours a, au début, du mal à passer, mais comme il implique que tu t'engages sur qq chose, tôt ou tard il te rend crédible.

Il me semble que ça fait quand même 40 ans qu'on cherche à faire des choses de plus en plus complexes en moins en moins de temps. A l'échelle de l'informatique qui est un domaine "jeune", ça fait presque une éternité.

Quand on a la chance d'avoir une hiérarchie à l'écoute, le technicien a tout intérêt à s'imposer pour trouver un compromis.

Mais on ne peut raisonnablement pas dire que c'est le cas de tout le monde.

Dans ce métier, on n'est pas bon tout seul, on doit être bon en équipe. Une solution technique peut te paraître bonne et élégante pour résoudre ce que tu as à faire, mais mauvaise quand elle va être intégrée au projet. Il faut donc OBLIGATOIREMENT un référent, un chef d'orchestre.
Le "débrouillard" qui fait tout dans son coin sans en parler peut donc être une véritable catastrophe dans un projet, j'en ai connu qquns, et la plupart étaient vraiment "bons" techniquement parlant.
Dans mes équipes, les programmeurs avaient pris l'habitude de :
-ne jamais perdre plus d'une journée à trouver une solution technique : au-delà, ils venaient me demander. Au début, par fierté, certains s'acharnaient pendant trois jours avant de jeter l'éponge. Quand ils voyaient ensuite que j'avais tout de suite la solution, t'inquiète pas, ils avaient compris.
-de me soumettre la solution avant de l'appliquer : 2 fois sur 3, c'etait la bonne, parfois même elle était meilleure que ce à quoi j'aurai pensé. Mais 1 fois sur 3, elle avait un défaut plus ou moins grave qui aurait tôt ou tard plombé le projet.
Ceux qui n'avaient pas le pli le prenaient vite, car je faisais des revues de code régulières et je leur expliquais pourquoi ils avaient pris un mauvais chemin, et je leur faisais refaire... mais tous finissaient par trouver ce mode de fonctionnement logique et confortable, à part 2 fois en 25 ans (des irréductibles qui ont par la suite été d'échecs en échecs).

Bref, faut arrêter avec les "bons" et les "mauvais", la vérité, c'est que, bien encadré, le niveau moyen est assez homogène. Il y a qq surdoués et qq sous-doués, mais ils sont très rares.
Mal encadrés, les comportements sont plus hétérogènes et sont en fait fonction de la personnalité, les fameux "débrouillards" ayant alors l'air de tirer leur épingle du jeu (tant que le projet n'est pas trop gros), tandis que d'autres peuvent carrément partir en panique et faire n'importe quoi. Mais si tu m'as compris, ça veut pas dire que les premiers soient bons, ni que les seconds soient mauvais...

Il y a une nette différence entre être dépendant d'un "architecte" et travailler en équipe.

La débrouillardise qu'on attend d'un ingénieur (avec l'indépendance qui suit) est de s'intégrer dans une équipe et de savoir communiquer - sur ce point on est d'accord, mais pas sur les mots.

[jsnooper]

De mon point de vue : aucune importance. La seconde écriture témoigne simplement d'un peu plus d'expérience. Mais dans les deux cas la fonction fait le job, et c'est tout ce qu'on lui demande.
Ce qui serait grave, ce serait par exemple de créer qq part "IsEvent", et ailleurs "IsOdd", ou "IsNumberEvent", bref, plusieurs fonctions pour faire le même job, dégradant ainsi la maintenabilité du code.
Dans mes premières années de programmation, j'étais moi aussi attaché à l'efficacité et la concision. Je me suis rendu compte ensuite que c'était loin d'être primordial. C'est même carrément secondaire.
A noter quand même que la plupart des outils de vérification de code tiqueraient sur la première écriture (plus d'un return dans la fonction). A un moment, on utilisait ce type d'outil dans les process (me rappelle plus le nom, faudrait que je recherche) pour qualifier le code. Au final, bcp de temps passé, mais vraiment peu de retombées positives...
Faut vraiment rester concentré sur la conception et le respect des règles d'architecture (ISP, ADP, LSP, SDP, SAP, OCP, CCP, CRP, REP), c'est dix mille fois plus important.

Nous touchons un point intéressant ici sur la problématique de concision du code. Je me suis toujours demandé jusqu'à quelle limite la concision pouvait être utilisée et son degré d'importance.

Tu écris :

... Mais dans les deux cas la fonction fait le job, et c'est tout ce qu'on lui demande.

Puis plus loin

... Dans mes premières années de programmation, j'étais moi aussi attaché à l'efficacité et la concision. Je me suis rendu compte ensuite que c'était loin d'être primordial. C'est même carrément secondaire.

Pendant quelques temps j'avais aussi adopté ce point de vue, or ces dernières années je reviens sur cette affirmation après avoir été arrosé plusieurs fois par du code type du premier exemple donné dans mon message précédent. Le problème est que la maintenance de code devient très ardue, car il s'agit pour la personne qui débarque dans un projet de faire un gros effort intellectuel pour ne pas perdre le fil du code dont il prend connaissance. Parfois, on se demande même si dans un tel code, ne se cacherait pas autre chose que nous n'aurions pas compris.

Il est vrai que nous avons aussi l'extrême inverse, probablement mieux connu, d'une trop grande concision qui conduit à une écriture énigmatique du code. Au final ce n'est pas mieux que du code verbeux.

Aussi, à la lumière de ta réponse, et de celles des autres personnes sur ce forum, il est clair qu'une règle de concision doit exister dans l'écriture de son code, le tout étant de savoir où l'on doit s'arrêter. Et là c'est aussi un autre problème : comme la limite dépend de beaucoup du point de vue de chacun, il est évident que nous n'aurons jamais de "bon" code qui permettra de définir un "bon" programmeur et donc aussi par conséquent un "mauvais". Néanmoins 2 règles peuvent être empiriquement définies et suivies (après plusieurs années d'application de ces règles les résultats sont globalement bien acceptés par beaucoup) :

1. La vie est très compliquée : simplifiez, simplifiez, simplifiez...
2. Vous n'écrivez pas du code pour vous mais pour les autres

La première règle est inspirée d'un auteur dont j'ai malheureusement oublié le nom ! La deuxième est le fondement même du vrai travail d'équipe.

Le travail du développeur, ce qui fera sa compétence et son métier (entre autre chose), étant de trouver le juste milieu entre ces 2 règles.

[Xper4net]

Un dernier petit commentaire à l'attention de ceux qui ont pris la peine de me répondre.
@maske :
1/ Dans ce métier, on n'a pas le choix. Soit on impose ses idées, soit on subit celles des autres, et faut pas venir se plaindre. La culture du semi-échec récurrent, dont tu te fais le porte-parole un peu désabusé n'est pas une fatalité, mais malheureusement elle conduit souvent à "laisser-faire", avec dans l'inconscient : "si ça foire, au moins ce ne sera pas de ma faute". Mauvais calcul : y'en aura toujours des plus forts que toi quand il faudra se dédouanner. Et de toute façon, dans une équipe qui perd, personne ne sort grandi.
Même si on n'y arrive pas toujours, surtout face à des non-techniciens, faut toujours se battre pour convaincre, quitte à se faire virer du projet (je parle d'expérience). C'est mon conseil, après c'est toi qui voit.

2/ A qualité d'écriture et de conception égale, il y a une relation directe entre nombre de lignes et complexité, c'est pas moi qui le dit.... Le chiffre de 50KLOC est bien sur une moyenne. C'est à partir de là que le cerveau humain n'arrive plus à appréhender en permanence l'ensemble, et que les artefacts de conception (schémas UML) deviennent indispensables pour maintenir la cohérence.

Le deux + gros softs que j'ai conçus atteignaient 1MLOC. Ils ont tous les deux été livrés dans les délais & sans dépassement de budget. C'est impossible à faire sans architecte référent. Enfin moi j'ai jamais vu.

Travailler en équipe sans architecte, ça va pour les petits projets, pour les autres c'est retard assuré, voir pire.
C'est marrant, dans les autres industries, il ne viendrait pas à l'idée de contester ça (on peut faire sa cabane au fond du jardin sans architecte, mais pas un building), mais dans l'informatique, c'est vraiment pas encore acquis, t'es pas le premier à se montrer dubitatif.

@jsnooper : je suis d'accord, faut savoir positionner le curseur, et c'est d'ailleurs en ça que les outils de vérification de code peuvent être utiles, comme les relectures croisées : ça homogèneïse l'écriture.
Mais, à part pour une recherche ponctuelle de performance pour un bout de code critique, ça fait longtemps que je ne m'excite plus sur un gazier qui écrit du code à rallonge ou au contraire, comme tu dis, énigmatique. Dès l'instant que les interfaces sont claires et respectent le design, c'est tout ce qui m'importe. Après, je sais qu'en prenant de la bouteille, et à force de voir le code des autres, il va progresser...

[Drawingrom]

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 !
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 ?

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.

[popo]

Réinventer la roue, refaire un existant à sa propre sauce, c'est tellement jouissif!
Problème : ça n'apporte rien à l'utilisateur. Le développeur qui fait ça est donc un mauvais développeur. En tout cas c'est ce qui sera retenu.

ç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 !

[Xper4net]

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

[Pergos]

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