Un développeur doit-il d’abord viser la lisibilité ou la performance?

Souvent, un développeur sera confronté à un choix entre deux manières possibles de résoudre un problème: une solution idiomatique et lisible, et une autre moins intuitive, mais plus performante. Par exemple, dans les langages basés sur C, il existe deux manières de multiplier un nombre par 2:

int SimpleMultiplyBy2(int x) { return x * 2; } 

et

 int FastMultiplyBy2(int x) { return x << 1; } 

La première version est plus simple à prendre à la fois pour les lecteurs techniques et non techniques, mais la seconde peut donner de meilleurs résultats, car le transfert de bits est une opération plus simple que la multiplication. (Pour l’instant, supposons que l’optimiseur du compilateur ne le détecte pas et l’optimise, bien que cela soit également une considération).

En tant que développeur, quelle serait la meilleure tentative?

Vous en avez manqué un.

Premier code pour l’exactitude, alors pour plus de clarté (les deux sont souvent connectés, bien sûr!). Enfin, et seulement si vous avez réellement des preuves empiriques, vous pouvez envisager une optimisation. L’optimisation prématurée est vraiment mauvaise. L’optimisation coûte presque toujours du temps, de la clarté et de la facilité de maintenance. Vous feriez mieux de vous assurer que vous achetez quelque chose de valable avec cela.

Notez que les bons algorithmes battent presque toujours le réglage localisé. Il n’y a aucune raison pour laquelle vous ne pouvez pas avoir un code correct, clair et rapide. Vous serez déraisonnablement chanceux de commencer à vous concentrer sur la rapidité.

OMI la version lisible évidente en premier, jusqu’à ce que la performance soit mesurée et une version plus rapide est requirejse.

Prenez-le de Don Knuth

L’optimisation prématurée est la racine de tout mal (ou du moins la majeure partie) dans la programmation.

Lisibilité 100%

Si votre compilateur ne peut pas faire l’optimisation “x * 2” => “x << 1" pour vous - obtenez un nouveau compilateur!

Rappelez-vous également que 99,9% du temps de votre programme est passé à attendre les entrées de l’utilisateur, à attendre les requêtes de la firebase database et à attendre les réponses du réseau. À moins que vous ne fassiez les 20 fois plus, cela ne sera pas perceptible.

Dans votre exemple, 99,9999% des compilateurs généreront le même code pour les deux cas. Ce qui illustre ma règle générale – écrivez d’abord pour la lisibilité et la maintenabilité, et optimisez uniquement lorsque vous en avez besoin.

La lisibilité à coup sûr. Ne vous inquiétez pas de la vitesse sauf si quelqu’un se plaint

Lisibilité.

Le codage de la performance a ses propres défis. Joseph M. Newcomer l’a bien dit

L’optimisation ne compte que lorsque cela compte. Quand c’est important, cela compte beaucoup, mais tant que vous ne savez pas que c’est important, ne perdez pas beaucoup de temps à le faire. Même si vous savez que cela compte, vous devez savoir où cela compte. Sans données de performance, vous ne saurez pas quoi optimiser et vous optimiserez probablement la mauvaise chose.

Le résultat sera obscur, difficile à écrire, difficile à déboguer et difficile à maintenir le code qui ne résout pas votre problème. Il a donc le double inconvénient de (a) augmenter les coûts de développement de logiciels et de maintenance des logiciels, et (b) n’avoir aucun effet sur les performances.

Lisibilité. Le temps d’optimiser est le moment où vous atteignez le test bêta. Sinon, vous ne savez jamais vraiment sur quoi vous devez consacrer du temps.

J’irais d’ abord pour la lisibilité . Compte tenu du fait que, avec les langages optimisés et les machines très chargées que nous avons actuellement, la plupart du code que nous écrivons de manière lisible fonctionnera correctement.

Dans certains scénarios très rares, où vous êtes sûr que vous allez avoir un goulot de performance (peut-être de mauvaises expériences passées), et que vous avez réussi à trouver des trucs bizarres qui peuvent vous donner un énorme avantage en termes de performances, vous pouvez opter pour cette. Mais vous devriez très bien commenter cet extrait de code, ce qui vous aidera à le rendre plus lisible.

Un facteur souvent négligé dans ce débat est le temps supplémentaire nécessaire à un programmeur pour naviguer, comprendre et modifier un code moins lisible. Considérant que le temps d’un programmeur est de cent dollars l’heure ou plus, cela représente un coût très réel.
Tout gain de performance est compensé par ce surcoût direct en développement.

Mettre un commentaire avec une explication le rendrait lisible et rapide.

Cela dépend vraiment du type de projet et de l’importance des performances. Si vous construisez un jeu en 3D, il y a généralement beaucoup d’optimisations communes que vous voudrez y jeter en cours de route, et il n’y a pas de raison de ne pas trop vous en occuper. Mais si vous faites quelque chose de délicat, commentez-le pour que tout le monde sache comment et pourquoi vous êtes difficile.

La réponse dépend du contexte. Dans la programmation des pilotes de périphériques ou le développement de jeux, par exemple, la seconde forme est un idiome acceptable. Dans les applications métier, pas tellement.

