Etant en train de mettre à jour un site réalisé sous SPIP 1.7 vers SPIP 1.9.2c (soit un écart proche de *21* versions intermédiaires (majeures ou mineures), voici quelques retours :
- Ne pas suivre la mise à jour de l'outil qu'on utilise, c'est très mal. Avoir en tête tous les changements qui ont eu lieu entre ces versions relèvent parfois du casse-tête. Bon en même temps, un bug sur le critère titre_mot a empêché une mise à jour de l'outil pendant longtemps (au moins la version 1.8.2e, soit déjà 10 versions d'écart).
- Ne pas documenter le code (php ou les squelettes SPIP), c'est mal aussi.
- Ne pas conserver les sources des animations flash, c'est mal aussi (pour le coup, cela m'a simplement obligé à utiliser un lien symbolique suite à la réorganisation du bazar)
Du coup, on peut raisonnablement se dire que pour assurer la pérénité de son projet, il faut :
- Documenter le code de façon satisfaisante :
- Utilisation de la javadoc, phpdoc, ...
- Utilisation de la balise REM pour les squelettes SPIP expliquant chaque boucle ou bloc de boucle (notamment avec les boucles HIERARCHIES)
- Documenter le fonctionnement du site, les règles de gestion, la raison d'être des différents articles, etc que ce soit dans un document externe ou au sein des squelettes par ex
- Le code ne correspondant pas au code source de l'application doit être clairement identifiable.
- Seul le code source spécifique au projet doit dès lors être dans le gestionnaire de source du projet
- Suivre les mises à jour de l'outil au fur et à mesure en tirant parti des nouvelles fonctionnalités
- Le nouveau compilateur (plus oblige a réécrire certaines boucles vu qu'il est moins laxiste que précédemment.
- L'apparition de
#DOSSIER_SQUELETTEpuis deCHEMIN{}permet ainsi de centraliser tous les éléments de vos squelettes et vous donne une plus grande flexibilité (plus de chemin en dur par ex) - Le coût de la mise à jour est alors minime et réparti - plutôt qu'un gros coup prohibitif lors de la mise à jour 21 versions plus tard, risquant de plonger votre projet dans l'immobilisme total...
- La transformation de certains bouts de code en plugins SPIP (notamment pour des éléments insérés dans la partie privée) est un réel plus et améliore la lisibilité de votre site/code.
- Suivre les mises à jour pour bénéficier des correctifs de sécurité
- Sans oublier que la mise en page par tableaux, c'est une horreur à maintenir, illisible, etc.
La liste n'est sans doute pas exhaustive mais déjà rien que pour ce projet, je peux mettre un zéro pointé partout. Alors certes, un bug SPIP corrigé en 1.8.2e empêchait toute mise à jour vers la version 1.8 de l'outil, mais depuis, cela aurait du être fait proprement.
En tous cas, ça vous donne plein de bonnes pratiques pour vos prochains projets perso / cahier des charges / mode de gestion de projet / ... ; si ça vous en donne pas, moi si !
