Tutti hanno bisogno di una struttura per funzionare meglio?

Sono d'accordo con @Martin sul fatto che non hai necessariamente bisogno di framework per risolvere questi problemi. Sebbene per lo sviluppo di aree verdi, è in effetti consigliabile scegliere e utilizzare una struttura consolidata, in questo caso specifico mi sembra che la maggior parte dei tuoi problemi derivi dalla disordine generale e dall'incoerenza del sistema. Sebbene un framework comune e costantemente utilizzato possa effettivamente aiutare a consolidare il sistema e mantenerlo gestibile a lungo termine, la parte più importante e urgente è riorganizzare il sistema per renderlo coerente e pulito.

Questo può - e in effetti dovrebbe - essere fatto prima di migrare ad un framework, perché implica molte decisioni e preparativi che dovresti fare prima di migrare comunque ad un framework. Tuttavia, questo approccio è molto meno invadente, quindi meno rischioso della migrazione su larga scala. Complessivamente, ti dà il massimo ritorno sull'investimento (sforzo speso).

Altrimenti, migrando a un framework direttamente, rischi di espellere un enorme sforzo e avere ancora un sistema che potrebbe essere leggermente meno disordinato e incoerente - e in un modo diverso rispetto a prima -, ma ancora difficile da mantenere.

Quindi inizia impostando convenzioni comuni per il tuo team di progetto (" questo è dove inseriamo il file di output per il modulo X, e questo è il formato previsto") e assicurando che tutti aderiscano a loro, inizialmente per un nuovo sviluppo. Una volta che le convenzioni sono state discusse, scosse, provate, testate e maturate, si può gradualmente iniziare a rivedere, riscrivere e riconfigurare gli script esistenti per aderire anche a loro. Una volta che la maggior parte del sistema funziona secondo le convenzioni, puoi prendere in considerazione la possibilità di migrare a qualche framework.

Tutto sommato, nei casi più e in particolare per i tipi più comuni di applicazioni, è meglio usare i framework piuttosto che non usarli.

I framework (quelli giusti, comunque) offrono i seguenti vantaggi:

• Forniscono API ben progettate per attività comuni e implementazioni efficienti e ben collaudate che sono molto meglio di ciò che la maggior parte degli sviluppatori si inventerebbe, specialmente quando sono nuove in un campo.
• Impongono al tuo codice alcune strutture / schemi che hanno dimostrato di funzionare bene e facilitano la comprensione del codice, in particolare (ma non solo) per le persone che hanno utilizzato lo stesso framework.

Imparare a usare un framework può essere scoraggiante, e la maggior parte degli istinti di programmatori di cowboy degli sviluppatori urlano "Potrei farlo molto meglio". Di solito si sbagliano - stai vedendo il risultato.

Ma i framework non riescono magicamente a rendere il tuo codice gestibile - qualsiasi strumento può essere utilizzato in modo improprio al punto in cui fa più male che bene.

La risposta è No. Non hai bisogno di quadri per lavorare meglio. Alcune strutture incorporano schemi di progettazione che potrebbero essere applicati in modo utile a una particolare applicazione.

Quindi guarderei se un pattern di progettazione può essere applicato al tuo problema e poi valutare se un framework ti assisterà o se implementare il modello tu stesso sarebbe l'opzione migliore.

Non reinventare la ruota solo per il gusto di farlo, ma anche non applicare ciecamente strutture, hanno conseguenze e compromessi come qualsiasi altra cosa.

Sono d'accordo che il tuo primo dovere è quello di consolidare / pulire il tuo codice fino a utilizzare un singolo posto per file, file di configurazione comuni, meccanismi di stato consistenti.

Utilizzare un framework, senza farlo prima, non aiuterà. Quindi esegui la pulizia prima e poi rivaluta le tue esigenze.

La pulizia di PS è difficile e lenta. Ho passato 6-8 settimane a pulire un sistema che era stato appena completato perché gli sviluppatori precedenti non avevano seguito le regole di coerenza ecc.