Discussion :

[laurentSc]

Bonjour,

parti d'un code simple, en ajoutant des fonctionnalités, mes fichiers sont devenus extrêmement lourds (plus de 1200 lignes pour le plus gros). Il est donc clair que je dois décomposer mon code en plus de fichiers et de fonctions (ou méthodes, vu que c'est de la POO). Cela représente un travail considérable, donc je compte faire bon du premier coup. Auriez-vous une règle à me proposer (taille des fichiers ou autre) ?

[Cincinnatus]

Bonjour,

Il y a quelques années j'ai "hérité" d'une application PHP écrite selon les règles de ce qu'il ne faut pas faire. Entre autres, une fonction de 400 lignes dans un fichier de 4000 ...
Je me suis appuyé sur les idées de Michael Feathers : Working effectively with legacy code.

https://understandlegacycode.com/blo...h-legacy-code/

En trois lignes :
- analyser les fonctionnalités et dépendances de chaque bout de code, fonction ou classe, puis
- modifier le code un peu à la fois, vérifier que tout marche,
- et poursuivre.

Ah, et tout faire bien du premier coup, je ne connais pas...

[laurentSc]

modifier le code un peu à la fois, vérifier que tout marche,

Le problème, c'est que à l'heure actuelle, mon code est dans un état bogué (ça plante) et le corriger ne semble pas simple...

[xounet]

Personnellement j'utilise de gros fichiers scripts par fonctionnalité car je ne trouve pas pratique d'avoir "x" fichiers différents pour un programme qui dans l'absolu fait pas plus de 100 lignes...

Une idée essentielle que tu dois pratiquer sûrement, c'est de factoriser le code au maximum (je ne conseille pas de faire du 100% POO pour cela car la conception est trop complexe et prend un temps énorme pour un gain très faible je trouve personnellement), ça fait gagner beaucoup de lignes et cela va dans le sens que tu souhaites subdiviser le script... C'est aussi une façon de réécrire qui permet de prendre du recul et voir plus facilement les erreurs.


1200 lignes c'est pas énorme dans l'absolu, par contre si chaque programme comprends des références à des classes ou programmes extérieurs pour plusieurs centaines de lignes alors oui je comprends que cela devienne difficile à déboguer car tu dois inspecter toutes les références pour bien comprendre d'où vient le problème si je comprends...
Peut être réécrire tout le script depuis 0 en faisant un débogage ou un test à chaque fonction ou ligne écrite pour bien saisir le problème.

Il existe aussi des environnements d'exécution de php permettant un débogage très complet (indique en temps réel la valeur de toutes les variables et le point d'arrêt du programme), mais j'ai oublié le nom....

[Soundboy39]

Bonjour Laurent,

Quel qu’en soit la structure actuelle du code (100% procédurale, Objet mais avec des méthode comptant 300 lignes...), tu peux le réorganiser au fur et à mesure que tu debug et faire en sorte que les 2 structures cohabites.

La manière la plus simple est de rediriger la structure du code vers une architecture MVC, çà peut se faire au fur et à mesure du debug si tu n'a pas le temps et/ou la nécessité de tout refaire d'un coup.

Je sais par expérience qu'il faut se méfier des applications qui démarre petites et pour lesquelles on n'a pas forcément envi de mettre en place une architecture "complexe" contenant des classes et des méthodes bien distinctes... sauf qu'au fur et à mesure que les fonctionnalités vont s'ajouter... le code va prendre de plus en plus d'ampleur, et le debug va devenir de plus en plus compliqué...

[laurentSc]

Une idée essentielle que tu dois pratiquer sûrement, c'est de factoriser le code au maximum

Oui, je le fais déjà, mais ce que je ne faisais pas et ai décidé de le faire, c'est de décomposer le code en fonctions (ou méthodes dans mon cas) afin de le rendre beaucoup plus lisible.

Il existe aussi des environnements d'exécution de php permettant un débogage très complet (indique en temps réel la valeur de toutes les variables et le point d'arrêt du programme), mais j'ai oublié le nom....

Mon IDE est PhpStorm qui fait tout ça. Ca fait moins d'un an que je l'ai mais il me change la vie.

La manière la plus simple est de rediriger la structure du code vers une architecture MVC

