Toute la difficulté est de savoir où placer la limite.
Moins de dépendances, c'est effectivement moins de code (surface d'attaque moindre) et moins de personnes extérieures à qui faire confiance. Le journal l'explique très bien. Et, quand on peut obtenir moins de dépendances juste en changeant la bibliothèque qu'on utilise, c'est très bien.
Mais si on enlève des dépendances en réécrivant soi-même le code de la bibliothèque, là, on peut partir dans l'excès inverse : on risque de recoder mal ce qui a été codé bien par une équipe compétente. On perd la force du travail d'équipe, le partage du travail.
La frontière est mince. Dans le journal, les exemples donnés semblent raisonnables (grosses bibliothèques enlevées en (re)codant quelques cas particuliers) mais il serait facile d'aller trop loin si on ne fait pas attention. J'ai vu nombres d'étudiants recoder (très) mal des fonctionnalités de bibliothèques pour de mauvaises raisons (ignorance de l'existant, c'est plus rigolo de tout (re)faire soi-même, etc.)
Dans le contexte d'enseignement, ça peut être bien (on apprend quand on (re)code), mais dans un contexte plus professionnel (stage, emploi), ça peut vite apporter des problèmes (performances, sécurité, maintenabilité, etc.)
# Les limites de l'exercice
Posté par Vincent Danjean . En réponse au journal Mon inquiétude sur les dépendances en Rust. Évalué à 10.
Toute la difficulté est de savoir où placer la limite.
Moins de dépendances, c'est effectivement moins de code (surface d'attaque moindre) et moins de personnes extérieures à qui faire confiance. Le journal l'explique très bien. Et, quand on peut obtenir moins de dépendances juste en changeant la bibliothèque qu'on utilise, c'est très bien.
Mais si on enlève des dépendances en réécrivant soi-même le code de la bibliothèque, là, on peut partir dans l'excès inverse : on risque de recoder mal ce qui a été codé bien par une équipe compétente. On perd la force du travail d'équipe, le partage du travail.
La frontière est mince. Dans le journal, les exemples donnés semblent raisonnables (grosses bibliothèques enlevées en (re)codant quelques cas particuliers) mais il serait facile d'aller trop loin si on ne fait pas attention. J'ai vu nombres d'étudiants recoder (très) mal des fonctionnalités de bibliothèques pour de mauvaises raisons (ignorance de l'existant, c'est plus rigolo de tout (re)faire soi-même, etc.)
Dans le contexte d'enseignement, ça peut être bien (on apprend quand on (re)code), mais dans un contexte plus professionnel (stage, emploi), ça peut vite apporter des problèmes (performances, sécurité, maintenabilité, etc.)