Reprise du message précédent :

Je ne peux pas prédire l'avenir mais quand j'ai commencé à dév mon appli métier (environ 200 000 lignes de code avec les plugins) en 2003, si j'étais parti sur les framework de l'époque, j'aurais été bien dans le caca aujourd'hui, plus aucun existant Pareil pour les libs JS. Du coup, dans 10 ans, est-ce qu'on aura toujours les framework actuels ? Des trucs comme Angular, React ou Vue ou autre, j'en ai vu passer en 20 ans. C'est régulièrement remplacé par une nouvelle lib à la mode. Etant seul à développer et le portage d'une appli d'un framework à un autre étant lourd, je peux peut pas m'amuser à suivre le framework à la mode tous les 5 ans Tu as raison, je développe des applis dans un cadre bien spécifique : peu d'utilisateurs (au max 100), applis sur un LAN ou réseau WAN d'entreprise, un nb faible de pages différentes (environ 100 écrans différents).
 
Par contre, je fait attention à l'accessibilité de mes applis en particulier aux personnes déficientes visuels. La tendance actuelle au one-page est une catastrophe pour ce type de personne, leur lecteur d'écran ne détectant en général pas les zones où le contenu a été mis à jour. Raison pour laquelle je suis resté sur un écran = une url. Ca permet aussi de rendre l'appli web beaucoup plus facilement scriptable
 
Bref, j'essaye de trouver l'archi technique la plus simple et la plus facilement maintenable dans le temps vu que mes clients veulent bien payer pour de nouvelles fonctions mais pas trop pour juste faire un changement de lib/framework. Avec ma façon de faire, j'ai pas trop mal réussi ces 20 premières années en traversant 4 versions majeurs de PHP sans avoir à reprendre trop de code (moins de 100 lignes sur 200 000 pour passer de PHP5 à PHP8)

 
...et en toute vraisemblance quasiment l'intégralité de l'appli serait écrite différemment avec du "vrai" php 8 qui profite des évolutions du langage.
C'est la version light du "je fais du C++" et quand tu regardes le code c'est du C avec des classes ton histoire.