C'est déjà la structure que j'ai adoptée. Le seul problème, c'est que dans cette structure, certaines méthodes sont devenues énormes et le debug est devenu hyper difficile, d'où je démarre un travail de morcellement.

Le problème, c'est que à l'heure actuelle, mon code est dans un état bogué (ça plante) et le corriger ne semble pas simple...

C'est quand même résolu

[CosmoKnacki]

Je dirais: ça dépend! En partant du principe 1 classe (et rien d'autre) = 1 fichier, 1200 lignes ça commence à faire (encore qu'il faille relativiser en considérant la quantité de commentaires et l'espacement) mais c'est le moment de se questionner:

• Est-ce que je ne cherche pas à faire trop de choses avec ma classe? Dont des taches qui sont étrangères à la nature de l'objet.
• Est-ce que j'ai des méthodes énormes?
• Est-ce que je me répètes.
• Est-ce que je n'aurais pas intérêt à créer d'autres classes.

Je n'ai pas vu ton code et ces questions sont très générales. Mais je te conseille de jeter un coup d'œil sur github pour voir comment est découpé le code source de symfony ou laravel (ou un autre gros projet). Tu verras que les classes sont très légères et qu'à chaque notion une classe correspond (quitte à ce qu'elle soit quasiment vide). L'idée est simple: il faut déléguer un maximum.

[cavo789]

Bonjour

Il existe de multiples standards (pas plus de xxx lignes / fonction, yyy lignes par fichiers / zzz niveaux de profondeurs par méthodes).

D'excellents outils d'analyse de code viennent t'aider lors de ta programmation : phpstan, phan, psalm, ... Voici quelques-uns de ceux que j'utilise avec leur lien : https://github.com/cavo789/uses#code-quality-tools

Selon ton éditeur (vscode pour moi), certains outils comme phan vont venir "râler" dans mon éditeur càd qu'ils vont me dire "Attention, là, telle fonction, fait plus de xxx lignes".

En tout premier lieu, je te conseille Phan qui est l'outil que tu recherches en cet instant.

Bonne journée et bonne programmation.

[grunk]

Il ne faut pas (trop) se focaliser sur le nombre de ligne d'un fichier. L'important est d'avoir une "navigation" claire et simple dans le code.
C'est compliquer de deboguer quand , pour une simple fonctionnalité tu te retrouve à jonglet avec 10 classes différentes qui s'échange des données.

1200 lignes ca peut être tout à fait normal si tout est cohérent. Par contre une fichier de 100 lignes avec 3 classes différentes dedans c'est moche.

Idem pour le nombre de ligne par fonction ou le nombre de caractère par ligne. Ce sont des règles la plus part du temps qui date du temps ou on avait des écran cathodique de 11 pouces et qu'on codait en ligne de commande. C'est des règles perpétuées par les intégristes de VI mais avec le matériel d'aujourd'hui ca n'a pas de sens de se limiter à 30 caractères par lignes ou 30 lignes par fonctions.

Voici quelques règles que je te conseillerais :

• Bon sens : si ca semble moche , si semble compliqué , c'est que ca l'est surement.
• 1 fichier par classe
• Limiter au maximum les responsabilité des classes. Ex : Ma classe Utilisateur , ne parse pas un fichier par exemple.
• Réduire les couplages dans la mesure du possible (injection de dépendance)
• Limiter la taille des fonctions sans pour autant tomber dans l'outrance : On sépare en plusieurs fonction si c'est nécessaire mais on évite de faire 10 fonctions de 5 lignes pour remplacer une fonction de 50 lignes.
• Ne pas trop abstraire les concepts : Par exemple mettre en place des design pattern complexes, "au cas ou" n'a pas de sens. Autant faire simple et on refactor plus tard si besoin.
• Eviter les codes complexe en 1 lignes, souvent décomposer un peu rend la lecture et donc le deboggage bien plus simple sans pour autant perdre en performance.

[cavo789]

Salut.

D'accord sur l'essentiel, je vais pinailler sur des détails qui me semblent importants.

C'est compliquer de deboguer quand , pour une simple fonctionnalité tu te retrouve à jonglet avec 10 classes différentes qui s'échange des données.

Peut-être si tu le fais à la mano mais si tu utilises un outil comme xdebug; c'est même encore plus simple puisque tu peux choisir de rentrer dans le code de telle fonction ou juste l'exécuter, ...

