Discussion :

[Théolude]

Bonjour à tou.te.s,

Je travaille depuis de très nombreuses années sur une très grosse application écrite en PHP avec un framework maison utilisant ModeliXe notamment et d'autres briques.
Aujourd'hui nous voulons le migrer sur un Framework reconnu pour en faciliter la maintenance et l'évolution .

L'architecture est du type MVC dans la philosophie mais les adressages des requêtes HTTP sont classiques, une URL, une fonctionnalité métier (exemple: listeCommandes.php)... et les "routes" n'existent réellement que dans la structure des menus gérés en BDD. Le lien entre l'ensemble des scripts qui gèrent une fonctionnalité est "implicite" dans la structure des noms des fichiers.
Il y a de très nombreux formulaires très orientés utilisateurs, mais complexes avec beaucoup de champs et d'affichages conditionnels, de l'Ajax, mais les enregistrements sont classiques la plupart du temps: un POST, un traitement et un contrôle des données, un enregistrement en SQL. le soin apporté aux formulaires doit être conservé pour conserver l'expérience utilisateur intacte.
Les vues sont gérées avec le moteur de template ModeliXe, ancien mais efficace, aucun code ni aucune logique métier n'est intégré dans les templates. Ceux-ci sont modulaires avec des notions de blocs auxquels l'application peut accéder pour en modifier le comportement (dupliquer, supprimer, modifier, etc.)
Il y a un gestionnaire de session maison avec une authentification LDAP, mais il mériterait d'être changé.
Le JS est géré à part, on utilise la très vieille mais très efficace librairie Prototype plus quelques autres indispensables dont sweetalert, etc. (j'en oublie je ne les ai plus en tête).
Au niveau SQL, il y a nécessairement de très grosses et très complexes requêtes sur une base de plus de 300 tables ... je ne me vois pas utiliser un ORM et ré-écrire toutes les requêtes...

Bref comment moderniser tout ça en restant efficace, sans trop perdre de temps, et en se rapprochant le plus possible de l'existant au niveau des interfaces?
Quel serait selon vous le framework PHP le plus adapté?

Merci de vos retours, conseils, remarques, etc.

Théo

[unanonyme]

Bonjour,

Avant de me lancer je prendrais le temps de bien étudier les problèmes de maintenance
et les difficultés rencontrées lors des évolutions.

Je réfléchirais à savoir comment j'aurais pu éviter ces problèmes,
dans le système existant, et dans le/les frameworks envisagés.
Cela doit permettre d'évaluer le cout d'une correction généralisé pour l'existant,
de ce que le/les frameworks envisagés apportent bien le gain escompté
lorsque viendra le moment de se lancer.

Peut être que l'existant peut être corrigé à moindre coût pour améliorer ces points.
Peut être qu'un changement technologique n'apportera rien pour améliorer ces points.

En tout cas t'auras forcément des surprises dans une telle transition,
il faut le prendre en compte dans la concrétisation du choix
et donc en limiter les effets en amont en ayant bien balisé le terrain.

En bref, "moderniser..... pour en faciliter la maintenance et l'évolution"
n'est pas suffisamment étayé selon moi.

Bonne journée

[Théolude]

Bonsoir,

Merci de la réponse et d'avoir bien perçu une de mes premières questions / hésitations... la question du framework se pose aussi dans la perspective d'ouvrir plus largement l'application à des développeurs extérieurs sans qu'ils aient le besoin préalable d'apprendre le framework particulier et personnel que nous utilisons... mais qui remplit très bien son rôle.

D'autres considerations liées à la sécurité sont également présentes, plus faciles à résoudre à travers l'usage d'un framework aguerri et très usité qui a bénéficié de l'expertise et de l'expérience de très nombreuses personnes.

C'est une vraie question existentielle pour moi ce choix, et je me sens très peu outillé pour y répondre convenablement... même si c'est moi le premier qui pose la question. Conserver ou migrer...

Théo

[unanonyme]

Bonjour,

je subodore que tu es la tête pensante de cette implémentation,
que cette situation ralentit le business qui voudrait augmenter
la main d'œuvre pour capter plus de marché.

Dans le cadre de cette démarche vous avez des difficultés
à vous staffez car les employés préfèrent passer
du temps à apprendre des frameworks reconnus
car c'est plus efficace pour la ré employabilité.

Tu rencontres peut être des difficultés à opérer
le passage de connaissance,
tout est peut être "tellement évident de ton point de vu".

Que ton projet fonctionne super bien, mais qu'il a
des lacunes, qui, le temps passant, deviennent
de plus en plus pointues et ardues à implémenter.

Que tu ressens de la pénibilité à ré inventer des roues
qui existent par ailleurs.

Qu'au delà des difficultés de développement,
c'est peut être aussi une manière de livrer les projets
qu'il faut réfléchir.

-----------------------------------

Que tu aies pu percevoir ton inexpérience quand à la manière
d'aborder tout cela est un bon signe.

-----------------------------------

Mon biais perso c'est de considérer que comme 99.99% des logiciels
celui ci finira dans la poubelle de l'histoire,
qu'à se titre là ce qui importe c'est qu'il m'en donne pour mes efforts.
Je suis donc partisan du moindre effort.
C'est facile de tout casser, c'est plus difficile de tout recoller,
tu t'en convaincras rapidement en tentant de refaire du blé avec de la farine.

-----------------------------------

Maintenant, dans la perspective d'une montée en puissance,
imposée, ou ardemment désirée, je procéderais de manière incrémentale
sur l'existant.
C'est à dire qu'au lieu de repartir de zéro, d'agrandir la distance entre l'existant
et le devenir, d'augmenter les risques d'échec, je procéderais par grosse touche
une mise à jour à la fois.
Et ainsi de suite.

Dans ce cadre là j'irais piocher parmi les composants existant d'autres projets.
Telle mise à jour pour intégrer tel routeur, telle mise à jour pour intégrer tel
framework de test, telle mise à jour pour intégrer tel composant de formulaire.

Cela nécessite de repasser plusieurs fois sur le code, c'est fastidieux,
ça demande de la rigueur et de la volonté, ça réduit les écarts à la divergence.

Si un problème se déclare ce sera localisé, mieux maitrisé, moins pléthorique.

Il faudra alors s'interroger sur la pertinence des composants à intégrer.
Est ce vraiment justifié de changer tout le système de routage des urls
pour pouvoir utiliser des middlewares ?
Si j'intègre tel framwork de test, qui écrira, pérennisera, maintiendra et fera évoluer
les suites de test ?
Est ce bien justifié d'intégrer tel composant de sécurité pour telle fonctionnalité
qui n'est que très peu redondée dans l'application ? Qui nécessite peu de maintenance.
Est ce que l'intégration de tel composant résout bien le problème préalablement identifié.

-----------------------------------

Quoi qu'il en soit la nature dantesque de ce changement doit
être considérée à sa juste valeur.

Trouves d'autres avis, je ne peux que te souhaiter
d'obtenir l'avis d'autres personnes en désaccord avec moi.

Étudie bien les difficultés actuellement rencontrées,
et les solutions à moindre coût que tu peux déjà apporter.

Il n'est jamais facile de se staffer, mais c'est peut être par là qu'il faut commencer
pour te libérer du temps.
Tu aurais peut être besoin de faire des formations accélérer, de collecter des retours d'expériences,
sur les frameworks que tu envisages, le temps que tu as dépensé sur ce projet,
tu ne l'a pas dépensé à arpenter ces frameworks.
Je suis personnellement convaincu qu'on trouve de tout sur le marché,
que pour payer les factures, des bosseurs, ça existent,
faut juste pas leurs demander de prendre des rôles auxquels ils ne correspondent pas.

Je te souhaites bon courage, et de t'être donner les moyens de bien décider,
mon avis n'est qu'un avis et je n'ai pas la science infuse.

Bonne journée