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