Personnellement je n'ai pas de problème à voir du code peu lisible pour des questions d'optimisation, à partir du moment où :
C'est documenté – l'auteur a expliqué pourquoi et comment le code tarabiscoté a été conçu,
C'est testé – parce que si le code est difficile à lire, c'est aussi difficile de savoir ce qu'il fait,
C'est isolé – c'est un morceau de code tordu, pas l'intégralité du code qui est tordue.
C'est utile.
C'est bizarre, mais le point 4 est en fait assez rare. Je ne compte plus les trouzaines de micro-optimisations complètement inutiles alors que juste à côté il y a un énorme problème de performances facile à corriger.
J'ai l'impression que beaucoup de (mauvais ?) développeurs optimisent sur ce qu'ils pensent être problématique, au lieu de mesurer ce qui est réellement problématique. Et c'est comme ça qu'on se retrouve avec des trucs tordus pour gagner 0.5 ms sur une page qui met 15 secondes pour être calculée. Ou une astuce pour gagner quelques Ko de RAM, alors qu'une structure censée stocker des dizaines de millions d'entrée en RAM est tellement pétée qu'il lui faut 280 octets pour stocker un double (8 octets) (et donc, 10 millions d'entrées prennent 2,8 Go de RAM pour 80 Mo de données utiles) (je précise que la structure n'offre aucun avantage sur un tableau)...
On a certes dépassé la grande époque de PHP et des conseils moisis à base de « Utilise des guillemets simples, c'est plus rapide que les guillemets doubles », mais c'est encore des problèmes que je rencontre souvent.
[^] # Lisibilité... et optimisation là où c'est utile !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Exercices de programmation et benchmarks. Évalué à 9. Dernière modification le 12 février 2020 à 11:43.
Personnellement je n'ai pas de problème à voir du code peu lisible pour des questions d'optimisation, à partir du moment où :
C'est bizarre, mais le point 4 est en fait assez rare. Je ne compte plus les trouzaines de micro-optimisations complètement inutiles alors que juste à côté il y a un énorme problème de performances facile à corriger.
J'ai l'impression que beaucoup de (mauvais ?) développeurs optimisent sur ce qu'ils pensent être problématique, au lieu de mesurer ce qui est réellement problématique. Et c'est comme ça qu'on se retrouve avec des trucs tordus pour gagner 0.5 ms sur une page qui met 15 secondes pour être calculée. Ou une astuce pour gagner quelques Ko de RAM, alors qu'une structure censée stocker des dizaines de millions d'entrée en RAM est tellement pétée qu'il lui faut 280 octets pour stocker un
double(8 octets) (et donc, 10 millions d'entrées prennent 2,8 Go de RAM pour 80 Mo de données utiles) (je précise que la structure n'offre aucun avantage sur un tableau)...On a certes dépassé la grande époque de PHP et des conseils moisis à base de « Utilise des guillemets simples, c'est plus rapide que les guillemets doubles », mais c'est encore des problèmes que je rencontre souvent.
La connaissance libre : https://zestedesavoir.com