Discussion :

[Idelways]

Faut-il optimiser son code ou le garder lisible ?
La baisse des coûts de stockage va-t-il influencer votre manière de développer


Ayende Rahien, de son vrai nom Oren Eini, est un développeur .NET connu, qui participe également à de nombreux projets open-sources (NHibernate, Castle et Rhino Mocks).

Sur son blog, très technique (mais passionnant), un de ses billets vient de soulever une question très intéressante.

Son poste est intitulé, plutôt ironiquement, " Vous avez gagné 5 centimes, mais votre code est illisible, félicitations ".

Il critique dans ce billet le choix d'un confrère qui relate le passage d'un projet de MySQL à MongoDB.

Si MySQL ne stocke pas le nom des colonnes avec les données, MongoDB, le fait pour chaque ligne.
En raccourcissant le nom des colonnes à 2 ou 3 caractères, le développeur en question se réjouit d'avoir réduit de 140 mégas la taille de sa base de données.

Un chiffre qui n'impressionne pas Rahien. Au contraire, il fait un calcul simple.

Selon lui, l'espace disque libéré ne vaut pas plus de 0.05 dollar (le disque de 2 To coûte environ 120 dollars).

Alors qu'une seule minute du temps d'un développeur coûterait 0.62 cents. Soit 12 fois plus que ladite économie en espace disque.

Mais si le billet Rahien ne traite que de ce cas précis de bases de données, le même principe peut être appliqué au développement.

Une application écrite différemment peut économiser un serveur de production ou deux. Mais sa lisibilité, son évolutivité et sa facilité à être maintenu peuvent être compromises.

Et entrainer des coûts supplémentaires.

Ce billet d’Oren Eini a au moins le mérite de poser la question. Code clair (et un peu plus lourd) contre code optimisé (et illisible). Chaque école apportera sa propre réponse.

Et vous ?

De quelle école êtes-vous ? Celle du code lisible ou au contraire, préférez-vous l'optimisation des performances ?

Pensez-vous qu'il soit possible de faire les deux ?

Source : blog de Ayende Rahien


En collaboration avec Gordon Fowler

[noOneIsInnocent]

Bonjour

Je trouve que la question est très mal posée car cela sous-entends que l'on n'est pas capable de faire du code optimisé et lisible.
C'est loin d'être incompatible surtout si le code est bien commenté.

[MigouW]

D'accord avec isma4, un code peut être optimisé et lisible, et le plus important, il doit être bien commenté.

Il faut aussi se poser la question de la nécessité d'optimiser le code, par rapport au bénéfice qu'on va gagner derrière. Et du temps que l'on va y passer aussi.

[sgamel]

Si son code bien foutu le nom des colonnes peut être dans des constantes qu’elles peuvent garder un nom compréhensible.

Dans tous les cas je préfère un code lisible et clair a un code optimise et illisible. C’est d'autant plus vrai avec les langages compiles ou c'est au compilateur de faire le boulot d'optimisation.

Dans un langage interprété le compilateur peut exister (les JIT se généralisent) mais il est également possible de compresser le code qui est en production.

Le problème n’est pas seulement de gagner quelques bytes mais de comprendre que chaque octet gagné est également un gain de temps.

Avec l'expansion des terminaux mobiles avoir des données compactes est maintenant important. Mais rien de sert d'optimiser de façon prématurée.

[Hellwing]

Cela dépend aussi des contraintes du projet.

Il est parfois plus important d'optimiser le code un maximum que de le garder syntaxiquement lisible, par exemple pour améliorer les temps d'accès en base de données et faire attendre l'utilisateur le moins possible sur des traitements lourds (résultats de statistiques, par exemple).
A ce moment-là, il faut compenser la perte de lisibilité par des commentaires ultra détaillés expliquant les astuces utilisées.

Du moins c'est ce que je fais.

Mais s'il n'y a pas cette contrainte de temps d'exécution, il vaut mieux garder un code lisible (mais tout aussi commenté)

[EDIT] Après avoir relu le sujet, en fait je me pose la question suivante :
On parle d'optimisation des algorithmes ou du gain de place utilisé par les fichiers (donc exit l'indentation, les espaces et les retours à la ligne judicieux) ?

[Barsy]

En JavaScript par exemple, plus le code est optimisé, moins il est lisible. C'est le problème des langages interprétés.

Pour ce qui est des langages compilés au contraire, un code lisible va souvent de pair avec un code optimisé. D'ailleurs, les codes sales à lire sont souvent aussi sales à l'exécution...

