Suggerimenti per pianificare una riscrittura di un grande progetto PHP?

13

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, li avrei caricati in Trac come biglietti e li avremmo aggiunti in seguito, senza preoccuparmi del design della struttura stessa. Nel corso del tempo questo ha causato alcuni problemi e penso che una riscrittura sarebbe stata utile, tuttavia non sono sicuro da dove iniziare con la pianificazione di esso - So che non voglio usare Trac, e so che ho bisogno di più di una semplice biglietti e pietre miliari - ma che altro avrei bisogno?

Voglio davvero pianificare accuratamente questa riscrittura, voglio dettagliare ogni funzionalità che desidero, 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 schema che dovrei seguire? Avrò bisogno anche di bug tracking, ticket, milestones, ecc., Ma al di là di Trac non so neanche cosa sia buono. Sono sicuro che ce ne sarà di più di cui ho bisogno ma non ho idea di cosa, quindi qualsiasi aiuto sarebbe apprezzato.

    
posta Jon 15.09.2011 - 15:49
fonte

6 risposte

7

Vedi sotto alcune cose che faccio quando sviluppi un grande progetto:

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

2 - Io sono un negozio di sviluppo personale, quindi di solito mi muovo da una funzione alla successiva. Il mio piano è creato in modo tale che tutte le funzionalità siano sequenziali. Non investo troppo tempo a stimare quanto tempo avrò bisogno per ogni funzionalità. Di solito considero che ognuno mi vorrà un giorno per svilupparsi. Se ne occorrono di più, semplicemente aggiorno il piano e tutte le attività future si muovono di conseguenza.

3 - Io uso git estesamente. Ogni caratteristica è un ramo. Una volta completata ciascuna funzionalità, 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 correggerlo e unirlo nuovamente una volta risolto. Mi assicuro di aggiornare sia il ramo di sviluppo che il mio attuale ramo di funzionalità su cui sto lavorando. Tra l'altro il bug diventa un'altra attività nel mio piano OpenProj. Qualcosa come "bug-indirizzo errato". E quando lo inserisco, tutte le altre funzioni vengono spostate nella timeline.

5 - Mentre sto sviluppando, se penso a una nuova funzionalità, la includo semplicemente nel piano in cui penso che si adatta meglio e aggiustare di nuovo la linea temporale.

Spero che questo aiuti. Sembra che tu abbia un progetto entusiasmante davanti a te. Buona fortuna!

    
risposta data 15.09.2011 - 16:18
fonte
10

Se stai cercando una riscrittura completa, perché non considerare anche se dovresti usare il php? Un cambiamento / aggiornamento della tecnologia potrebbe essere il catalizzatore che vuoi migliorare la tua progettazione / scalabilità / manutenibilità ecc ...

    
risposta data 15.09.2011 - 16:23
fonte
10

Suggerirei di rifattorizzare pesantemente invece

Il problema che prevedi qui:

I really want to thoroughly plan this rewrite out, I want to detail every feature I want, where it will go, and how it will connect to every other part - but I have no experience with this level of planning. Any advice? Any programs that will help? I'm getting tired of Trac, I've never really liked it.

è davvero difficile. È fondamentalmente il modello Waterfall con tutta la sua bruttezza. Ecco alcune prove aneddotiche per i problemi con l'approccio della "grande riscrittura", che arriva alla conclusione: probabilmente non anticipare correttamente i problemi e finire con un altro pasticcio che si desidera 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 ticket e puoi continuare a utilizzare il progetto. Il trucco qui è identificare i cambiamenti più piccoli che portano a un design complessivo migliore.

Ad esempio: hai detto, non hai MVC, ma vuoi farlo. Come primo passo, potresti prendere un singolo file PHP e, assumendo il solito mixup, ordinarlo, in modo che nella parte superiore tu abbia tutti gli accessi db, i calcoli, ecc. In basso hai il "template" ( primi biglietti, per ogni file). Come secondo passo, potresti incapsulare tutte queste parti di modelli in funzioni, che ricevono i loro parametri passati. (molti più biglietti). Fatto? Complimenti, hai terminato la tua V in MVC.

    
risposta data 15.09.2011 - 16:39
fonte
3

Considera l'utilizzo di un framework esistente. CakePHP, Zend Framework, CodeIgniter e Symfony sono quelli noti per PHP. Se soddisfano le esigenze di centinaia o migliaia di utenti, sono sicuro che possano 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.

Ovviamente, a meno che tu non voglia sperimentare creare quadri - che, potrei aggiungere, ha molto meno valore nel mercato (piuttosto che saper usare bene i framework esistenti e supportati).

    
risposta data 15.09.2011 - 17:35
fonte
1

Quello che mi piace usare è Redmine come tracker di pianificazione. IT gestisce ciascuno di questi articoli molto bene, oltre ad essere molto più user friendly (a mio avviso) rispetto a trac.

Per quanto riguarda la tua riscrittura, è importante capire che non anticiperai mai tutte le funzionalità / nuove estensioni che possono emergere, quindi cerca di scrivere la tua domanda nel modo più flessibile possibile. Utilizzando molti dei framework MVC che PHP ha può aiutare a sfruttare questo; tuttavia alcuni di questi framework ti pidginano anche se la tua architettura DB non è flessibile sin dall'inizio (Cake). Mi concentrerei davvero sul rendere le cose il più astratte possibile, e ogni volta che vedi qualcosa di codificato ti chiedi a cosa serve e perché non può essere memorizzato in un DB.

Really DB design aiuta a rispondere a tante domande e problemi, ed è qui che vedo l'importanza principale di come l'applicazione interagisce; quindi consiglio di spendere una buona parte del tempo analizzando il modo in cui i dati sono archiviati e il modo in cui è strutturato il DB.

    
risposta data 15.09.2011 - 15:54
fonte
1

Come software per il monitoraggio dei problemi, JIRA è ottimo, ma è molto costoso. Un altro ottimo strumento che sto utilizzando è Eventum. È gratuito.

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 applicazione, per avere un sentimento generale su ciò che vuoi e il più completo possibile.

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

Sapendo che avrai una buona comprensione della complessità dell'applicazione e delle linee di codice necessarie, puoi fare una stima e creare un programma. È importante avere un programma e una scadenza, altrimenti potresti finire senza finirlo.

Spero che aiuti

    
risposta data 15.09.2011 - 16:08
fonte

Leggi altre domande sui tag