Par contre une fichier de 100 lignes avec 3 classes différentes dedans c'est moche.

C'est clair : une classe = un fichier. Sauf si le but est de fournir un script à quelqu'un "prêt à l'emploi" (et hop, copie ce fichier sur ton site et lance-le; bingo).
Une application avec un système de déploiement; un fichier par classe.

Idem pour le nombre de ligne par fonction ou le nombre de caractère par ligne. Ce sont des règles la plus part du temps qui date du temps ou on avait des écran cathodique de 11 pouces et qu'on codait en ligne de commande. C'est des règles perpétuées par les intégristes de VI mais avec le matériel d'aujourd'hui ca n'a pas de sens de se limiter à 30 caractères par lignes ou 30 lignes par fonctions.

L'idée est surtout de ne pas avoir à trop scroller (horizontal) et puis si la fonction est longue (verticale), cela peut faire sens de l'alléger en créant des "sous" fonctions.
Une telle sous-fonction pourrait à terme être utile à d'autres et réutilisée (ou pas).

Limiter la taille des fonctions sans pour autant tomber dans l'outrance : On sépare en plusieurs fonction si c'est nécessaire mais on évite de faire 10 fonctions de 5 lignes pour remplacer une fonction de 50 lignes.

Comme pour ce que je décrivais plus haut (xdebug), on peut alors passer au-dessus d'une fonction ou dans la fonction.
Est-ce qu'un file_exists() peut être une fonction à part entière; je dirais oui : dans cette fonction, je m'assure alors que le fichier existe et si pas, je lève une exception.
Idem pour un file_get_contents où je veux m'assurer que le fichier n'est pas vide, que son contenu est bien du JSON (ce ne sont que des exemples). Du coup, quand j'appelerai ma fonction JsonGetContent(); je n'aurais plus à me soucier de ces contrôles.

En créant des petites fonctions, je peux facilement intégrer des contrôles; je lève des exceptions, ... et mon code principal est terriblement plus simple à lire : je n'ai plus un "long" code mais une table des matières (j'appelle la fonction 1 puis 2 puis 3) et cela me donne l'aperçu de cette fonction, facile à lire et facile à maintenir.

La programmation, c'est une affaire de goûts et de couleurs; du moment que le code est propre et te plaît/plaît aux standards de ton team, c'est tout bon.

Le goût et l'expérience feront évoluer les standards

Bonne journée.

[laurentSc]

Peut-être si tu le fais à la mano mais si tu utilises un outil comme xdebug; c'est même encore plus simple puisque tu peux choisir de rentrer dans le code de telle fonction ou juste l'exécuter, ...

Avec l'IDE que j'utilise depuis ce printemps (PhpStorm), je peux faire du debug (avec Xdebug).

L'idée est surtout de ne pas avoir à trop scroller (horizontal) et puis si la fonction est longue (verticale), cela peut faire sens de l'alléger en créant des "sous" fonctions.
Une telle sous-fonction pourrait à terme être utile à d'autres et réutilisée (ou pas).

Pour éviter le scrollage horizontal, il y a dans PhpStorm une fonctionnalité (Soft-Wrap) qui remet en page le code pour que tout tienne dans la largeur de l'écran...Pour améliorer la lisibilité, OK pour le découpage en sous-fonctions.

La programmation, c'est une affaire de couleurs

Si le code est bleu, ça me va

Petit apparté sur PhpStorm : quand, je suis passé de VSCODE à PhpStorm, ça m'a changé la vie. Le premier est gratuit mais pas le second..

[cavo789]

Petit apparté sur PhpStorm : quand, je suis passé de VSCODE à PhpStorm, ça m'a changé la vie. Le premier est gratuit mais pas le second..

Qu'apprécies-tu dans PhpStorm que tu n'aurais pas avec vscode ? Juste pour savoir...

[grunk]

Salut.

Peut-être si tu le fais à la mano mais si tu utilises un outil comme xdebug; c'est même encore plus simple puisque tu peux choisir de rentrer dans le code de telle fonction ou juste l'exécuter, ...

Même avec un debugger classique c'est quand même plus compliquer de cheminer de classe en classe plutôt que de rester dans le même fichier.
Quand tu fais un aller retour entre 2 classes pas de problème.

