En regardant le code actuel de WordPress, il est clair que les fonctions sont surutilisées. Mon compte est supérieur à 8 100 fonctions/méthodes définies dans la base de code WordPress. C'est terrible, et une utilisation terrible des ressources.
Le problème avec tant de fonctions (ou classes) est que cela signifie que wordpress n'est pas DRY (ne vous répétez pas) et je suis sûr que beaucoup de ces blocs pourraient être combinés ou remplacés par de meilleurs modèles .
Cependant, nous avons besoin d'une certaine manière pour mettre l'API actuelle (toutes ces fonctions) en mémoire tampon afin de pouvoir commencer à combiner le code de base sans changer "l'interface" (utilisée de manière vague).
PHP 5 & 6 a SPL Autoloading de classes. C'est une fonctionnalité qui permet à PHP d'attendre d'avoir besoin d'une classe avant de la charger. Ceci évite le gaspillage de ressources car les fichiers/fonctionnalités inutilisés ne sont pas chargés tant qu'ils ne sont pas nécessaires.
Malheureusement, WordPress ne peut pas utiliser cela car "l'autoloading" dans PHP ne fonctionne que pour les classes .. et WordPress est une montagne de fonctions.
Je cherche des options et des défis pour nettoyer le code Word de WordPress et cela semble être le plus important.
Parce que WordPress a créé tellement de fonctions (plutôt que d’exposer des classes) pour les développeurs de plugins/thèmes, il semble qu’il n’y ait aucun moyen de sortir de ce trou profond sans casser des milliers de thèmes et de plugins.
La seule idée que j'ai pu imaginer est d'écrire un script qui examinerait toutes les fonctions et les convertirait en classes pouvant ensuite être chargées automatiquement. A leur place, il resterait des fonctions de shell appelées la version class-i-fied de la fonction.
Quelque chose comme ça:
function wp_foo_bar() {
call_user_func_array(array('foo' => __FUNCTION__), func_get_args());
}
Quelqu'un at-il essayé de nettoyer le code Word de WordPress? Y a-t-il d'autres problèmes avec cette approche?
La conversion du système pour utiliser le chargement automatique est la première étape qui nous permet de mieux contrôler le chargement des ressources et de mettre en place des façades à mesure que nous migrons certaines des fonctionnalités principales vers de meilleures conceptions. Il est beaucoup plus difficile de déprécier des fonctions. Par conséquent, cette question commence par le début de la réécriture du système.
Si nous nous arrêtions ici - nous risquions alors de subir une perte nette de performances car nous avions le même nombre de fonctions - et maintenant les classes commencent également à être chargées automatiquement.
Par conséquent, cela n'a rien à voir avec le code de procédure vs OOP . Il s'agit du meilleur moyen de protéger l'API contre les modifications apportées au système dans son ensemble. L’actuelle équipe de développement wordpress le fait déjà à un rythme très lent. Il y a déjà plus de 60 classes dans le système wordpress.
Vous présumez énormément qu'une telle solution améliorerait les performances. Spoiler - non, ce ne sera pas.
Le processus de chargementen termes très souplesest composé de:
Le "chargement automatique est rapide" est une erreur populaire. Le chargement automatique le plus important estconvenient. Il est possible queralentisse les chosesen pratique car le traitement des fichiers est énormément amélioré par le cache opcode, mais plusieurs foislocatingces fichiers (étape 1) ne peuvent être que optimisé jusqu'ici et ajoute très vite.
WordPress bénéficierait-il d’une meilleure organisation et d’un chargement automatique des classes? Cela n’est certes pas le cas, car il a été développé sur la base de la non-utilisation de cette fonctionnalité de PHP.
Mais "convertir" des fonctions en classes à chargement automatique? Je pense que cela nuirait à la performance, tout en essayant d’optimiser une partie du processus qui n’est pas prioritaire au premier abord (dans l’état actuel du code de base/de la charge).
le code fonctionnel interprété sera toujours plus rapide que OOP one. Comparer
function hello_mark() {
echo 'hello mark';
}
hello_mark();
avec
class mark {
function say_hi() {
echo 'hello mark';
}
}
$m = new mark();
$m->say_hi();
Je pense que ce qui est plus rapide à interpréter et à exécuter est évident.
Les gens ne font pas OOP parce que c'est plus rapide, ils le font parce que cela représente mieux le "domaine problématique" et produit un code plus facile à gérer.
Le code censé être organisé de manière à être plus facile à maintenir et à développer, afin d’accéder plus rapidement à de meilleurs interprètes, à une compilation en code machine ou à un hip-hop de Facebook, réduit les fonctionnalités de la langue que vous supportez et serveur Web dans votre interprète.
Pour Wordpress, ce qui influence le plus la vitesse du site, c’est la qualité de la mise en cache utilisée. Aucune amélioration du code php ne vous procurera les mêmes performances que l'utilisation de la mise en cache d'objets.
Quoi qu'il en soit, le fait que de nombreuses fonctions ne soient pas chargées paresseusement ne signifie pas que même sous un chargement paresseux, elles ne le seront pas avant que wordpress termine son initialisation. donnez aux développeurs principaux le mérite de connaître suffisamment le langage pour pouvoir placer les fonctions inutiles pour l’initialisation dans leurs propres fichiers lorsque cela ne rompt pas la structure logique du logiciel (c’est-à-dire que ce sera stupide update_option dans un autre fichier puis delete_option simplement parce que delete_option n'est pas appelé lors de l'initialisation)
Bonne chance à vous, mais cela n'améliorera pas les performances de manière réelle.
WordPress devient en effet de plus en plus orienté objet, avec le temps et avec des modifications incrémentielles. Chaque mise à jour effectuée au cours des 4 dernières années a transformé un élément de code majeur en une conception davantage orientée classe.
Néanmoins, OO, l'autoload et d'autres éléments de ce type ne sont pas intrinsèquement "plus rapides", ni réellement "meilleurs". Pas de souci cependant, c'est une erreur commune.
La programmation orientée objet en général est un mode d'organisation différent. C'est une approche plus saine et plus propre dans de nombreux cas. Mais ce n’est pas intrinsèquement "meilleur", et c’est en fait beaucoup plus lent et plus gourmand en mémoire dans la plupart des scénarios réels, ou au mieux, il est équilibré. Le modèle OOP est généralement préféré car a) il est plus facile de procéder à la maintenance et aux tests de code, b) il est enseigné dans de nombreuses écoles comme étant la "manière" correcte, et c) les programmeurs sont le genre de personnes qui aime construire des modèles de choses. OOP correspond bien à cette mentalité de "modèle". Représentez une "chose" en utilisant un seul morceau de code, puis faites en sorte que vos "choses" interagissent avec d'autres "choses", comme assembler des pièces de lego. Soigné, propre, bien rangé. :)
La vérité est que, avec des opérations telles que la mise en cache des opcode, le chargement automatique ne procure pratiquement aucun avantage en termes de rapidité, mais simplement des avantages organisationnels. Et ne vous méprenez pas, un avantage est un avantage et une meilleure organisation est une bonne chose. Mais vous obtenez une meilleure organisation en organisant des tâches et non en utilisant des processus automatisés.
Pouvez-vous écrire du code pour déplacer tout le code dans des classes, puis rendre les fonctions plus simples dans ces classes? Bien sûr, probablement. Qu'est-ce que ça va aider? Rien de substance.
Pour répondre à vos désirs spécifiques:
Il est beaucoup plus difficile de déprécier des fonctions. Par conséquent, cette question commence par le début de la réécriture du système.
Premièrement, je pense que vous vouliez dire "déconseiller".
Deuxièmement, vous ne pouvez pas tout réécrire en une fois et atteindre vos objectifs. C'est un peu tout ce que je veux dire. Revenez en arrière et regardez 3.1 ou 3.2. Maintenant, regardons 4.0. Notez le nombre de classes et la manière dont elles sont effectivement refacturées au fil du temps.
Cela n'a aucun sens de passer beaucoup de temps à réécrire du code fonctionnel pour aboutir aux mêmes résultats, à moins que vous ne l'amélioriez réellement au cours du processus. À mesure que chaque élément de WordPress est amélioré, il est généralement modifié dans un système de classe/POO. Évolution progressive. Changez avec le temps, pour permettre aux anciens plugins de disparaître et de créer du nouveau code pour le supporter et être corrigé, etc. Vous ne pouvez pas briser le monde du jour au lendemain et attendre de tout le monde qu'il vous suive, vous devez changer les choses lentement et méthodiquement.
@Xeoncross,
Vous écrivez dans votre WP profil de développeur
Vous remarquerez peut-être que certaines de mes questions vont au fond des choses, car je m'efforce d'optimiser au maximum les applications.
C'est très bien pour une application, votre application ou une application sur laquelle vous travaillez; ou votre propre philosophie et techniques de programmation.
Mais Wordpress est une communauté et, en tant que telle, fonctionne différemment. Cela peut sacrifier (faute d'un meilleur mot) des choses en termes de structures de programmation, de langages et d'efficacité qui sont prioritaires pour des projets petits ou individuels.
Mais Wordpress gagne beaucoup en tant que communauté. L’écosystème est vaste et varié, le développement se poursuit et en conséquence, ou malgré, WordPress est très populaire.
En tant que communauté, Wordpress ne peut pas supposer agir de la même manière qu'un projet individuel ou un développeur peut fonctionner.
Vous comparez des pommes et des oranges, ainsi que les arbres sur lesquels elles poussent et les gens qui aiment les pommes mieux que les oranges.
Je ne me considère pas comme un programmeur, et je ne peux pas discuter des avantages et des mérites de la programmation orientée objet, des cours, des procédures, etc.