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 ?
Le 2010-10-28 13:57:36, par Idelways, Expert éminent sénior
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
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 ?
Source : blog de Ayende Rahien
En collaboration avec Gordon Fowler
-
noOneIsInnocentMembre éprouvé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é.le 28/10/2010 à 14:06 -
grunkModérateurle 28/10/2010 à 16:48
-
Killing JokeMembre actifRéponse pragmatique : 80/20.
Toujours partir d'un code non-optimisé mais clair, lisible, maintenable (sauf cas particuliers, voir ci-dessous).
Si pas de problèmes de performances, on en reste là.
Si problème de performances, on commence à regarder, quitte à aller jusqu'au 80/20 : optimiser les 20% de code qui s'exécute 80% du temps.
Après il y a bien sûr des exceptions : il y a certaines choses dont on voit bien dès le départ, en fonction des besoins, qu'il s'agira de code "sensible" qui gagnera à être dès le départ gaulé dans une optique d'avoir des bonnes performances.
Rappel : en effet, parfois "ré-optimiser après coup" peut être particulièrement couteux sur la conception initiale est mal adaptée.le 28/10/2010 à 22:23 -
Franck SORIANOExpert confirméLe problème avec cette définition, c'est qu'il n'y a qu'un mathématicien pour y comprendre quelque chose
.
Moi je préfère dire qu'optimiser, c'est faire mieux à consommation de ressource constante, ou faire la même chose en consommant moins de ressource.
Ca implique que l'optimisation ne peut intervenir que dans un deuxième temps, puisqu'il faut déjà avoir une première solution à améliorer avant de pouvoir "l'optimiser".
Ca montre aussi qu'en fait, la question n'est pas de savoir s'il faut optimiser ou rendre un code lisible. Si on entre dans la démarche d'optimisation, c'est que le résultat n'est pas satisfaisant. Et un code lisible qui donne un résultat non satisfaisant, ça ne sert à rien, donc bon pour la poubelle.
En fait, la question c'est plutôt faut-il écrire un code efficace, qui consomme peu de ressource à chaque exécution, ou faut-il écrire un code agréable pour le développeur ? Faut-il réduire les coûts d'exploitation (coûts récurrents tout au long de la vie du produit) ou réduire les coûts de développements (coût qu'on doit payer uniquement au moment du développement) ?
Faut-il privilégier le confort des utilisateurs, ou faut-il privilégier celui des développeurs ?
Maintenant si on veut se préoccuper des performances et de la consommation de ressource de l'appli, c'est avant tout un problème d'architecture et de conception. Il faut concevoir les choses dès le départ pour qu'elles puissent être performantes.
Une conception plus efficace qu'une autre n'a pas de raisons d'être moins lisible.
Les cas où on doit réellement optimiser un code jusqu'à le rendre illisible sont rarissimes.
Le plus souvent, lorsqu'on veut opposer les deux, c'est qu'on ne sait faire ni l'un ni l'autre...le 01/11/2010 à 22:51 -
B.AFMembre chevronnéJ'aime pas ce raisonnement exclusif : ou optimisé ou lisible.
On peut obtenir les deux.
En l'occurence là, c'est généraliser un épiphénoméne et ce n'est pas de l'optimisation de code : gagner de l'espace disque (140Mo c'est ridicule de nos jours) ne veut pas dire être plus performant. C'est une appréciation libre.le 28/10/2010 à 18:36 -
MigouWMembre actifD'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.le 28/10/2010 à 14:16 -
HellwingMembre chevronné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) ?le 28/10/2010 à 14:44 -
el_slapperExpert éminent séniorRé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...le 28/10/2010 à 14:57 -
grunkModérateurDe 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 ?
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 ....le 28/10/2010 à 15:47 -
wiztricksExpert éminent séniorSalut,
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.
- Wle 28/10/2010 à 16:35