Une branche stable qui ne fait que des fix de sécurité, 0 modifs de "l'API de configuration" (une conf, c'est un peu comme une API si on y pense, non?), et une branche "dev" qui comprend les ajouts/suppressions/modif de features, avec des changelog qui expliquent que telle ou telle option à vu son comportement modifié.
Pour le coup, séparer les données du code à un intérêt: on peu faire autant de MaJ de sécu qu'on veux, ça ne touche pas à la config.
Pour être honnête, cette manie de mêler le code et des constantes, c'est quelque chose qui m'a valu de nombreuses heure de débogage, et maintenant, quand j'ai une donnée initialisée par une constante qui n'a rien a voir avec le fonctionnement interne de mon appli (genre, par 0 ou 1 en fonction des index de tableau, ou un code/message d'erreur que je mets dans le texte décrivant l'erreur), ça dégage dans un fichier de conf (que la configuration aie lieu à la compilation où à l'exécution ne change pas que ça reste de la configuration) , séparé de la logique du code.
L'autre point sympa, outre la maintenance, c'est que ça génère de facto un logiciel plus souple, avec moins de limites codées en dur et pénibles à faire évoluer (je trouve que "%s/…/…/g" c'est long à taper, et encore pire quand ça contiens des /, . ou autres joyeusetés)
[^] # Re: Et pour en remettre une couche
Posté par freem . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Si, il y en a une:
Une branche stable qui ne fait que des fix de sécurité, 0 modifs de "l'API de configuration" (une conf, c'est un peu comme une API si on y pense, non?), et une branche "dev" qui comprend les ajouts/suppressions/modif de features, avec des changelog qui expliquent que telle ou telle option à vu son comportement modifié.
Pour le coup, séparer les données du code à un intérêt: on peu faire autant de MaJ de sécu qu'on veux, ça ne touche pas à la config.
Pour être honnête, cette manie de mêler le code et des constantes, c'est quelque chose qui m'a valu de nombreuses heure de débogage, et maintenant, quand j'ai une donnée initialisée par une constante qui n'a rien a voir avec le fonctionnement interne de mon appli (genre, par 0 ou 1 en fonction des index de tableau, ou un code/message d'erreur que je mets dans le texte décrivant l'erreur), ça dégage dans un fichier de conf (que la configuration aie lieu à la compilation où à l'exécution ne change pas que ça reste de la configuration) , séparé de la logique du code.
L'autre point sympa, outre la maintenance, c'est que ça génère de facto un logiciel plus souple, avec moins de limites codées en dur et pénibles à faire évoluer (je trouve que "%s/…/…/g" c'est long à taper, et encore pire quand ça contiens des /, . ou autres joyeusetés)