Suggerimenti per la pianificazione di una riscrittura di un grande progetto PHP?

Ho deciso di riscrivere completamente un framework PHP (Using MVC) su cui ho lavorato, acceso e spento, per anni. Il mio problema fino ad ora era che avrei appena avuto idee, le avrei buttate in Trac come biglietti e le avrei aggiunte in seguito - senza preoccuparmi del design del framework stesso. Nel tempo questo ha causato alcuni problemi e penso che una riscrittura sarebbe utile, tuttavia non sono sicuro da dove cominciare con la pianificazione di esso - so che non voglio usare Trac e so che ho bisogno di più di un semplice biglietti e pietre miliari - ma cos'altro avrei bisogno?

Voglio davvero pianificare a fondo questa riscrittura, voglio dettagliare ogni caratteristica che voglio, dove andrà e come si collegherà a ogni altra parte - ma non ho esperienza con questo livello di pianificazione. Qualche consiglio? Qualche programma che ti aiuterà? Mi sto stancando di Trac, non mi è mai piaciuto molto.

So che avrò bisogno di un documento di progettazione, ma c'è qualche layout che dovrei seguire? Avrò anche bisogno di tracciamento dei bug, biglietti, pietre miliari, ecc., Ma al di là di Trac non so nemmeno cosa vada bene. Sono sicuro che ci sarà bisogno di più, ma non ho idea di cosa, quindi qualsiasi aiuto sarebbe apprezzato.

Vedi di seguito alcune cose che faccio quando sviluppo un grande progetto:

1 - Uso uno strumento di pianificazione come OpenProj e aggiungo tutte le funzionalità che voglio includere come attività. Ad esempio, in questo momento sto lavorando a una funzione per consentire ai miei utenti di accedere automaticamente dopo essersi registrati sul mio sito. Ho un compito nel mio piano come "feature-autologin".

2 - Sono un negozio di sviluppo personale quindi di solito passo da una funzione all'altra. Il mio piano è stato creato in modo tale che tutte le funzionalità siano sequenziali. Non dedico troppo tempo a stimare quanto tempo avrò bisogno per ogni funzione. Di solito ritengo che ognuno mi impiegherà un giorno per svilupparmi. Se uno prende di più, aggiorno semplicemente il piano e tutte le attività future si spostano di conseguenza.

3 - Uso ampiamente git. Ogni funzione è un ramo. Una volta completata ogni funzione, la ricollego al ramo di sviluppo e creo un nuovo ramo per la funzione successiva.

4 - Se trovo un bug nel software, creo un piccolo ramo git per risolverlo e ricollegarlo una volta risolto. Mi assicuro di aggiornare sia il ramo di sviluppo che il mio ramo di funzionalità corrente su cui sto lavorando. A proposito, il bug diventa un'altra attività nel mio piano OpenProj. Qualcosa come "bug-wrong-address". E quando lo inserisco, tutte le altre funzionalità vengono spostate indietro nella sequenza temporale.

5 - Mentre sto sviluppando, se penso a una nuova funzionalità, la includo semplicemente nel piano in cui penso che si adatterà meglio e adeguerà nuovamente la sequenza temporale.

Spero che questo possa essere d'aiuto. Sembra che tu abbia un progetto eccitante davanti a te. In bocca al lupo!

Se stai per una riscrittura completa, perché non considerare anche se dovresti usare php? Un cambiamento / aggiornamento della tecnologia potrebbe essere il catalizzatore che desideri migliorare il tuo design / scalabilità / manutenibilità ecc ...

Suggerirei invece di refactoring pesantemente

Il problema che prevedi qui:

Voglio davvero pianificare a fondo questa riscrittura, voglio dettagliare ogni caratteristica che voglio, dove andrà e come si collegherà a ogni altra parte - ma non ho esperienza con questo livello di pianificazione. Qualche consiglio? Qualche programma che ti aiuterà? Mi sto stancando di Trac, non mi è mai piaciuto molto.

è davvero difficile. È fondamentalmente il modello Waterfall con tutta la sua bruttezza. Ecco alcune prove aneddotiche per i problemi con l'approccio del "grande riscrittura", che arriva alla conclusione: probabilmente non anticiperai correttamente i problemi e finirai con un altro casino che vuoi riscrivere da zero. Non perché sei cattivo, ma perché è impossibile ottenere qualcosa di grosso in un colpo solo.

Quando invece inizi a refactoring, puoi scrivere singoli biglietti e continuare a utilizzare il progetto. Il trucco qui è identificare piccoli cambiamenti che portano a un design complessivamente migliore.

Ad esempio: menzioni, non hai MVC, ma vuoi farlo. Come primo passo, potresti prendere un singolo file PHP e, supponendo il solito mixup, ordinarlo, in modo che nella parte superiore hai tutti i db-accesso, i calcoli, ecc. Nella parte inferiore hai il "templating" ( primi biglietti, per ogni file). Come secondo passo, potresti incapsulare tutte queste parti del modello in funzioni, che fanno passare i loro parametri. (molti più biglietti). Fatto? Complimenti, hai finito la tua V in MVC.

Prendi in considerazione l'utilizzo di un framework esistente. CakePHP, Zend Framework, CodeIgniter e Symfony sono i noti per PHP. Se soddisfano le esigenze di centinaia o migliaia di utenti, sono sicuro che possono soddisfare i tuoi.

Se sei disposto a imparare / usare qualcosa di diverso da PHP - Django (Python) e Rails (Ruby) sono praticamente i framework principali per le applicazioni web convenzionali.

Questo, ovviamente, a meno che tu non voglia esperienza nella creazione di framework - che, potrei aggiungere, ha molto meno valore nel mercato (piuttosto che sapere come usare bene i framework supportati esistenti).

Quello che mi piace usare è Redmine come tracker di pianificazione. L'IT gestisce ognuno di questi elementi molto bene, oltre ad essere molto più user friendly (secondo me) di trac.

Per quanto riguarda la tua riscrittura, è importante capire prima che non anticiperai mai tutte le funzionalità / nuove estensioni che possono venire, quindi per provare a scrivere la tua applicazione il più flessibile possibile. L'uso di molti dei framework MVC che PHP ha può aiutare a sfruttare questo; tuttavia alcuni di questi framework ti colpiranno anche se la tua architettura DB non è flessibile dall'inizio (Cake). Mi concentrerei davvero sul rendere le cose più astratte che puoi, e ogni volta che vedi qualcosa di hard coded chiediti a cosa serve e perché non può essere archiviato in un DB.

La progettazione di DB realmente aiuta a rispondere a così tante domande e problemi, ed è dove vedo l'importanza principale di come la tua applicazione interagisce; quindi consiglierei di dedicare buona parte del tempo ad analizzare come sono archiviati i dati e come è strutturato il tuo DB.

Come software di localizzazione dei problemi, JIRA è eccezionale, ma è molto costoso. Un altro buon strumento che sto usando è Eventum. È gratis.

Ma la parte più importante è avere una buona idea di ciò di cui hai bisogno. Per prima cosa devi raccogliere i requisiti per la tua domanda, avere un'idea generale di ciò che desideri e il più completo possibile.

In base a ciò creerai requisiti software, ovvero un approccio più tecnico in cui descriverai i moduli che faranno parte della tua applicazione, le loro funzioni e sotto-funzioni, oggetti, classi, le loro interfacce, praticamente tutto.

Sapendo che avrai una buona comprensione della complessità dell'applicazione e delle linee di codice necessarie, in modo da poter effettuare una stima e creare un programma. È importante avere un programma e una scadenza, altrimenti potresti non finire mai.

Spero che sia d'aiuto