Pendant tout le temps de mon travail avec Bitrix, j'ai eu l'opportunité de travailler avec un très grand nombre de projets que quelqu'un a développés avant moi. Voici des améliorations mineures, correction de divers bugs et erreurs de logique, refonte du site Web et modifications globales des fonctionnalités existantes. Et, comme tout autre développeur, je déteste ratisser les poubelles, les béquilles et les correctifs «temporaires» de quelqu'un d'autre, qui sont en fait rappelés par une autre 8 édition du produit.
Ici, j'essaierai de ne pas me concentrer sur les «pires pratiques» standard lors de la programmation en PHP, telles que le non-respect du choix des noms et des fonctions des variables, les requêtes de base de données inutiles dans une boucle, le manque de vérification des données utilisateur dans les formulaires, l'ignorance des commentaires et autres. Je vais essayer de toucher exactement les moments inhérents au développement sur Bitrix, qui permettront par la suite d'éviter l'indignation et les malédictions contre vous de la part du programmeur qui devait accompagner votre code. Et oui, vous deviendrez souvent ce programmeur vous-même dans un an, ou plus, lorsque vous oublierez complètement pourquoi vous avez inséré telle ou telle béquille ici.
«Écrivez le code comme s'il serait accompagné d'un psychopathe violent qui sait où vous vivez» (c) John F. Woods
Le premier, et le plus, à mon avis, important - pour l'amour du ciel,
utilisez le dossier local . C'est tout simplement vital lorsque vous utilisez le système de contrôle de version - tout ce que vous avez à faire est d'ajouter le dossier / bitrix / aux exceptions. C’est tout. De plus, presque tout le développement n'est effectué qu'en lui. Cela simplifie considérablement la recherche des fichiers et composants nécessaires par la suite, aide à ne pas obstruer le référentiel avec des fichiers inutiles, et en effet - il donne à l'arborescence du projet une apparence plus «humaine».
Ne modifiez pas le noyau . Même si vous êtes sûr qu'il ne sera pas mis à jour. Même si c'est plus rapide. Même si vous êtes paresseux. Oubliez cette pensée comme un cauchemar. Si vous devez modifier la logique d'un composant standard, transférez-le dans le nouvel espace de noms / local / components / modify / et travaillez avec. Il en va de même pour les modules, gadgets et activités des processus métier.
Ne salissez pas le fichier init.php . Combinez des fonctions pour travailler avec un module spécifique ou une fonction dans une classe, écrivez cette classe entière dans un fichier séparé, et dans init.php, incluez simplement ces fichiers et écrivez des gestionnaires d'événements. J'ai rencontré des fichiers init.php de 500 Ko chacun, où les fonctions, la définition des constantes, les classes et l'initialisation des gestionnaires étaient mélangées dans un désordre. Bien sûr, quand j'ai dû comprendre ces fichiers, j'ai maudit mes prédécesseurs.
Le paragraphe suivant ne concerne pas le cas du développement de solutions prêtes à l'emploi pour la Marketplace, lorsque l'objectif est de rendre la fonctionnalité la plus personnalisable de la partie publique pour l'utilisateur final. Si vous travaillez sur un projet spécifique, sur un mandat spécifique -
n'essayez pas de créer un modèle unifié pour le composant pour toutes les occasions . Personnellement, j'adhère à une philosophie - il vaut mieux avoir quelques modèles simples qui sont utilisés à des fins différentes de celui universel, mais dans lequel le diable se cassera la jambe plus tard. Bien sûr, dans chaque cas, vous devez vous appuyer sur ce qui est - les termes de référence, les options de mise en œuvre, etc., mais vous ne devez pas oublier le rasoir d'Occam. À titre d'exemple, je vais vous donner un projet d'une société de crédit-bail, que j'ai édité. Le projet lui-même, bien sûr, a été mis en œuvre horriblement; à la grande horreur, il était dans les pages d'une section du catalogue de services. Chacune des cinq sections avait sa propre disposition, sur laquelle la position des blocs sur la page et, en principe, la présence de certains d'entre eux différaient. Et pour les cinq pages, un modèle a été utilisé avec un tas d'if-else, la duplication des appels de composants, les styles de connexion et les scripts, qui, de plus, étaient périodiquement en conflit les uns avec les autres. En conséquence - un énorme fichier dans lequel comprendre "sans une pinte" était comme la mort. Bien que, semble-t-il, qu'est-ce qui vous a empêché de créer 5 modèles différents et de ne pas créer de difficultés à l'improviste?
Utilisez l'API . Ne réinventez pas la roue là où elle n'est pas nécessaire. Utilisez la documentation - l'ensemble du produit est assez bien décrit, et chaque fonction peut également être consultée en détail sur bxapi.ru.
Évitez les requêtes de base de données directes . Ceci est un cas particulier du paragraphe précédent - utilisez l'API. Les demandes hâtives et non sécurisées peuvent entraîner une corruption, une perte ou même un compromis des données.
N'utilisez pas de composants CNC depuis la racine du site . Les conséquences, en règle générale, sont plutôt tristes, car la CNC utilise un fichier de gestionnaire d'adresses, une tentative de l'utiliser à partir de la racine casse facilement l'adresse d'autres composants, ainsi que 404 pages. Il n'y aura rien de mal si les articles que vous avez sont adressés au dossier / articles / et que les produits sont relatifs à / catalogue /.
Connectez css et js à l'aide de l'API. Je vois toujours des scripts et des feuilles de style utilisant des balises html partout. Utilisez l'objet de classe \ Bitrix \ Main \ Page \ Asset et les fonctions addJs () et addCss (). Cela permettra de combiner des fichiers et, par la suite, de les mettre en cache en un clic de la case à cocher dans les paramètres du module principal
Et enfin, l'erreur concerne non seulement Bitrix, mais c'était déjà trop douloureux pour moi de rencontrer des problèmes qui lui sont associés.
Vérifiez pour annuler le tableau avec les résultats de la sélection . Par exemple, la dernière fois que j'ai rencontré ce problème, c'était lorsque je travaillais avec une boutique en ligne. Plainte: les pages se chargent parfois pendant 16 secondes. Ce qui est lié à n'est pas clair. Par essais et erreurs, j'ai découvert que les pages sont chargées indécemment longtemps uniquement lorsque le panier est vide. Il semblait, pourquoi? Il s'est avéré qu'une fenêtre contextuelle est apparue dans le panier en vol stationnaire, dans laquelle des images des marchandises placées dans le panier ont été affichées. Eh bien, qu'a fait le développeur précédent? J'ai pris le résultat du composant "petit panier" et dans le fichier result_modifier.php j'ai fait un appel GetList () pour que les marchandises sélectionnent des images avec un filtre dans le tableau des ID de produit, puis j'ai ajouté des images src des résultats de la sélection au tableau du produit correspondant. Par conséquent, lorsqu'il n'y avait aucune marchandise dans le panier, le filtre est resté vide et le catalogue ENTIER des marchandises est tombé dans la sélection. Eh bien, puis un cycle pour chacun et ... nous avons ce que nous avons. Il est clair qu'au stade de développement des produits d'essai 15, cela était imperceptible et des problèmes se posaient déjà dans des conditions de combat. Bien qu'il semble que cela valait la peine de mettre le chèque à vide ($ arResult ['ITEMS']) ...
C'est là que je termine ma «pire pratique» personnelle concernant le développement Bitrix. Si au moins quelqu'un, ces informations aideront à éviter les erreurs à l'avenir et à améliorer son style de développement, ce n'était pas en vain.