Votre meilleur pari est de regarder autour du code (ou dans des applications similaires réussies ) pour vérifier comment les autres développeurs le font.

utiliser << serait par une micro optimisation. So Hoare (pas Knuts) règle:

L’optimisation prématurée est la racine de tout mal.

s’applique et vous devez simplement utiliser la version la plus lisible en premier lieu.

Ceci est la règle est à mon humble avis souvent mal utilisé comme une excuse pour concevoir un logiciel qui ne peut jamais évoluer ou performer.

Tous les deux. Votre code doit équilibrer les deux; lisibilité et performance. Car ignorer l’un ou l’autre va nuire au retour sur investissement du projet, ce qui en fin de compte est tout ce qui compte pour votre patron.

Une mauvaise lisibilité entraîne une diminution de la maintenabilité, ce qui entraîne une augmentation des ressources consacrées à la maintenance, ce qui se traduit par un retour sur investissement plus faible.

La mauvaise performance se traduit par une diminution des investissements et de la clientèle, ce qui se traduit par un retour sur investissement inférieur.

Plus la base de code est grande, plus la lisibilité est importante. Essayer de comprendre une fonction minuscule n’est pas si grave. (Surtout que le nom de la méthode dans l’exemple vous donne un indice.) Pas si génial pour une épopée de code uber écrite par le génie solitaire qui vient de quitter le codage parce qu’il a finalement vu le haut de la complexité de sa capacité écrit pour vous et vous ne le comprendrez jamais.

Si la lisibilité de votre code vous inquiète, n’hésitez pas à append un commentaire pour vous rappeler ce que vous faites et pourquoi.

Le décalage de bits par rapport à la multiplication est une optimisation sortingviale qui gagne presque rien . Et, comme cela a été souligné, votre compilateur devrait le faire pour vous. En dehors de cela, le gain est négligeable de toute façon, de même que le processeur sur lequel s’exécute cette instruction.

D’un autre côté, si vous devez effectuer un calcul sérieux, vous aurez besoin des structures de données appropriées. Mais si votre problème est complexe, vous devez vous renseigner à ce sujet. En guise d’illustration, envisagez de rechercher un numéro d’identification dans un tableau d’objects 1000000 non sortingés. Ensuite, réexaminez en utilisant un arbre binary ou une carte de hachage.

Mais les optimisations comme n << C sont généralement négligeables et triviales à changer à tout moment. Rendre le code lisible ne l'est pas.

Cela dépend de la tâche à résoudre. Habituellement, la lisibilité est plus importante, mais certaines tâches doivent encore être envisagées. Et vous ne pouvez pas simplement passer une journée ou faire du profilage et de l’optimisation après que tout fonctionne parfaitement, car l’optimisation elle-même peut nécessiter la réécriture d’une partie suffisante d’un code à partir de zéro. Mais ce n’est pas commun de nos jours.

Vous devez toujours optimiser au maximum, la performance compte toujours. La raison pour laquelle nous avons bloatware aujourd’hui, c’est que la plupart des programmeurs ne veulent pas faire le travail d’optimisation.

Cela dit, vous pouvez toujours formuler des commentaires dans lesquels le codage délicat doit être clarifié.

Il ne sert à rien d’optimiser si vous ne connaissez pas vos goulots d’étranglement. Vous avez peut-être rendu une fonction incroyablement efficace (généralement au désortingment de la lisibilité dans une certaine mesure) pour constater que cette partie du code est rarement exécutée ou que vous passez plus de temps à bash le disque ou la firebase database. Vous ne pouvez donc pas micro-optimiser jusqu’à ce que vous ayez quelque chose à mesurer, et vous pourriez aussi bien commencer à lire. Cependant, vous devez être attentif à la rapidité et à la compréhensibilité lors de la conception de l’architecture globale, car les deux peuvent avoir un impact considérable et être difficiles à modifier (en fonction du style de codage et des méthodologies).

On estime qu’environ 70% du coût du logiciel est en maintenance. La lisibilité rend un système plus facile à maintenir et, par conséquent, réduit les coûts du logiciel au cours de sa vie.

Il y a des cas où la performance est plus importante que la lisibilité, cela dit qu’ils sont rares.

Avant de sacrifier la lisibilité, pensez “Suis-je (ou votre entreprise) prêt à faire face aux coûts supplémentaires que j’ajoute au système en faisant cela?”

Je ne travaille pas chez Google alors je choisirais l’option maléfique. (optimisation)

Au chapitre 6 de “Programming Pearls” de Jon Bentley, il décrit comment un système accélérait 400 fois en optimisant 6 niveaux de conception différents. Je crois que, en ne se souciant pas des performances à ces 6 niveaux de conception, les développeurs modernes peuvent facilement atteindre 2 ou 3 ordres de grandeur de ralentissement de leurs programmes.

Comme presque tous l’ont dit dans leurs réponses, je suis favorable à la lisibilité . 99 des 100 projets que je gère n’ont pas de temps de réponse requirejs, c’est donc un choix facile.

