B.A.-BA d’un développeur : le fichier de configuration
fulgurio
Aller à son site
Voir ses articles
Cet article peut paraître un peu stupide, je vous entends déjà « mais évidemment qu’il faut faire ça ». Oui, mais j’ai déjà été confronté plusieurs fois à ce genre d’erreur, et je pense qu’il est intéressant d’expliquer en quoi c’est une erreur.
Dans la majorité de vos développements, vous avez à stocker des informations qui varient en fonction de votre environnement de travail. Par exemple, les accès à la base de données en environnement de production seront doivent être différents de l’environnement de développement.
Ces informations sont stockées dans le code source, et doivent être ABSOLUMENT regroupées dans un seul et même fichier.
Pourquoi ? Imaginons que chaque développeur mette dans son code ses propres paramètres. Cela fonctionne correctement sur son environnement de développement, mais pas sur les autres environnements. Il faut donc chercher les paramètres dans le code et les modifier afin de le faire fonctionner sur son environnement. Bref, on peut y passer du temps.
Pire, lors du déploiement du site internet, vous ne serez sans doute pas la personne qui déploiera le site. La tierce personne devra donc être avertie de l’emplacement de chaque paramètre. Ok, le déploiement n’a lieu qu’une seule fois, mais quid des évolutions ? On pourrait être amené à livrer une évolution, et lors du déploiement, impossible de rendre le site hors ligne pendant le paramétrage des nouveaux fichiers.
La majorité des outils (si ce n’est pas tous) utilise un fichier de configuration où l’on retrouve tous ces paramètres. Il suffit donc de modifier un seul et unique fichier pour que le site soit fonctionnel dans un nouvel environnement, par exemplie config.php.
Donc utilisez un unique fichier dans lequel vous mettrez tous vos paramètres ! Pensez aux autres développeurs qui utiliseront vote core ! 😉
Pour aller plus loin, l’idéal est d’avoir un fichier de paramètre pour la production et un second fichier pour le développement, et d’avoir un script qui charge le bon fichier en fonction de l’environnement. Comme ça, pas de sueurs froides lors de l’écrasement de la totalité des fichiers. Ce sera le sujet du prochain article.