Migration d'un framework PHP à un autre


10

Je travaille avec une entreprise Web qui approche d'un point où elle devra probablement repenser le produit en tant que V2 - en raison de la croissance de certaines de ses fondations et principes V1 qui ont été intégrés dans pratiquement tout, du modèle de données à la Les interfaces des utilisateurs. Pour diverses raisons, cette évolution pourrait impliquer une migration de CakePHP (avec lequel la V1 a été construite) vers Symfony ou Zend.

Je voudrais demander des opinions expérimentées sur la façon dont les gens auraient pu gérer une transition comme celle-ci pour un site Web qui a un trafic important et génère des revenus. Je ne veux pas ouvrir une discussion sur les avantages et les inconvénients des différents frameworks PHP, ni pourquoi cette migration pourrait être nécessaire. Au contraire, je serais très intéressé de savoir s'il existe des alternatives pratiques pour essentiellement construire un V2 à partir de zéro à côté du V1 pendant quelques mois - et verrouiller un temps de codage précieux pour la durée de cette période intense. Un exemple d'une telle alternative pourrait être la migration d'une application en plusieurs parties sur une période plus longue.

Je serais reconnaissant pour toute opinion de personnes qui auraient pu gérer ou être impliquées dans de telles transitions.

Merci d'avance.

Réponses:


2

S'il s'agit d'une application commerciale qui est l'affaire de votre entreprise, vous feriez mieux de vous passer complètement d'un framework tiers. Ensuite, lorsque le temps pour la v3 arrivera, vous ne serez plus confronté à ce même problème. Et vous ne serez jamais dans une situation où vous devrez continuer à ajuster votre code en réponse aux mises à jour du cadre. Les cadres sont parfaits pour que les choses soient rapidement opérationnelles, mais si c'est quelque chose a) au cœur de votre entreprise et b) maintenu à long terme, la valeur du cadre diminue.


1
Merci - Perspective utile, bien que les frameworks facilitent la vie en ce qui concerne tant de choses qu'il est difficile d'envisager de ne pas les utiliser. Ils peuvent également être personnalisés et n'ont pas toujours besoin d'être mis à jour, sauf en cas de besoin réel (par exemple, des failles de sécurité, un manque de support pour X, etc.). Accepter cette réponse car il s'agit vraiment d'une «solution» plutôt que d'essayer de comprendre pourquoi le changement de structure pourrait être nécessaire.
Tom

1
Cette réponse n'est pas du tout une solution.
James

6

Apprenez très bien le nouveau cadre d'abord, et assurez-vous qu'il va répondre à vos besoins, et que vous comprenez vraiment les paradigmes du nouveau cadre. Vous allez devoir jeter beaucoup de code, et ça va. L'important est que vous utilisiez le nouveau cadre de la façon dont il était censé être utilisé, en tirant pleinement parti de ses fonctionnalités et en n'étant pas lié aux façons de penser de votre ancien cadre. N'essayez pas d'utiliser Zend "à la manière de CakePHP" *

Par exemple, lorsque je suis passé à l'utilisation du framework MVC à partir de précédents non-MVC, je n'ai pas vraiment compris comment les modèles, les vues et les contrôleurs étaient censés fonctionner, et j'ai écrit un code à l'aspect terrible parce que je ne comprenais pas le nouveau façon de faire les choses. Vous feriez mieux de vous en tenir à un ancien cadre inférieur que d'avoir une application mal écrite sur un meilleur cadre.

* Je ne connais pas non plus, donc je ne sais pas comment ils sont similaires / comparables.


+1 pourDon't try to use Zend "the CakePHP way
Tim Post

vous savez quand les gens disent '+1', ils donnent généralement le +1 en votant pour la réponse;)
GSto

Désolé, hoquet Internet. :) TCP sur pigeon voyageur ici.
Tim Post

Merci pour la réponse utile. J'ai essayé Zend et CakePHP, et bien que je sois d'accord avec votre commentaire, je ne peux pas par principe "l'accepter" quand ce n'est pas une expérience pratique de parler.
Tom

5

La première chose à considérer est que la réécriture d'un produit à partir de zéro est quelque chose que vous ne devriez jamais faire . Cela est particulièrement vrai lorsque la version actuelle vous rapporte déjà de l'argent. En gros, vous allez passer 6 mois, juste pour revenir là où vous étiez il y a 6 mois. Seulement maintenant, vous avez plus de bogues (ou du moins, différents bogues) , des bogues réintroduits qui avaient déjà été corrigés dans l'ancien code, et vous avez six mois de retard par rapport à ce que vous auriez pu être, si vous aviez été l'ajout de fonctionnalités à l'ancienne base de code.

CakePHP, Zend et Symphony sont essentiellement les mêmes (c'est-à-dire que ce sont tous des frameworks de style MVC au-dessus de PHP), donc je ne sais pas quel avantage vous auriez à passer de l'un à l'autre. Il y a certainement des différences dans l'ensemble des fonctionnalités, mais valent-elles vraiment la peine de vous remettre en arrière tout ce temps? Pour le temps que vous passeriez à réécrire à partir de zéro dans Zend ou autre, pourriez-vous passer le même temps à ajouter les fonctionnalités requises à Cake?

À mon avis, vous feriez mieux de refactoriser lentement votre code existant au fil du temps, plutôt que de recommencer complètement à zéro avec un nouveau cadre.

Bien sûr, cela est juste mon avis. Je sais qu'il est tentant de laisser tomber le code existant (moche, ancien) et de recommencer à zéro, mais pour les produits établis qui fonctionnent déjà, il y a généralement peu à gagner et beaucoup à perdre.


Exactement ce à quoi je pensais. Inutile de réécrire ici, car il ne semble pas y avoir de preuves solides que ce sera une décision économique.
EricBoersma
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.