Par contre, je sais qu'il y a parfois des problèmes d'optimisation dans le développement Orienté Objet. Par exemple, si on prend une Classe "Toto" avec 50 paramètres et une table "Totos" associée en base de données. Lorsque l'on souhaite récupérer qu'une seule valeur parmi les 50, il n'est pas rare de voir les développeur faire un "new Toto(id)" (constructeur qui va charger l'intégralité des 50 valeurs de Toto à partir de la base) puis ensuite un "Toto.maValeur; Toto.dispose();". Résultat, on a effectué une requête sur 50 valeurs, on les a charger en mémoire, simplement pour n'en utiliser qu'une seule.

[el_slapper]

Réponse standard d'ingénieur standard : ça dépend.

Ça dépend du besoin. Dernièrement, j'ai cradement fait sauter une bufferisation dans un programme batch afin d'implémenter simplement et lisiblement une modification sur un aiguillage de fichiers. Résultat : temps de traitement passé de 4 minutes à 5 minutes. Sur un traitement total de quelques heures. Tout le monde s'en fout - mais la modification est faite, et compréhensible.

A coté de moi, un gars a limité la lecture de données aux seules données réellement utilisées. Au prix d'une petite offusquation. Temps de traitement passé de 34 à 8 heures. C'est un héro.


Evidemment, quand on peut facilement optimiser les performances sans taper dans la lisibilité, il ne faut pas se gêner...

[rebolon]

Ah ça c'est sûre, le To ne coûte pas cher financièrement, mais écologiquement son coût est désastreux. Si on peut économiser l'achat de serveur ou de disque ou tout autre matériel informatique, alors oui, autant sacrifier un peu de lisibilité. Je ne dis pas non plus de écrire sur une ligne, mais on peut aussi envisager des solutions qui vont compiler le code interpréter pour les rendre moins lisible, mais plus optimisé en production.

[pmithrandir]

Pour moi, optimisation et lisibilité ne vont pas toujours de paire.

Combien de fois j'ai eu une requête SQL que je complexifiais parce que de cette façon j'avais des meilleures perf... Alors que la requête simple se lisait d'un coup d'œil, la nouvelle demandait un peu plus de temps.

De la même façon, certains algorithmes sont illisibles... Vous avez écrit 4 ou 5 lignes, mais celles ci vous ont demandé une journée de boulot.
Quand on travaille une journée voir une semaine à optimiser une partie du code, il y a des chances que le code ne soit pas lisible, en particulier sur une lecture en diagonale.

Ce qui n'empêche pas du tout d'indenter, de mettre des noms de variables corrects, etc... Et surtout de dire ce que fait cette fonction incompréhensible.


Et puis, le choix n'est pas toujours possible. Je me souviens d'un tutorial sur tour de jeu qui montrait plein de trucs et astuces pour aider les développeurs de jeux gratuit en ligne a garder un serveur le plus petit possible.

Ça allait de la taille des fichiers PHP à parser jusqu'au requête SQL, la taille des images, etc... Pas moyen de le retrouver tout de suite, j'essaierais plus tard

[Flaburgan]

On ne parle pas de performance d'algorithmes mais de performance de mémoire là. La limite est donc le nombre de caractères, donc la question d'optimisation c'est exit les commentaires, espace, et tabulation, nom de variable à 40 caractères... En fait, tout ce qui n'empêche pas le code de fonctionner. Sur nos bestioles avec des disques durs au To, aucune importance, mais pour de l'embarqué sur des systèmes avec seulement quelques ko de mémoire, tout compte...

[Uther]

Pour ne pas original : dans la plupart des cas faire les deux n'est pas incompatible.
Quand on indente correctement, donne des noms de variable clair et commente bien son code quand c'est nécessaire, ça ne coute rien en performance. Après compilation (il y a également des outils de nettoyage pour les langages interprétés), le code est identique.

Dans les cas ou il faut faire un choix, il n'y a pas de réponse toute faite. Il faut estimer le gain espéré et déterminer si ça en vaut la peine ou non.
Personnellement, j'ai rarement eu des cas ou ça le valait.

[Invité]

Personnellement, j'ai rarement eu des cas ou ça le valait.

C'est vrai en général, mais là c'est un développeur .net et .net, link, entityframework peuvent réserver quelques vilaines surprises.
Il a surement des "réflexes", car un code lisible s'améliore et pas un code difficile.

[grunk]

De quelle école êtes-vous ? Celle du code lisible ou au contraire, préférez-vous l'optimisation des performances ?

Pensez-vous qu'il soit possible de faire les deux ?

