Inversement, refuser obstinément de se mettre un minimum à la page « parce que ça fonctionne en l’état », c’est prendre le risque réel de commencer à réagir quand on est déjà dans le mur. Et quand le produit ne se vends plus « parce qu’il est trop moche » et qu’on ne sait plus le redesigner en un temps raisonnable, parce qu’il utilise des techniques qui sont bloquées par défaut – à raison – par les navigateurs modernes, quand la concurrence arrive et fait mieux fonctionnellement avec 10x moins de boulot de paramétrage et 10x moins de boulot d’administration, c’est trop tard.
La vraie difficulté dans un projet à long terme – vraiment long pour de l’informatique, sur plus de 10 ans – c’est pas de « suivre la hype » ou de « rester conservateur ». C’est de bien découpler les différentes parties de son projet, d’identifier ce qu’il est pertinent de mettre à jour et de réussir à le faire, et ce en permanence, sans laisser un morceau pourrir dans un coin, et surtout sans re-créer du couplage inutile.
Une technologie moderne et qui apporte d’énormes avantages à un instant T (comme les JSP en 2000) peut devenir un boulet 20 ans plus tard (comme les JSP en 2020). De même, le code de 20 ans d’âge peut avoir été conçu selon des contraintes complètement obsolètes : toutes ces contorsions pour que le code puisse s’exécuter sur un serveur doté de 128 Mo de RAM peuvent être remplacées par quelque chose de plus rapide et plus facile à maintenir. Un LEFT OUTER JOIN sera plus lisible qu’un table1 = table2 (+). Etc.
Je ne dis pas que c’est facile à faire, au contraire : la maintenance, c’est toujours risqué (régressions...), c’est un cout difficile à justifier, ça peut être long pour un résultat pas évident à court terme, et identifier quelles technologies sont à l’agonie et par quoi les remplacer est un exercice délicat. Mais un code qu’on a laissé pourrir dans un coin « parce que c’est fonctionnel » est tout aussi mauvais qu’un code qu’on passe son temps à modifier « pour suivre la hype ».
[^] # Re: la fin du site central...
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le sophisme du meilleur outil. Évalué à 10. Dernière modification le 13 novembre 2023 à 12:29.
Inversement, refuser obstinément de se mettre un minimum à la page « parce que ça fonctionne en l’état », c’est prendre le risque réel de commencer à réagir quand on est déjà dans le mur. Et quand le produit ne se vends plus « parce qu’il est trop moche » et qu’on ne sait plus le redesigner en un temps raisonnable, parce qu’il utilise des techniques qui sont bloquées par défaut – à raison – par les navigateurs modernes, quand la concurrence arrive et fait mieux fonctionnellement avec 10x moins de boulot de paramétrage et 10x moins de boulot d’administration, c’est trop tard.
La vraie difficulté dans un projet à long terme – vraiment long pour de l’informatique, sur plus de 10 ans – c’est pas de « suivre la hype » ou de « rester conservateur ». C’est de bien découpler les différentes parties de son projet, d’identifier ce qu’il est pertinent de mettre à jour et de réussir à le faire, et ce en permanence, sans laisser un morceau pourrir dans un coin, et surtout sans re-créer du couplage inutile.
Une technologie moderne et qui apporte d’énormes avantages à un instant T (comme les JSP en 2000) peut devenir un boulet 20 ans plus tard (comme les JSP en 2020). De même, le code de 20 ans d’âge peut avoir été conçu selon des contraintes complètement obsolètes : toutes ces contorsions pour que le code puisse s’exécuter sur un serveur doté de 128 Mo de RAM peuvent être remplacées par quelque chose de plus rapide et plus facile à maintenir. Un
LEFT OUTER JOINsera plus lisible qu’untable1 = table2 (+). Etc.Je ne dis pas que c’est facile à faire, au contraire : la maintenance, c’est toujours risqué (régressions...), c’est un cout difficile à justifier, ça peut être long pour un résultat pas évident à court terme, et identifier quelles technologies sont à l’agonie et par quoi les remplacer est un exercice délicat. Mais un code qu’on a laissé pourrir dans un coin « parce que c’est fonctionnel » est tout aussi mauvais qu’un code qu’on passe son temps à modifier « pour suivre la hype ».
La connaissance libre : https://zestedesavoir.com