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 !

Qu'est-ce qu'un bon code ? Une étude tente d'apporter des éléments de réponse

Le , par Olivier Famien

283PARTAGES

7  1 
Qu’est-ce qui fait bon code ?
Qu’est-ce qu’un bon code ? À maintes reprises, chacun de nous s’est déjà posé une telle question ou du moins s’est déjà vu poser cette question. Déjà en 2004, Paul Dilascia tentait de répondre à cette même question dans le magazine MSDN. Pour lui, un bon code doit fédérer 8 critères qui sont la simplicité, la lisibilité, la modularité, la séparation des différentes couches fonctionnelles, le design, l’efficacité, l’élégance et la clarté.

L’entreprise IntentHQ qui travaille à apporter des réponses à certaines problématiques a voulu donner également un élément de réponse basé non pas sur une définition personnelle, mais plutôt sur des éléments scientifiques.

Pour y arriver, elle a mis en œuvre une étude de janvier 2014 à janvier 2015 en interrogeant 65 développeurs directement ou par téléphone lors de plusieurs entretiens d’embauche. Les entretiens ont été effectués par la même personne et s’adressaient en général à des personnes ayant de solides compétences en java ou scala avec plus de cinq années d’expérience.

Il faut souligner que même si les réponses peuvent varier d’un individu à un autre, nous sommes d’accord pour affirmer qu’un bon code comporte plusieurs avantages. Il permet par exemple de respecter le cahier de charges, d’éviter certaines erreurs qui rallongeraient les délais de livraison du projet et donc satisfaire ceux qui nous ont mandatés.

Lors de cette étude, deux questions fondamentales ont été posées. À votre avis, qu’est-ce qui participe à bonifier la qualité du code ? Comment définissez-vous un bon code ?

Les réponses à ces questions ont permis de dégager un grand nombre de réalités pouvant être regroupées sous 31 vocables. Bien qu’il soit difficile d’aborder ici tous les ingrédients de qualité relevés par l’étude, nous nous sommes focalisés sur les cinq premiers critères évoqués par les 65 développeurs interrogés. Pour chaque critère, un pourcentage a été obtenu et se présente de la manière suivante :

En première position, nous avons la lisibilité et la compréhension. En effet, 78,46 % des personnes interrogées affirment que le code doit être lisible et compréhensible. Ce qui signifie que 8 personnes sur 10 sont d’accord sur le fait qu’un bon code doit être facile à lire et à comprendre.

En seconde position, nous avons les tests. 29,23 % des développeurs estiment que le code doit être testé ou au moins doit supporter des tests automatisés.

Ce même ratio suggère également que le code doit être fonctionnel.

21,54 % estiment qu’il doit être facile d’appliquer des modifications, des corrections, des ajouts à un code sans en ressentir une perte de performance ou une dégradation de la qualité. En somme, qu’on puisse effectuer aisément la maintenance.

En dehors de ces cinq premiers critères, nous avons entre autres, la présence des commentaires dans le code et le facteur réutilisable. Environ 11 personnes sur les 65 interrogées s’attachent à ces deux critères. Pour plus de détails sur l’ensemble de l’étude, vous pouvez vous référer au tableau suivant.


Il faut noter qu’une corrélation forte existe entre les différents points mentionnés. Par exemple, un code simple, lisible, facile à comprendre favorisera forcément une maintenance plus aisée. À contrario, des heures seront nécessaire pour trouver des erreurs ou pour inclure de nouvelles fonctionnalités dans un code. Et cela est vrai aussi bien pour l’auteur du code que pour une tierce personne travaillant sur le code.

C’est pourquoi IntentHQ, en se basant sur les critères les plus pertinents, c’est-à-dire les cinq premiers en raison de leur évocation par plus de 20 % des interrogés, a défini un bon code comme suit : « un bon code doit être écrit de telle sorte qu’il soit lisible, compréhensible, couvert par des tests automatisés, pas trop compliqué et effectuant parfaitement ce pour quoi il a été écrit ».

