Programmazione di PHP senza MVC, classi o framework: riscrivi o continua sulle nuove funzionalità?

L'apprendimento dell'OOP vale sicuramente la pena. Gli sviluppatori affezionati appassionati sono sempre disposti ad imparare ad espandere le loro conoscenze, specialmente quando è possibile risparmiare tempo a lungo termine. Sarei d'accordo di più con il secondo gruppo di persone:

Others say it's incredibly stupid, you're not scaleable, you're never get serious funding, you're the only one who ever be able to work on the project, you should stop and start learning it now, etc.

Questo è un po 'duro, ma la realtà è che più sai, più scala. Il finanziamento serio è spesso circondato da hype e il codice procedurale purtroppo non è abbastanza interessante. OOP e framework sono.

Am I doomed? I feel lost. My personal opinion on this is, that even though it is a huge system already, it is still a MVP and I guess at some point in the future we would rewrite the code anyways [...]

Le basi di codice procedurali di grandi dimensioni non sono rare, vedi WordPress. OOP aiuta davvero ad astrarre e organizzare il codice senza fare affidamento su convenzioni procedurali (sebbene i framework MVC abbiano un insieme di convenzioni completamente diverso). WordPress ha avviato un processo di migrazione, che è ancora in corso oggi. Con progetti così grandi tutto quello che puoi fare è aggiornare il tuo sistema, passo dopo passo, testando che non si rompa nulla, e mantienilo di nuovo, per sempre, come se avessi introdotto nuove funzionalità che necessiterebbero di refactoring in seguito.

Ma no, non sei condannato, solo un po 'in ritardo per l'intero processo. Impara cosa puoi quando puoi; meno è meglio di niente. La curva di apprendimento nell'apprendimento di nuovi paradigmi di programmazione, o lingue, è spesso scoscesa all'inizio, ma dopo quel primo singhiozzo sarà una navigazione fluida, e inizierai ad apprezzare davvero la differenza che può apportare sul tuo codice e la differenza lo farà quando altri leggeranno il tuo codice.

Modifica: Giusto per chiarire, non sto suggerendo che il sistema attuale debba essere OOP, o che deve essere costruito da zero. A un certo punto, qualsiasi sistema verrà rielaborato, e potrebbe essere necessario rompere la compatibilità con il sistema precedente, e va bene se il progetto lo richiede; puoi avere anche un ciclo di deprecazione. Quello che sto suggerendo è di introdurre lentamente OOP come refactoring del codice corrente, namespace, ecc.

Probabilmente è un po 'troppo tardi per passare all'ingrosso a un framework MVC. Soprattutto se stai ancora cercando di ottenere il progetto online.

Quello che ti consiglierei di fare è concentrarsi sull'apprendimento di OOP e quindi iniziare a migrare le funzionalità esistenti in una struttura di classe. Quindi, se decidi in fondo alla strada di migrare a un framework di terze parti, dovresti essere in grado di riutilizzare gran parte del codice.

(Spostato da Stack Overflow che segue domanda chiusa ) .

Penso che dipenda. Se il codice è già modulare e markup / logic è ben separato, potrebbe essere meglio non effettuare il porting su un sistema completamente diverso. Devi considerare l'impatto sull'attività esistente e se valga la pena di prendere gli sviluppatori da nuovi progetti di feature nel tuo caso.

Un modo migliore per farlo potrebbe essere trovare una libreria bolt-on che separa la logica dal codice e usarla inizialmente solo per il tuo nuovo codice. Poi, quando trovi il tempo, inizia a portarti i tuoi vecchi schermi, e ricevi ognuno vivo mentre lo finisci. Il risultato è che si migliora in modo iterativo, piuttosto che provare a farlo in un "big bang", e quindi è meno rischioso.

Lavoro su un sistema PHP di grandi dimensioni in cui è stato abbastanza difficile fare un biglietto da visita per passare a qualsiasi sistema di MVC decente. Ci piacerebbe, ma sarebbero 6-12 mesi di lavoro di sviluppo, e sebbene io tendo a vedere personalmente il rapporto costi / benefici in modo favorevole, il cliente non lo fa, e naturalmente sono i clienti / dirigenti a prendere queste decisioni!

La soluzione nel mio caso è stata quella di scrivere un sistema di controller semplice basato su oggetti, che tendiamo ad utilizzare per lo sviluppo futuro. Non è bello come Symfony2 o Laravel, ma è un passo significativo verso la modularità e la manutenibilità, ed è abbastanza buono.

Ciò detto, se non utilizzi affatto gli oggetti, direi che era piuttosto insolito. Sono un meccanismo molto naturale e utile per organizzare la tua applicazione e suggeriscono che questo dovrebbe essere il tuo primo punto di riferimento quando decidi come migliorare il tuo codebase.

Questo progetto in particolare potrebbe essere un po 'troppo grande per essere completamente riscritto, ma consideralo una lezione.

I framework MVC hanno molti scopi:

• Gestiscono molto il boilerplate (routing, template ecc.)
• Dissociano i vari passaggi tra la richiesta e la risposta, consentendo di iniettare facilmente tutti i tipi di funzionalità.
• Separano preoccupazioni diverse: le viste sono separate dal modello e dalla logica di business, quindi puoi ridisegnare completamente il sito senza competenze di codifica.

Questo può essere ottenuto senza un framework, ma non ha senso farlo. Di solito ti fanno risparmiare un sacco di tempo ed energia, e dovresti assolutamente considerarli per il tuo prossimo progetto.

Se il tuo progetto attuale è mantenibile, non dovresti sprecare così tanto risorse da riscriverlo e invece considerare lentamente la migrazione delle cose mentre le tocchi. Vale la pena investire? Solo tu lo sai.

Riscrivere un sistema di grandi dimensioni come il tuo solo per organizzare il codice nelle classi all'inizio non sembra poi così male, ma a meno che tu non sia ricompensato per i tuoi sforzi avendo quindi un sistema che ha meno bug, è più facile per estendere, più ottimale e così via, direi che il tuo tempo è meglio speso magari pensando di scrivere estensioni alla tua applicazione usando le classi al massimo.

È vero che molti framework e applicazioni di grandi dimensioni favoriscono l'organizzazione del codice OOP, ma certamente non è un requisito. Avendo imparato ad amare i linguaggi di programmazione funzionale, specialmente ocaml, personalmente ritengo che le classi siano inferiori alle funzioni, e ora che php offre un uso migliore delle funzioni e delle chiusure, non c'è davvero nessuna ragione schiacciante per usare le classi. Questo potrebbe essere una bestemmia per la maggior parte, ma credo che sia così.

Le classi hanno i loro usi ma non sono una necessità. Esaminiamo alcuni casi d'uso in cui l'uso tradizionale delle classi e dei loro equivalenti, vale a dire i metodi e le istanze statici.

1. Metodi statici.

   Utilizzando gli spazi dei nomi, è più che possibile avere la stessa funzionalità di un metodo di classe statico, e dato che è possibile avere diversi metodi di namespace raggruppati su file diversi, probabilmente molto più flessibile ed estensibile.

2. Stato istanza.

   Un'istanza di una classe contiene il proprio stato interno. Questo è sempre stato pubblicizzato come uno dei vantaggi dell'utilizzo di OOP. È ugualmente fattibile utilizzare le chiusure per fare lo stesso con lo stesso criterio ed è stato usato con successo in molte altre lingue con grande successo.

Quindi, il mio consiglio è di mantenere il passo. Potresti essere grato nel tempo mentre le persone iniziano a migrare verso il tuo stile di codifica.