Alors que je fais la migration de mon site, je me rends compte que cela prend du temps, trop de temps, quand on sait qu’il n’y a que quelques méga-octets. C’est vrai que ma connexion ADSL n’est pas des plus rapides (je n’ai pas la chance d’habiter une grande ville dégroupée) mais cette lenteur est essentiellement dûe à la quantité de petits fichiers: fichiers de configuration, fichiers de localisation, fichiers pour les bibliothèques, fichiers de cache, etc. On atteint rapidement un nombre de fichiers à 4 voire 5 chiffres. Cela en fait des requêtes FTP lors d’une migration vers un autre serveur ou pour une sauvegarde tout simplement.
La solution idéale serait de faire une archive tar du site entier pour la télécharger ensuite mais sur la majorité des hébergements mutualisés il n’est pas envisageable d’avoir accès à un shell.
Et là je me dis que ce serait bien si les applications réduisaient un peu le nombre de fichiers. Dans des applications courantes en PHP, on retrouve souvent le paradigme venant de Java où une classe correspond à un fichier (même si on peut faire le contraire) alors qu’on pourrait facilement grouper plusieurs classes dans un seul fichier lorsqu’elles sont liées. On évite par la même occasion le nombre d’accès au système de fichiers comme l’évoque Michael J. Radwin lors du petit bilan qu’il fait après un an de PHP chez Yahoo!.
Pour le moment j’y vois des avantages pour la redistribution et la sauvegarde d’une application mais cela doit sûrement avoir une contrepartie pour les développeurs. Il peut alors devenir plus compliqué de travailler à plusieurs ou tout simplement de s’y retrouver dans du code plus long dans un même fichier. Mais je me dis que finalement, c’est pour l’utilisateur qu’on travaille, alors on peut bien faire quelques concessions.
La solution qui pourrait être satisfaisante pour tout le monde serait que la réduction du nombre de fichiers soit automatisée. Une piste à creuser, qu’en pensez-vous ?
(au passage, si vous lisez ces lignes, c’est que vous êtes sur le nouveau serveur)
6 replies on “Organiser ses classes en PHP”
Tu es hébergé où maintenant ? Et avant ?
Et surtout pourquoi as-tu changé ?
PHPar ou la “possible solution”. bon personnelement je viens tout jsute de découvrir et je n’ai fait aucune recherche poussé sur le sujet … mais c’est peut être à approfondir. (!!! bien sur ce n’est à envisager que pour les devt PHP 5.1 et supérieur)
C’est vrai qu’un petit SSH limité au repertoire
/home/compteserait vraiment pratique… M’enfin faut pas rêver.Sinon on pourrait envisager une interface web qui permettrait d’uploader/decompacter une archive sur le serveur hôte. C’est même assez simple, réalisable en PHP tout bête. Peut-être même que ça existe déjà…. Sinon, c’est à faire 🙂
Je me rappelle que Citeglobe offrait automatiquement un accès Shell pour tous les comptes, mais c’etait il y’a environ 3 ans je crois, et cela n’existe malheureusement plus. Sinon, comme le dit Niko, un simple fichier tar decompressé par un fichier PHP serait très facile à faire. Pour ma part, je trouve que d’avoir beaucoup de fichiers séparés est plutôt une bonne chose lors du developpement, ne serait-ce que pour la lisibilité et la maintenance simplifiée de même que le travail en groupe. Et d’un autre coté, uploader un site, ce n’est pas quelque chose qui se fait tous les jours… A mon avis, le principal inconvénient des sites tenant en de nombreux fichier reste les nombreux accès disque necessité par l’appel d’une page PHP.
Ce qui est gênant avec les gros fichiers ( disons plus de 5000 lignes, quand on sait qu’une classe bien commentée en prend souvent plus de 1000 ), c’est que les éditeurs tels que Ultra-Edit 32 mettent tréééééés longtemps à ouvrir le fichier … 🙁
Par contre, il me semble qu’une extension php existe pour la compression / décompression, si je vois juste, il suffit de créer un miniscript php permettant juste de décompresser un .tar(.gz), de l’uploader, d’uploader l’archive et de faire tourner le script …
A moins que ce ne soit déjà de ca dont vous parliez 😀 ( désolé du paragraphe inutile dans ce cas :-° ).
En effet, idée à explorer 🙂
hjkl