IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 !

Trouvez-vous souvent le code des autres mauvais ?
Une développeuse décrit l'évolution de sa perception et prône l'humilité

Le , par Idelways

48PARTAGES

9  1 
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). Elle 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 code 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 modé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, qualifié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 trouvant systématiquement meilleur que ses confrères.

Une modération qui se ferait (trop) rare ?

Et vous ?

Votre travail a-t-il été injustement critiqué par un tiers ? Comment faites-vous pour protéger votre réputation en livrant vos sources ?

Trouvez-vous souvent (systématiquement) le code source des autres mauvais ? Ou en tout cas moins bon que ce que vous auriez pu faire ?
Comment expliquez-vous ce phénomène ? Est-il lié au genre (homme-femme) ou pas du tout ?

Source : Your code sucks

En collaboration avec Gordon Fowler

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

Avatar de sevyc64
Modérateur https://www.developpez.com
Le 07/09/2010 à 13:37
Il faut effectivement faire la différence entre du code vraiment mauvais et du code "Pas-Comme-Je-L'aurais-Fais-Moi"

Le premier est assez reconnaissable et jugé unanimement par une majorité de développeur. Généralement d'ailleurs, il n'y a pas besoin d'analyser les contraintes du projet pour le reconnaitre mauvais, et toutes les parties de code, même les plus simples souffrent du même défaut ainsi que tous les code du même auteur.

Pour le second, il peut effectivement arrivé de l'analyser comme mauvais parce que tout simplement dans la première impression, on en comprend pas la logique.Mais tout bon développeur, dans ce cas, essaiera de comprendre ce code avant d'avoir un jugement définitif. Et les cas ne sont pas rare de s'appercevoir que, même si c'est pas codé comme on l'aurait fait non même, le code n'en reste pas moins bon, voire original, et même parfois meilleur que ce que l'on aurait pu faire.
5  1 
Avatar de mlezzoum
Futur Membre du Club https://www.developpez.com
Le 13/09/2010 à 11:40
Un développeur est :
soit chevronné - professionnel
soit initié
soit débutant

Etre chevronné professionnel et porter un jugement de valeur sur un développeur
débutant c'est une remise en cause du chevronné lui même.

Etre débutant et porter un avis négatif sur le code d'un chevronné, c'est un long parcours qui lui reste à faire le débutant, surement il changera de métier au cours de route.

Etre initié c'est regarder au dessus le chevronné avec un respect de l’élève qui apprend, et présenter un sagesse en baissant le regard pour voir les premiers pas du débutant.

Le secret de l'expert est de garder le silence et aider les autres et par modestie l'expert est désigné par la troisième personne du singulier.

que delphi soit avec vous. ( mes respects pour delphiprog au passage)
4  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 07/09/2010 à 14:16
J'ai l'impression de voir souvent des trucs pas terribles.

Ce que j'en sais c'est qu'il est parfois (trop) facile de juger un travail fini sans avoir connu le contexte réel de celui-ci.
J'essaie toujours de me mettre dans la situation de la personne, avait-elle prévu un certain design et ensuite des modifications imprévues en dernière minute l'aurait forcée à faire des compromis? Ceci ajouté au manque de temps, délais pressants, intégration à l'existant etc...

Qui ne s'est jamais dit : "tiens j'aurai pu faire comme ci, gérer ça autrement etc..." après coup à la fin d'un projet?

Niveau code, mon seul critère est qu'il soit écrit de façon simple, des méthodes assez courtes, facilement unit-testable avec un rôle bien défini et une gestion d'erreur propre.
3  0 
Avatar de bugsan
Membre confirmé https://www.developpez.com
Le 07/09/2010 à 16:28
Je suis un peu étonné.

Il y a pourtant des critères objectifs pour juger un code source, un tas d'outils, de bonnes pratiques, un tas de livres écrits par les Guru de l'informatique. Et avec les années les anti-patterns de conception et d'architecture sont de mieux en mieux connus.

- Single responsibility / Separation of concerns
- Open/closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
- Don't repeat yourself
- Keep it simple, Stupid
- PMD
- Checkstyle
- Findbugs
- etc ...

Liste exhaustive (très intéressante au passage) :
http://en.wikipedia.org/wiki/List_of...t_philosophies
http://en.wikipedia.org/wiki/Anti_pattern