Quand tu as des codes plus complexe , c'est une autre histoire. J'ai certains projets (C++) ou un point d'entrée déclenche un cheminement dans des dizaines de classes , des dizaines de thread , des bus d'événements ... même avec un bon debugger tu pleure un petit moment avant de comprendre parfaitement le cheminement Dans ce cas précis la complexité se justifie , mais parfois on pourrait s'éviter quelques noeuds au cerveau en ayant une conception plus légère dès le départ.

Petit apparté sur PhpStorm : quand, je suis passé de VSCODE à PhpStorm, ça m'a changé la vie. Le premier est gratuit mais pas le second..

Qu'apprécies-tu dans PhpStorm que tu n'aurais pas avec vscode ? Juste pour savoir...

Sur de l'utilisation "normale" je pense pas que vscode soit si à la bourre que ca pour peux que tu es les bon plugins.
En revanche l'avantage de PHPstorm c'est que tu passes pas trois plombe à le configurer. Ca marche tout de suite , ca supporte plein de framework.
C'est juste l'approche inverse de vscode : J'ai tout ce qui faut pour travailler tout de suite, et éventullement j'ajoute une extension pour le truc un peu exotique qui me manque.

[laurentSc]

J'ai énormément gagné en productivité.

Un exemple : si on veut savoir où une méthode est utilisée, Alt+F7, et ça te le dit (nom du fichier et numéro de la ligne).

Autre point : Xdebug ; je ne suis pas un expert et j'ai déjà lu que tu l'utilisais avec vscode ; moi, je ne savais pas le faire, mais avec l'aide d'un expert (ex-modo de DVP), c'est intégré dans PhpStorm.

C'est tout ce qui me vient à l'esprit tout de suite, mais y a sûrement d'autres points.

[cavo789]

En effet, vscode vient tout "nu" et il faut y ajouter les extensions pour être vraiment à l'aise en développant avec PHP; c'est tout à fait juste.
Par contre, vscode sert à ... tout (écrire des scripts Powershell, du bash, du php, du markdown, ...). A tout puisqu'il "suffit" (=prendre le temps de) le configurer pour son projet.

VSCode me sert à tout; même à écrire ma documentation (en markdown qui est ensuite convertie en html/docx/pdf ou n'importe quel autre format; merci pandoc).

Pour xdebug, voici un petit tuto technique https://github.com/cavo789/vscode_ti...-xdebug-xdebug

Pour le ALT-F7, je n'ai pas l'info qui me vient immédiatement en tête car je fais le contraire; de mon utilisation d'une méthode, je remonte au parent (intelliphense). Nul doute que vscode le fait avec ses outils de refactorisation.

(merci pour l'apparté)

[laurentSc]

Pour la refactorisation (merci de m'y faire penser), c'est intégré dans PhpStorm, et je l'ai découvert par hasard, en fouillant dans le menu, car je savais même pas que ça existait ! (Avant, je le faisais à la main : fastidieux et grosse source de bugs).

Ce qui est aussi intégré, c'est la génération de PhpDoc (pareil, je connaissais pas).

[CosmoKnacki]

VSCode me sert à tout; même à écrire ma documentation (en markdown ...

Puisque tu parles du markdown dans vscode, connais-tu un moyen pour obtenir la coloration syntaxique des sections de code dans la preview?

[cavo789]

Bonjour

Je ne fais aucun preview dans vscode, désolé, aucune piste à te donner.

[cavo789]

Ce qui est aussi intégré, c'est la génération de PhpDoc (pareil, je connaissais pas).

Phpdoc est un outil 100% gratuit et qu'on installe avec l'outil composer. Cela rejoint ce qu'on disait plus haut : ton éditeur te prémache toutes ces installations / configurations, c'est un éditeur ultra dédicacé.

Tu peux l'intégrer sous forme de tâche dans vscode 😉

[grunk]

Perso j'utilise les deux outils pour des sujet différents. Par exemple pour PHP je préfère phpstorm , ultra complet .

En revanche pour le front (angular majoritairement) je préfère vscode a webstorm. Quasi rien a installer et on se retrouve avec un IDE hyper léger. Il n'y a que le refactoring et la recherche qui me manque de temps à autre.

Il faut reconnaître que très souvent une fois qu'on a goûté a un IDE jetbtains on a du mal a revenir en arrière.