En apportant une définition à ce concept, IntentHQ donne ainsi les normes d’un bon code. Nous espérons qu’elle fera l’unanimité et achèvera de clore le débat sur ce sujet.

Source : Blog IntentHQ

Et vous ?

Que pensez-vous de cette étude?
Etes-vous d'accord avec la définition obtenue?
Quelle définition personnelle avez-vous d'un bon code?

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

Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 13/03/2015 à 9:32
Un bon code, c'est un code qui a été développer en pensant: "La personne qui va le maintenir est un psychopathe meurtrier qui connaît mon adresse"

9  0 
Avatar de ustensile
Membre régulier https://www.developpez.com
Le 16/03/2015 à 14:56
C'est juste une question de point de vue, pour certaines personnes, un bon code:

- doit être assez complexe pour que le client ne puisse pas le modifier seul
- ne doit évidement pas être commenté, ce serait trop facile (on peut aussi commenter avec des conneries)
- ne doit fonctionner que dans les cas généraux de base décrits par le cahier des charges
- doit fonctionner un minimum au moment de la recette
- ne doit pas forcément être compatible en cas d'upgrade
- doit pourvoir faire l'objet d'un devis pour modification à tout moment
- doit permettre de tester le niveau des stagiaires ou des nouveaux arrivants
- permet de repérer les bons commerciaux
9  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 12/03/2015 à 20:24
Voici ce que m'inspire le sujet ^^

7  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 13/03/2015 à 10:53
Désolé, je ne connaissait pas l'auteur original.

J'avais juste entendu une tel phrases lors d'une conférence (Agile Grenoble 2013), prononcé par un conférencier Belge : Pascal Van Cauwenberghe (désolé, je n'ai pas retransmis l'accent )
5  0 
Avatar de Grimly
Membre averti https://www.developpez.com
Le 13/03/2015 à 16:01
Citation Envoyé par Saverok Voir le message
Tu compares des choses qui n'ont rien à voir
D'un côté le "goût" qui est notion totalement subjective
Et de l'autre "la qualité du code" qui est notion technique dont il existe des indicateurs pour le mesurer.
Le débat sur le code porte sur l'importance à donner à chaque indicateur mais cela reste objectif.

Alors que "les goûts et les couleurs"...
Le code est aussi une question de goût et même de mode.

Il y a quelques années, personne n'aurait eu l'idée de maintenir un site qui aurait une partie de javascript, toute page qui en contenait était considéré comme mal codée. La soumission de formulaires était la norme et signe de "bon code maîtrisé".
Maintenant, une page sans javascript géré entièrement par le serveur ça fait vieux, personne n'en veux et on entends "pourquoi tu ne fais pas un $.ajax() ? C'est plus joli !".

De même, bien documenter un code est subjectif. Si tu décris chaque partie d'un algorithme dans tes fonctions, tu fais ce qu'il faut pour une personne allergique aux documents annexes (wiki/docs), mais celui qui a plus l'habitude d'avoir sa documentation sur son deuxième écran voit ce même deuxième écran inutile et ça ne lui plait donc pas.

Enfin, il m'arrive de réaliser du code que je trouve bon au moment où je l'écris, mais quelques mois plus tard quand je doit y replonger, je trouve que j'aurais pu largement mieux faire si j'avais fait complètement autrement. Je doute que je soit le seul dans cette situation.
5  0 
Avatar de Gumichan01
Membre régulier https://www.developpez.com
Le 12/03/2015 à 17:54
J'ai envie de dire que ça dépend des besoins.

Évidement que le code doit quand même être lisible et commenté, surtout quand on sait que quelqu'un va peut-être y jeter un œil dans 6 mois.
Et le côté fonctionnel me parait évident. Faire un code source qui ne marche pas relève pour moi d'un non-sens.