Avant même de commencer à coder, vous devez déjà connaître la réponse. Certains projets ont certaines exigences de performances, telles que “besoin de pouvoir exécuter la tâche X en Y (millisecondes)”. Si tel est le cas, vous avez un objective à atteindre et vous savez quand il faut optimiser ou non. (heureusement) ceci est déterminé à l’étape des besoins de votre projet, pas lors de l’écriture du code.

Une bonne lisibilité et la possibilité d’optimiser ultérieurement résultent d’une conception logicielle appropriée. Si votre logiciel est de conception sonore, vous devriez pouvoir isoler des parties de votre logiciel et les réécrire si nécessaire, sans casser d’autres parties du système. En outre, la plupart des cas d’optimisation que j’ai rencontrés (en ignorant certaines astuces de bas niveau, celles-ci sont accessoires) ont consisté à passer d’un algorithme à un autre ou à mettre en mémoire des données au lieu de disque / réseau.

La lisibilité est la PREMIÈRE cible.

Dans les années 1970, l’armée a testé certaines des “nouvelles” techniques de développement de logiciels (conception descendante, programmation structurée, équipes de programmeurs en chef, pour n’en citer que quelques-unes) afin de déterminer laquelle de ces différences était significative.

La seule technique qui faisait une différence statistiquement significative dans le développement était …

ADDING BLANK LINES au code de programme.

L’amélioration de la lisibilité dans ces codes pré-structurés et orientés pré-object était la seule technique dans ces études à améliorer la productivité.

==============

L’optimisation ne devrait être envisagée que lorsque le projet entier est testé et prêt pour l’instrumentation. Vous ne savez jamais où vous devez optimiser le code.

Dans leurs ouvrages de référence, Kernigan et Plauger, à la fin des années 1970, ont montré que SOFTWARE TOOLS (1976) et SOFTWARE TOOLS IN PASCAL (1981) permettaient de créer des programmes structurés en utilisant la conception descendante. Ils ont créé des programmes de traitement de texte: éditeurs, outils de recherche, pré-processeurs de code.

Lorsque la fonction de formatage de texte terminée a été INSTRUMENTED, ils ont découvert que la majeure partie du temps de traitement était passée en trois routines exécutant la saisie et la sortie de texte (dans le livre original, les fonctions io prenaient 89% du temps). consommé 55%!)

Ils ont été en mesure d’optimiser ces TROIS routines et ont produit les résultats d’une performance accrue avec un temps de développement et des coûts raisonnables et gérables.

La lisibilité en premier Mais plus que la lisibilité est la simplicité, surtout en termes de structure des données.

Cela me rappelle un étudiant qui fait un programme d’parsing de la vision, qui ne comprend pas pourquoi c’est si lent. Il a simplement suivi une bonne pratique de programmation – chaque pixel était un object, et cela fonctionnait en envoyant des messages à ses voisins …

regarde ça

S’il n’y a pas de lisibilité, il sera très difficile d’améliorer les performances lorsque vous en aurez vraiment besoin.

Les performances ne devraient être améliorées que lorsque cela pose un problème dans votre programme, car il y a beaucoup d’endroits qui pourraient constituer un goulot plutôt que cette syntaxe. Disons que vous écrasez 1ns amélioration sur un << mais ignoré que 10 minutes IO temps.

En ce qui concerne la lisibilité, un programmeur professionnel devrait être capable de lire / comprendre les termes informatiques. Par exemple, nous pouvons nommer une méthode de mise en file plutôt que de dire putThisJobInWorkQueue.

Écrivez d’abord pour la lisibilité, mais attendez-vous à ce que les lecteurs soient des programmeurs . Tout programmeur digne de ce nom devrait connaître la différence entre un multiplicateur et un bitshift, ou être capable de lire l’opérateur ternaire lorsqu’il est utilisé correctement, être capable de rechercher et comprendre un algorithme complexe (vous commentez votre code correctement? ), etc.

La sur-optimisation précoce est, bien sûr, assez mauvaise pour vous amener plus tard à des remaniements, mais cela ne s’applique pas vraiment à l’optimisation des méthodes individuelles, des blocs de code ou des instructions.

Je dirais aller pour la lisibilité.

Mais dans l’exemple donné, je pense que la deuxième version est déjà suffisamment lisible, puisque le nom de la fonction indique exactement ce qui se passe dans la fonction.

Si nous avions toujours des fonctions qui nous disaient ce qu’elles font …

Combien coûte une heure de processeur?

Combien coûte une heure de programmation au programmeur?

IMHO les deux choses n’ont rien à faire. Vous devriez d’abord opter pour du code qui fonctionne, car c’est plus important que la performance ou la qualité de lecture. En ce qui concerne la lisibilité: votre code doit toujours être lisible dans tous les cas.

Cependant, je ne vois pas pourquoi le code ne peut pas être lisible et offre de bonnes performances en même temps. Dans votre exemple, la deuxième version est aussi lisible que la première pour moi. Qu’est-ce qui est moins lisible? Si un programmeur ne sait pas que le décalage est égal à la multiplication par une puissance de deux et que le décalage vers la droite équivaut à la division par une puissance de deux … alors, vous avez beaucoup plus de problèmes de base que la lisibilité générale.