Perso, le seul framework que je connaisse et utilise c'est jQuery parce que ça me fait gagner beaucoup de temps sur ces conneries de JS, les autres ne m'intéressent pas (et encore jQuery, j'ai tendance à me faire une sorte de lib perso en Vanilla, qui répond à mes besoins).
Et là, je suis en train de virer tous les Ajax pour migrer sur FetchAPI.
Le reste je vois pas l'intérêt de maitriser plusieurs frameworks frontend, il y en a tellement une chiée... sans parler du stack pour tout mettre en place (je me restreint à sass + webpack)

Oui, tout à fait. En 2003, le modèle objet du PHP était vraiment peu mature. J'ai donc fait le choix de tout écrire en procédural, pas de POO, me disant que l'objet m'apporterait pas une grosse plus-value à cette époque de PHP. Hors, c'est l'aspect objet qui a le plus évolué entre les différentes versions de PHP ce qui aurait nécessité de faire pas mal de réécriture de code pour passer aux différentes versions majeurs de PHP. Je me suis donc épargné ça

 
Par curiosité, pour quelle(s) raison(s) ?

 
ouch. 200K lignes de php en procédural. Bon courage à celui qui devra reprendre le bébé un jour.

Théoriquement ça pourrait être du PHP bien modularisé et structuré, c'est pas parce que c'est procédural que c'est imbitable: git c'est 250kLOC de C et c'est relativement lisible, j'ai plus de mal avec les 250kLOC de scripts shell.
 
Après ça reste très théorique .

 
Perso, ça me fait quand même un peu halluciner 200k lignes de code procédural en PHP. Sans parler de forcément installer un framework complet, on peut installer des librairies qui vont quand même considérablement simplifier le travail et la lisibilité de l'ensemble. Pour par exemple envoyer des emails en PHP avec DKIM et S/MIME signing support et tout le toutim (LOGIN, PLAIN, CRAM-MD5, XOAUTH2 mechanisms over SMTPS and SMTP+STARTTLS transports etc...), je trouve complètement aberrant de ne pas utiliser une lib come PHPMailer qui est supportée par toute une communauté par rapport à réinventer la roue ou maintenir sa propre librairie écrite en code procédural.
 
D'ailleurs nous ici, pour certains projets très spécifiques, on utilise un mix de librairies de Symfony et d'autres librairies + les nôtres quand c'est nécessaire. Mais TOUT écrire, je comprends absolument pas le projet.  (On fait de plus en plus de python ceci dit...)

En fait, c'est pas mal de fichiers, chacun représentant une partie d'un module. Bien que jeune développeur à l'époque, j'avais quand même séparé les accès à la BD, la partie IHM et les fichiers affichant l'IHM ou traitant les formulaires. Bref, un truc qui ressemble un peu à du MVC.
Il y a de grosses similarités entre les fichiers (nommage des variables et des fonctions, ce qu'elles font...), du coup, quand tu as compris qq fichiers d'un module, tu as compris globalement la logique des autres. C'est donc assez facile de savoir quel fichier modifier.
 
Après, cette similarité fait que j'aurais pu optimiser certaines parties de mon code (donc réduire sa taille), ça fait partie des choses que si c'était à refaire, j'aurais fait différemment.
Par ailleurs, j'ai mis pas mal de documentation (spéc détaillée, manuel de conf, manuel utilisateur). Donc, côté traçabilité, c'est pas trop mal (en tout cas, j'ai vu largement pire sur pas mal d'autres projets   )

J'utilise bien PHPMailer De même, j'utilise FPDF. J'ai jamais dit que je n'utilisais aucune lib. J'essaye juste d'en utiliser le moins possible et quand la lib est conséquente et que j'en utilise une toute petite partie, je vais plutôt recoder cette petite partie. Je suis pas maso non plus

 
Bah c'est pas du procédural donc.    

Ton code peut être en procédural et appeler des libs qui sont en objet

Je parlais que de ce que j'ai codé moi. Je suis pas responsable si d'autres font de l'objet

 
   
 
Ceci étant dit, tu instancies bien des classes et tu appelles des méthodes quand tu utilises les librairies. Donc oui, ça reste procédural dans le sens que l'appel aux méthodes se fait dans un flux procédural. Mais c'est quand même pas pareil que de dire : kikoolol, je fais tout en procédural.
 
 

 
Bah stadire que dans tes messages précédents c'est pas ce qui transparaissait.  
 
Fondamentalement, je comprends ce que tu veux dire, mais les classes et la prog objet ont été inventés pour de bonnes raisons. Tu dis que ton truc est cool parce que tu changes juste quelques lignes de code pour passer à PHP8, mais moi, ce que je ressens en te lisant, c'est surtout que tu as une grosse dette technique et que tu as plus vraiment le choix à moins de tout ré-écrire. C'est pas forcément une critique. Comme d'autres l'ont dit, tu peux avoir du procédural de bonne qualité et de l'objet merdique... Mais bon...

Ça va tu galères pas trop entre les conflits de noms de fonctions, variables ? (à moins que tu sois old school comme Zend, type maClass_Dossier1_Dossier2_Module_Controller_Expand_Blabla_Override)..

T'arrives à gérer des fonctions sans what mille paramètres, la transmission de variables, l'instance DB ?

Mon forum que j'avais pondu en 2001 (www.trancegoa.org) était en procédural.
J'ai complètement rewrité le truc en 2017 en créant moi-même un framework MVC dans le but d'apprendre et de structurer mon code.
Bah, ça m'a beaucoup aidé, car je suis toujours allergique à Synfony et Zend aujourd'hui....  par contre je pourrais plus revenir sur du procédural (hors one page rapide), tellement l'objet est pratique à gérer.
J'essaie également de dépendre du moins de libs possibles.

Parce que Ajax est un montage batard fait en 2006 (souvenez-vous d'IE ou de mozilla qui ne faisaient pas comme les autres), et surtout entre les libs qui sont synchrones, pas synchrones, les résultats HTTP qui te font aller dans un mauvais callback, maintenant avec FetchAPI c'est bien plus clean, standard (implémenté de la même façon dans les navigateurs), et avec les Promises intégrées et mieux gérées, on comprends mieux et on peut faire plus de choses concrètes et non hasardeuses.

C'est IE6, qui passait par un activex batard. IE6 est mort depuis presque 20 ans.

fetch est clairement plus propre et moderne (et permet d'envoyer des ReadableStream), mais XMLHttpRequest est tout aussi standard, portable, et fiable.
 
Et tu peux pas avoir des appels réseaux programmatiques synchrones dans les navigateurs.

https://developer.mozilla.org/en-US [...] open#async
 
A une époque cet argument a fait des ravages sur l'UX

Non, du tout Règles de nommage pour les variables et fonctions. J'évite autant que possible les variables globales (ce sont surtout les variables de conf et de traduc de langues). Pour les paramètres, si une fonction a un nb variable, j'utilise un paramètre de type tableau associatif.
 
J'ai aussi fait une appli en MVC et objet. Très formateur effectivement. Y'a juste un truc qui me posait souci : c'est que j'étais obligé de charger tout un enregistrement pour initialisé un objet (i.e. charger tous les champs d'une table voir ceux d'autres tables liées) alors qu'en procédural, je pouvais facilement charger juste les 2-3 champs dont j'avais besoin.

C'est le souci avec l'écrit : pour pas faire des messages type pavé, j'ai tendance à simplifier. Si 90% du code d'une appli est procédural et 10% est de la POO, si on doit faire une simplification, on peut dire que toute l'appli est "globalement" du procédural.
 
Si qq'un a une solution qui permet de maintenir sur plus de 20 ans une appli de manière acceptable avec un seul dév avec une charge et coût minimal (car ce n'est pas mon occupation principale, les outils que je développent sont pour des experts ou pour moi-même pour faire mon travail métier quotidien), je suis preneur Il y a 20 ans, je suis parti sur cette idée. Jusqu'à présent, ça a donné de plutôt bons résultats en terme de temps et cout de maintenance et fonctions mises à disposition des utilisateurs. Et il faut se rappeler qu'il y a 20 ans, certains outils/frameworks n'existaient pas. Il y a donc des choses aujourd'hui qu'on fait naturellement qu'il était difficile de faire en 2003. La jungle des navigateurs web, c'était marrant à gérer (le JS qui était différent suivant les navigateurs, la balise <layer> pour Netscape et pas <div>, le CSS qui était un vrai bazar, obligé de faire des hack, parfois   )

 
Bah c'est totalement possible en faisant les choses progressivement et en étant régulier.  
 
Chez nous, on update régulièrement les libs qu'ont utilise ainsi que notre code. On ne refait pas une version entièrement nouvelle. Quand une lib n'est plus correctement supportée par exemple, on la remplace. La clé, c'est la régularité. C'est sûr que si tu laisses le truc dans un coin et que tu te réveilles des années après, c'est pas facile... (je ne parle pas de toi, je parle en général).
 
Pour ce qui est d'utiliser un framework complet type symfony par exemple, oui, les changement de version du framework peuvent être périlleuses. C'est pour cela qu'il faut les utiliser à bon escient.

Pour les libs, on a régulièrement des demandes de la PSSI pour mettre à jour celles trop anciennes. Donc pour les trucs sensibles, j'ai pas trop de décalage en général.
Et quand ça marche plus, je suis bien obligé de trouver une solution (dernièrement, c'est l'IGN qui a changé pour la 3ème fois en qq années son API ).

Pour symfony spécifiquement c'est très stable depuis quelques années à ce niveau, ça fait longtemps que j'ai pas eu une montée de version qui pose problème. Tu fais le tour des dépréciations avant de monter de version et ça roule.

Putain, mais qui fait ça ?! Mais faut tout brûler là...
   

Y a un certain cote.... artistique a la chose

Bon courage si tu dois reprendre ce code  

'Tain la req SQL en option c'est épique  . S'ils font un pentest sur le projet après ta presta et que tu ne refais pas tout
 
Bon courage en tout cas, j'espère pour toi que tu les fais bien raquer

Mon dieu.
Si tu met ça dans un gpt, tu vas débloquer le mode insultes.

Purée, j'avais pas vu le coup de la requête SQL dans une liste déroulante  

 
   
 
J'ai tellement de questions
T'es censé maintenir ca ? Faire une refonte totale ? T'as pensé à refuser ?

Je n'ose imaginer, le nombre de pages qu'il faudrait se taper, rien que pour expliquer ce qui ne va pas.

Attends, si ça se trouve c'est pas la valeur dans l'option qui est directement exécutée  

 
Ils voulaient, mais j'ai répondu que je reprends pas "ça", on repart à 0

 
Oui, un nombre à 5 chiffres mini
 

 
Nan, je veux pas maintenir ça, c'est vraiment à chier, faut tout brûler
Les injections SQL à la pelle, les contenus en dur, bref, ya rien à reprendre.
 
La refonte est prévue, mais je vais d'abord les faire raquer pour modéliser leurs données (là c'est tout à plat), puis mettre ça dans un petit framework OO
 
Ils y connaissent rien, et le webmaster actuel n'y voit rien de mal

 
Le bon coté de ce genre de trucs, c'est que ça nous évite de trop tomber dans le syndrome de l'imposteur

Effectivement, du PHP, qui fait ça ?

C'est... Ingénieux
Ça économise des cases derrière, il n'y a pas de petites économies mon Janco.

Il va te falloir un doliprane

Ca va être délocalisé. Il faut qu'il se dépêche, il risque de plus en trouver  

 
Ah ça… c’est sûr, oui.  

 
r'fo C'était la blague