Par contre pour le côté test je trouve ça discutable (en même temps certaines personnes interrogées sont des devs Java). Perso quand je programme, je teste directement la fonction ou la classe. Si ça marche comme je le veux, j'intègre la prise en charge des cas problématiques, si nécessaire. Si ça ne fonctionne pas, je corrige pour que ce soit fonctionnel. Pour ce qui est de la réutilisabilité, tout dépend des besoins là encore.

En gros le minimum vital serait :

"un bon code doit être écrit de telle sorte qu’il soit lisible, compréhensible, couvert par des tests automatisés, commenté un minimum, documenté au mieux, pas trop compliqué et effectuant parfaitement ce pour quoi il a été écrit"

Pour finir, 65 personnes qui ont des connaissance en Java OU Scala (le OU logique ^^) ce n'est pas pertinent (et les autres il n'existent pas ?).
4  0 
Avatar de AoCannaille
Membre émérite https://www.developpez.com
Le 13/03/2015 à 10:40
Citation Envoyé par Laurent 1973 Voir le message
Un bon code, c'est un code qui a été développer en pensant: "La personne qui va le maintenir est un psychopathe meurtrier qui connaît mon adresse"

Merci de citer son auteur
Citation Envoyé par John Woods
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”

et quitte à choisir une citation, je citerais plutôt Knuth :
Citation Envoyé par Donald Ervin Knuth
“The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct.”
4  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 12/03/2015 à 20:50
Citation Envoyé par Olivier Famien Voir le message
Quelle définition personnelle avez-vous d'un bon code?
Facile : c'est du code que j'ai écrit, bien sûr . Pour tout développeur qui se respecte, le code des autres est toujours mauvais

Parmi les critères proposés dans le sondage, j'ajouterais "bien découplé". Mais bon, ça va de pair avec la testabilité et la maintenabilité.

Pour ce qui est des commentaires, je ne pense pas qu'ils soient indispensables en règle générale. Un bon code est généralement compréhensible juste en le lisant, il est "auto-documenté". Après il y a bien sûr des cas particuliers, par exemple un algorithme particulièrement complexe, ou un hack dégueulasse qu'on a été obligé de faire pour résoudre un problème dont l'origine est externe à notre code; dans ces cas là, les commentaires s'imposent.
3  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 13/03/2015 à 13:33
Citation Envoyé par Grimly Voir le message
Il n'y a pas, objectivement, de "bon" code.

Pour illustrer ma petite phrase je vous propose ce problème :
J'aime le chocolat noir, je trouve ça bon.
Mais ma copine trouve le chocolat noir trop amère, plus que mauvais même ! Elle préfère très largement le chocolat blanc.
Est-ce que le chocolat noir est bon ?
Tu compares des choses qui n'ont rien à voir
D'un côté le "goût" qui est notion totalement subjective
Et de l'autre "la qualité du code" qui est notion technique dont il existe des indicateurs pour le mesurer.
Le débat sur le code porte sur l'importance à donner à chaque indicateur mais cela reste objectif.

Alors que "les goûts et les couleurs"...
3  0 
Avatar de gabriel.klein
Membre régulier https://www.developpez.com
Le 16/03/2015 à 8:57
Un bon code répond avant tout aux besoins de l’utilisateur Il répond aux désirs de l’utilisateur.

Du "quick and dirty" est acceptable dans certains cas! Par exemple pour tester un concept avant de le construire. Parfois c'est totalement pas acceptable - par exemple si on doit contrôler un avion.

Personnellement j'ai plusieurs niveaux de "maturité" dans mes projets - certaines parties du projet sont testées, d'autres faites pour être rapidement remplacées - et c'est comme ça que je gère un bon code.

Certaines parties ne sont pas encore bien définies par l’utilisateur - donc c'est plutôt du "quick and dirty" au niveau qualité. Pouvoir "jouer avec l'application" permet aux utilisateurs de mieux définir ce qu'ils veulent.
3  0