Tu n'as jamais du écrire un wrapper pour utiliser une API qui n'était pas conçue selon la logique de ton code?
Je ne sais pas si c'est un très bon exemple. Si tu as des problèmes architecturaux de cette nature (faire interagir deux modules avec des logiques de code très différentes), ça ressemble à un truc où il faut un peu réfléchir à ce qu'on fait. P-e avec un exemple plus concret, je comprendrais mieux en quoi écrire un wrapper pour faire interagir deux logiques différentes, ça se fait sans y penser.
L'exemple le plus proche que j'ai en tête, c'est de passer du code python en cgi (y avait de la dette technique) appelant une lib en C, techniquement thread safe, mais pas fonctionnellement pour que ça tourne en mod_wsgi. Au final, y avait que quelques dizaines de lignes de code, dont 2 décorateurs, je classerai pas ça dans le pissage de code.
Tu n'as jamais dû convertir un format de fichier dans un autre,
je réfléchis mais je ne crois pas. Quand tu fais du dev côté serveur, tu peux recevoir des fichiers/flux à traiter dans plusieurs formats. Mais à partir du moment où tu sais parser un format, autant l'utiliser directement. Sauf spécification supplémentaire, je ne vois pas de raisons de le ré encoder dans un autre format.
coder de manière sous optimale des trucs triviaux (calcul de moyenne, de variance, de distance euclidienne entre des vecteurs...) pour ne pas embarquer une dépendance?
j'ai ré implémenté du dijkstra pour un graphe local, mais de max 10 noeuds et des contraintes fortes sur le nombre de transitions possibles. Une fonctionnalité utilisé ponctuellement pour définir des workflows. Sous optimal ? probablement. Mais sous optimalité négligeable au regard du reste de l'application. C'était pas pour éviter d'embarquer une dépendance, j'étais jeune à l'époque, j'ai même pas cherché. Pour moi, savoir implémenter un dijkstra ou un double liste chaînée, ça faisait partie de la culture générale (j'étais bien naïf :) )
Tu parles de C par exemple, tu n'as jamais dû gérer des entrées à partir d'un fichier non-standardisé (espaces vs. tabulations, virgules ou point virgules, etc)?
ça a du m'arriver, mais pas qui m'ait marqué. Sur des échanges de fichiers réguliers, quand il y a un problème sur un fichier, ça se traite au niveau de l'entité qui génère les fichiers. Côté dev, je n'ai pas été souvent confronté à ça, ou alors de manière très occasionnel, sur des fichiers de petite taille, qui se normalise facilement à coup de regex. C'était probablement un problème plus sérieux côté exploitation.
c'est juste que j'ai du mal à imaginer comment un patron peut vouloir payer quelqu'un à résoudre des puzzles accessibles en quelques secondes à un ordinateur.
c'est pas à ça que je répondais. Dans ton commentaire initial, tu semble dire que la seule manière d'écrire du code, ça se résume à écrire des constructeurs/destructeurs/surcharge d'opérateur, que c'est de "pisser du code", et que c'est pas intéressant.
Ma réponse, c'est que "pisser du code", (c'est à dire passer des longs moments à écrire automatiquement du code sans trop utiliser son cerveau), c'est très ponctuel. Parce que justement, les trucs faciles, ça se fait vite, donc une fois que c'est fait, il reste plus que les trucs compliqués, et ça se pisse pas bien. Le code, ce n'est pas que ça, et on peut y trouver son intérêt.
Le fait qu'un employeur soit prêt ou pas à payer pour que quelqu'un effectue une tâche est décorrélée de savoir si elle est intéressante pour la personne qui la fait.
[^] # Re: ia routeur
Posté par gaaaaaAab . En réponse au lien Une IA conçoit un ordinateur Linux fonctionnel en une semaine. Évalué à 3.
Je ne sais pas si c'est un très bon exemple. Si tu as des problèmes architecturaux de cette nature (faire interagir deux modules avec des logiques de code très différentes), ça ressemble à un truc où il faut un peu réfléchir à ce qu'on fait. P-e avec un exemple plus concret, je comprendrais mieux en quoi écrire un wrapper pour faire interagir deux logiques différentes, ça se fait sans y penser.
L'exemple le plus proche que j'ai en tête, c'est de passer du code python en cgi (y avait de la dette technique) appelant une lib en C, techniquement thread safe, mais pas fonctionnellement pour que ça tourne en mod_wsgi. Au final, y avait que quelques dizaines de lignes de code, dont 2 décorateurs, je classerai pas ça dans le pissage de code.
je réfléchis mais je ne crois pas. Quand tu fais du dev côté serveur, tu peux recevoir des fichiers/flux à traiter dans plusieurs formats. Mais à partir du moment où tu sais parser un format, autant l'utiliser directement. Sauf spécification supplémentaire, je ne vois pas de raisons de le ré encoder dans un autre format.
j'ai ré implémenté du dijkstra pour un graphe local, mais de max 10 noeuds et des contraintes fortes sur le nombre de transitions possibles. Une fonctionnalité utilisé ponctuellement pour définir des workflows. Sous optimal ? probablement. Mais sous optimalité négligeable au regard du reste de l'application. C'était pas pour éviter d'embarquer une dépendance, j'étais jeune à l'époque, j'ai même pas cherché. Pour moi, savoir implémenter un dijkstra ou un double liste chaînée, ça faisait partie de la culture générale (j'étais bien naïf :) )
ça a du m'arriver, mais pas qui m'ait marqué. Sur des échanges de fichiers réguliers, quand il y a un problème sur un fichier, ça se traite au niveau de l'entité qui génère les fichiers. Côté dev, je n'ai pas été souvent confronté à ça, ou alors de manière très occasionnel, sur des fichiers de petite taille, qui se normalise facilement à coup de regex. C'était probablement un problème plus sérieux côté exploitation.
c'est pas à ça que je répondais. Dans ton commentaire initial, tu semble dire que la seule manière d'écrire du code, ça se résume à écrire des constructeurs/destructeurs/surcharge d'opérateur, que c'est de "pisser du code", et que c'est pas intéressant.
Ma réponse, c'est que "pisser du code", (c'est à dire passer des longs moments à écrire automatiquement du code sans trop utiliser son cerveau), c'est très ponctuel. Parce que justement, les trucs faciles, ça se fait vite, donc une fois que c'est fait, il reste plus que les trucs compliqués, et ça se pisse pas bien. Le code, ce n'est pas que ça, et on peut y trouver son intérêt.
Le fait qu'un employeur soit prêt ou pas à payer pour que quelqu'un effectue une tâche est décorrélée de savoir si elle est intéressante pour la personne qui la fait.