Citation: Quand faut-il optimiser son code/système?
Voici une nouvelle citation fort intéressante:
Et bien non, il suggère seulement que vouloir écrire un code "trop propre" pourrait être la source de nombreux problèmes.
Et d'expérience, je confirme que c'est vrai même si je confirme aussi que se jeter trop vite dans les développements sans aucune réflexion est aussi source de nombreux problèmes.
Exemple 1: l'Analyse
Probablement le plus connu. C'est celui de vouloir peaufiner un modèle à fond (et aussi l'optimiser) avant de commencer des développements. En fin de compte, on rebondit de problème de conception en problème de conception sans jamais commencer le développement.
Autre effet de bords courant dans ce cas: anticiper trop de fonctionnalités (pas forcement nécessaire), ce qui révèle des problèmes d'analyse (pointilleux à ce stade) pour des fonctionnalités qui ne sont pas utiles!
Résultat: analyse qui s'enlise... développements qui ne démarrent pas.
Exemple 2: la base de donnée
Autre cas assez courant... c'est la conception d'une base de donnée par une personne manquant d'expérience sur l'utilisation optimal du moteur DB.
Il est assez fréquent d'avoir des développeurs capable de concevoir de bon modèles de base de donnée... par contre j'ai déjà rencontré des modèles littéralement bardés d'index... histoire de couvrir des cas de figures potentiels.
Le résultat est généralement contre productif... puisque écrire un enregistrement implique la mise-à-jour de tous les indexes (donc chute de performances).
Le pire, c'est que dans la plupart des cas, ces indexes ne sont pas nécessaires et que l'étude des performances en production révèle souvent un indexe adéquat auquel personne n'a pensé.
Post-scriptum:
Dans ces deux exemples/cas de figure, c'est la tentative d'optimisation (ou d'anticipation) qui est contre-productif.
Il est préférable de préparer un système bien pensé... destiné a remplir les objectifs (sans plus)... et éventuellement ouvert sur l'avenir (donc sans fermer de portes).
Le développement pourra ainsi être rapide, en faisant appel à du code bien écrit sans optimisation excessive. Le résultat ne présente pas une complexité élevée... ce qui le rendra plus facile à optimiser.
L'optimisation peu alors se faire en étudiant le comportement sur le terrain (en production). Il arrive souvent que les optimisations à réaliser ne se fassent pas là où l'on avait anticipé un problème.
Règle des 80/20:
Pensez toujours à cette règle des 80/20.
20% du code réaliser 80% des objectifs. 20% du travail d'optimisation réalisera 80% améliorations de performances.... etc... etc.
Pas besoin de perdre trop de temps en amont de vos projets... 20% d'efforts en fin de projet fera probablement toute la différence :-)
L'optimisation prématurée est à la base de tous les mauxTiens tiens, cela signifierait-il qu'il est préférable d'écrire un code "cochon" à un code un code bien propre et optimisé?
Et bien non, il suggère seulement que vouloir écrire un code "trop propre" pourrait être la source de nombreux problèmes.
Et d'expérience, je confirme que c'est vrai même si je confirme aussi que se jeter trop vite dans les développements sans aucune réflexion est aussi source de nombreux problèmes.
Exemple 1: l'Analyse
Probablement le plus connu. C'est celui de vouloir peaufiner un modèle à fond (et aussi l'optimiser) avant de commencer des développements. En fin de compte, on rebondit de problème de conception en problème de conception sans jamais commencer le développement.
Autre effet de bords courant dans ce cas: anticiper trop de fonctionnalités (pas forcement nécessaire), ce qui révèle des problèmes d'analyse (pointilleux à ce stade) pour des fonctionnalités qui ne sont pas utiles!
Résultat: analyse qui s'enlise... développements qui ne démarrent pas.
Exemple 2: la base de donnée
Autre cas assez courant... c'est la conception d'une base de donnée par une personne manquant d'expérience sur l'utilisation optimal du moteur DB.
Il est assez fréquent d'avoir des développeurs capable de concevoir de bon modèles de base de donnée... par contre j'ai déjà rencontré des modèles littéralement bardés d'index... histoire de couvrir des cas de figures potentiels.
Le résultat est généralement contre productif... puisque écrire un enregistrement implique la mise-à-jour de tous les indexes (donc chute de performances).
Le pire, c'est que dans la plupart des cas, ces indexes ne sont pas nécessaires et que l'étude des performances en production révèle souvent un indexe adéquat auquel personne n'a pensé.
Post-scriptum:
Dans ces deux exemples/cas de figure, c'est la tentative d'optimisation (ou d'anticipation) qui est contre-productif.
Il est préférable de préparer un système bien pensé... destiné a remplir les objectifs (sans plus)... et éventuellement ouvert sur l'avenir (donc sans fermer de portes).
Le développement pourra ainsi être rapide, en faisant appel à du code bien écrit sans optimisation excessive. Le résultat ne présente pas une complexité élevée... ce qui le rendra plus facile à optimiser.
L'optimisation peu alors se faire en étudiant le comportement sur le terrain (en production). Il arrive souvent que les optimisations à réaliser ne se fassent pas là où l'on avait anticipé un problème.
Règle des 80/20:
Pensez toujours à cette règle des 80/20.
20% du code réaliser 80% des objectifs. 20% du travail d'optimisation réalisera 80% améliorations de performances.... etc... etc.
Pas besoin de perdre trop de temps en amont de vos projets... 20% d'efforts en fin de projet fera probablement toute la différence :-)
.png)
Écrire un commentaire