La lisibilité du code n'est pas non plus quelque chose de subjectif. Ce que l'on appelle le "relearning", où comment écrire son code de façon à réduire le temps nécessaire à le réapprendre des mois plus tard (pour s'y replonger).

Bien sur aucun code n'est parfait et je suis très loin d'appliquer moi même tout ce que je viens d'énumérer.
Dire qu'un code source est "tordu" ou "mauvais" n'est pas un argument acceptable à mon avis. Il faut pouvoir expliquer pourquoi, de façon rationnelle.
5  2 
Avatar de Népomucène
Modérateur https://www.developpez.com
Le 08/09/2010 à 11:56
Un code peut être propre au début ... et devenir un tas de boue par la suite :
Il y a quelques semaines, je commence un développement en java avec
cahier des charges, spécifications, structure claire de la base de données.
Le paradis
Je livre, le client l'utilise, ça marche après le débogage d'une fonctionnalité.

Il y a 10 jours, patatras : le client demande de modifier en urgence l'application
car ses contraintes ont changés (mais pas son budget).

Hier je viens donc de commettre plusieurs crimes informatiques dans le code
pour que le client puisse travailler comme il le souhaite ... sans changer le budget

Maintenant si quelqu'un regarde le code, il va hurler.

Je crois que les évolutions d'application sans les moyens nécessaires provoquent du code pourri.
3  0 
Avatar de ymoreau
Membre émérite https://www.developpez.com
Le 11/04/2011 à 13:48
C'est un vaste débat que tu ouvres, mais je dirais que dans l'opinion générale le cout de développement est bien plus cher que le cout d'exécution. Avec les machines qu'on a de nos jours les optimisations au niveau code (et pas au niveau architecture ou conception) sont, je pense, négligeables en gain d'exécution. Alors que la compréhension du code peut faire gagner beaucoup temps pour ceux qui devront le faire évoluer, et ce temps là coute cher (au client aussi d'ailleurs).
3  0 
Avatar de CheryBen
Membre chevronné https://www.developpez.com
Le 07/09/2010 à 13:14
Citation Envoyé par Idelways Voir le message

Comment expliquez-vous ce phénomène ? Est-il lié au genre (homme-femme) ou pas du tout ?
C'est bien connu que les femmes ne savent pas coder. ...

Les langages évoluent également, il arrive parfois que l'on tombe sur du très vieux code, écrit à l'époque avec les possibilités offertes par le langage.
Par exemple je travail sur un projet dont les 1ères classes ont été faites en java 1.2, et maintenant on utilise la version 1.5. Il y a eu énormément de nouveautés depuis qui facilitent la vie du développeur ou améliorent la syntaxe.
2  0 
Avatar de JeffPalmier
Membre régulier https://www.developpez.com
Le 07/09/2010 à 14:04
Il est vrai que des fois, on tombe sur un code qui parait assez "dégeu" au premier abord, mais en fait, on se rend compte que c'était la seule solution pour que tout tourne nikel.

On s'est tous retrouvé confronté à des erreurs incompréhensibles, et une fois que ça marche, même si c'est super sale, on le laisse, ça marche lol
4  2 
Avatar de killruana
Candidat au Club https://www.developpez.com
Le 07/09/2010 à 16:31
Dans la boite où j'ai bossé cet été le code du boss était vraiment horrible. Mais pas dans la logique, car au contraire, son code révélait une certaine intelligence et réflexion (quoi que des fois... ), mais la présentation était horrible Entre le nom des variables à un caractère, les indentions aléatoires, les accolades placés au petit bonheur la chance... -_-'
De l'autre coté y'avait le stagiaire SupInfo de 4eme année qui apprenait le PHP. Le code était présenté nickel (enfin, si on aime la notation BSD), mais point de vu logique c'était parfois un peu funky
Mais que voulez-vous faire dans ces conditions ?
2  0 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 07/09/2010 à 19:46
Citation Envoyé par verbose Voir le message
Je n'ai pas encore une grande expérience, mais j'ai pu constater que bien souvent, lorsque le code est mauvais, c'est soit parce qu'il n'a pas été modélisé ou du moins fait l'objet d'une réflexion quant à son architecture, soit parce que plusieurs développeurs sont passés par là avec chacun sa propre vision du problème.
Dans mon cas, à chaque fois que je trouve le code mauvais, c'est parce que les gens réinventent la roue.

L'autre jour, j'ai par exemple eu un ticket sur le dev d'un collège qui consistait à faire de la pagination de resultat.

Autant ma première reaction a été de savoir comment le faire avec le framework, autant la sienne a été de coder directement une pagination faite maison.
Bref, le truc que je devais developper allait me prendre des heures le temps de comprendre son code, donc j'ai écrit 2 lignes de code qui remplacait son code pour mettre en pagination automatique et zou, c'était fini.(il fallait ajouter un tri par colonne)

On a le même genre de problème avec l'emplacement du code, tout dans la vue par exemple.

Et en général, plus les gens tapent vite, moins ça va bien.
A contrario, plus ils utilisent un papier et un crayon, plus ça se passe bien.
2  0