Sauf langage web client type javascript/html (et encore c'est de moins en moins vrai) qui implique le chargement du code la taille du code n'a pas grand chose à voir dans l'optimisation.

Avant de commencer à rendre son code illisible pour soit disant optimiser , on ferait bien de se pencher sur ses algorithmes

Pour faire le rapprochement avec les base de données choisir ses types de champs finement sera nettement plus rentable que de raccourcir le nom des champs ....

[el_socio]

Bonjour,

En fait, la question se résume en un mot clé: le compromis.

Il n'est pas possible de faire un code optimal (en terme de rapidité et de taille) et lisible. En effet, pour écrire un code optimal, il faudrait l'écrire en langage machine, ce qui le rend illisible.
Il faut donc trouver le bon compromis.
Et la, bien évidemment, et comme tout compromis, cela dépend de beaucoup de chose. Par exemple, sur certaines applications, chaque cycle processeur gagne est important, mais sur d'autres, on peut se permettre de perdre des minutes entières.

Cela n'empêche pas qu'il est important de savoir optimiser un programme (souvent, cela reviens a savoir faire en sorte que le compilateur puisse bien optimiser), car parfois c'est indispensable.

[wiztricks]

Salut,

C'est une discussion sans fin que vous déclenchez là.

Le plus important, je crois, sera peut être de constater qu'on peut s'amuser à "mesurer" d'une façon ou d'une autre qu'un code sera plus optimisé qu'un autre à partir de critères construits sur le "travail accomplit par unité de temps" - il fait quoi ce code - et les ressources consommées (CPU, mémoire, capacités disques, bande passante IO,...)

Mieux, même si un code n'est pas optimal, on pourra en fonction de l'objectif dire qu'on est "assez bon" et arrêter "d'optimiser"...

Pour ce qui est de la lisibilité du code, c'est beaucoup plus subjectif!

Car ce qui est lisible pour l'un ne le sera pas toujours pour d'autres. Pire, si je veux rendre mon code "lisible" quels seront les critères qui permettront de dire que c'est suffisant, assez bon, ....

Note: En général, lorsqu'on a un code qui "fonctionne" pas trop mal, passer du temps à essayer de l'optimiser est parfois plus incertain et couteux qu'augmenter les capacités (cpu, mémoire,...) dont le coût décroit dans le temps. En amont de l'optimisation, il y a des choix de designs plus ou moins scalables suivant les possibilités de répartition des traitements.

- W

[kurk49]

Ecrire un code lisible est le fait de l'humain (le développeur) et agit sur les éléments suivants: Maintenabilité, fiabilité, stabilité.
Avoir un code optimisé, dans le cadre d'un code compilé peut certes être le fait du développeur, mais est aussi grandement confié au compilateur. Ainsi, lorsque j'ai parfois écrit un code sur lequel je passerais des heures à gagner en optimisation pour tout perdre en lisibilité, je préfère laisser cette tâche ingrate au compilateur.

Bien sur, cela n'est pas réalisable pour des langages interprétés, et c'est entre autres pour cela que j'évite de les utiliser...

[grunk]

Salut,

C'est une discussion sans fin que vous déclenchez là.

Un peu comme toutes les news en ce moment d'ailleurs

[bubulemaster]

Bonjour,

je prend une vue que je n'ai pas vu encore dans les posts.
Si le code suit la spécification détaillée, peu importe qu'il soit lisible ou non.
C'est à la spécification détaillée d'être claire.

Par contre, encore faut-il qu'il y ait une spécification détaillé, c'est pas si courant que ça.

Et effectivement comme dit wiztricks, c'est une discussion sans fin car ça touche aux convictions (peut-être même religion).

[kurk49]

Pour répondre à bubulemaster:

On peut implémenter de façon immonde une spécification logicielle détaillée.
Car, la lisibilité du code dépend certes des algorithmes employés, mais aussi des petites manies du développeur (ou plutot ses bonnes pratiques) comme la notation hongroise, l'abus de parenthèses, les commentaires fonctionnels, l'indentation.

La notion de lisibilité du code n'a a priori que peu de lien avec la spécification en ce sens.

[Obligen]

@Flaburgan

On évite assez souvent d'utiliser un terminal embarqué avec quelques kilo octets de mémoire pour écrire du code source, on s'en sert plus souvent pour exécuter du code compilé. Donc les commentaires et autres indentations ne feront une différence que sur les fichiers sources, sur la machine de développeur, payée par le boss et qui trimballe ses giga octets de mémoire...