Quasiment toutes les structures de données sont disponible d'une façon ou d'une autre pour un langage donné, et souvent optimisées par rapport aux particularités dudit langage.
Il faut aussi faire attention à ca. Évidement on commence par utiliser les trucs standards quand c'est possible pour aller vite et identifier ce qui va poser problème ou non (approche type balle tracante).
Maintenant dès que tu t'intéresse un peu à ce que tu fais ou que tu es dans un contexte un peu différent de "Je pisse du code pour la webapp lambda" tu tombes rapidement sur des trous ou des choses qui méritent un peu d'attention.
Exemple débile d'hier: trier une liste d'entiers selon un comparateur adhoc en Java. Bha ca n'existe pas. Du coup j'ai trois solutions:
Je trouve quelque part une dépendance qui fait ca. Mes clients vont être content et moi aussi, un truc de plus.
Je converti mon int[] en Integer[] ou en ArrayList et ma consommation mémoire fait mini x3 sans parler de l'impact sur les perfs.
Je comprends les caractéristiques de l'objet que je manipule. Je connais les outils algorithmique à ma disposition. Je peux écrire en une à deux heure le code du tri adapté à mon besoin. C'est dommage que ce ne soit pas built-in mais ces deux heures vont me faire des heures à l'exécution et gagner des Mo de RAM pour aucun autre coût que ces deux heures.
En pratique tu tombes très souvent sur des cas comme ca. En Java 6 String.split passe par des regex même si tu utilises un bête char comme délimiteur. Ca me coute 20% de mon temps d'exécution ? Je prends 1h pour le réécrire. L'UX n'est pas contente de l'highlighting de mot faire par Solr ? Je désactive et je le recode avec d'horribles algo sur les chaînes de caractères etc.
On utilise les outils qui existent quand c'est possible, mais on n'hésite pas à mettre les mains dans le cambouis quand c'est justifié. C'est une histoire d'équilibre, comprendre ce qu'on manipule et essayer de faire le choix le plus judicieux à court et long terme.
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 9. Dernière modification le 17 juillet 2013 à 12:43.
Il faut aussi faire attention à ca. Évidement on commence par utiliser les trucs standards quand c'est possible pour aller vite et identifier ce qui va poser problème ou non (approche type balle tracante).
Maintenant dès que tu t'intéresse un peu à ce que tu fais ou que tu es dans un contexte un peu différent de "Je pisse du code pour la webapp lambda" tu tombes rapidement sur des trous ou des choses qui méritent un peu d'attention.
Exemple débile d'hier: trier une liste d'entiers selon un comparateur adhoc en Java. Bha ca n'existe pas. Du coup j'ai trois solutions:
En pratique tu tombes très souvent sur des cas comme ca. En Java 6 String.split passe par des regex même si tu utilises un bête
charcomme délimiteur. Ca me coute 20% de mon temps d'exécution ? Je prends 1h pour le réécrire. L'UX n'est pas contente de l'highlighting de mot faire par Solr ? Je désactive et je le recode avec d'horribles algo sur les chaînes de caractères etc.On utilise les outils qui existent quand c'est possible, mais on n'hésite pas à mettre les mains dans le cambouis quand c'est justifié. C'est une histoire d'équilibre, comprendre ce qu'on manipule et essayer de faire le choix le plus judicieux à court et long terme.