Discussion :

[chaplin]

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.

[parou]

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

[Gouyon]

- 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

- 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

[roudoudouduo]

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.

[Marco46]

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

[roudoudouduo]

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.

[sshpcl2]

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

[bruneltouopi]

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

[Invité]

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