Ridurre la complessità del nostro framework personalizzato

1

Nella nostra azienda, abbiamo un'applicazione software personalizzata che utilizza il nostro framework. Il framework è stato costruito intorno al 2002 o 2003, molto tempo prima che mi presentassi all'azienda. La maggior parte delle funzioni nel framework sono solide, quindi le usiamo ancora perché non abbiamo mai avuto problemi con loro, sto parlando delle funzioni e delle funzioni del database per ottenere parametri get / post e dati di escape, ecc.

Ero solo io a lavorare sui progetti, quindi non ho mai avuto problemi con il code-base, tuttavia ora abbiamo fino a 6 sviluppatori che hanno iniziato a lavorare sul framework di recente, quindi le cose sono diventate più complicate. Nel nostro attuale framework è impostato come:

/cms/
/cms/modules/
/cms/modules/filemanager/
/cms/modules/filemanager/index.php
/cms/modules/pages/
/cms/modules/pages/index.php
/cms/...

Ora all'interno di ciascun file indice di ciascun modulo abbiamo il seguente:

require_once '../../config.php';
require_once '../../database_functions.php';
require_once '../../url_functions.php';

Sto trovando sempre più difficile mantenere i cambiamenti, ora e ora, che alcuni moduli interagiscono con altri moduli e sta diventando pazzesco per mantenerlo tra tutti i membri del nostro team di sviluppo.

In passato era molto semplice, ma ora il nostro modulo di pagina in realtà integra altri moduli nel modulo principale, in segnaposti fondamentalmente in modo da poter inserire qualsiasi contenuto da singoli moduli nella pagina.

Il problema arriva quando apportiamo una modifica al nostro modulo galleria e ora ho bisogno di apportare modifiche al front-end (output html), al modulo stesso della galleria, al database e quindi eseguire il debug di tutti gli errori che si verificano in altri moduli che stanno attualmente utilizzando i dati dal modulo galleria. Fondamentalmente diventa una reazione a catena di cambiamenti.

Qualcuno ha qualche suggerimento su come semplificare le cose o un modo migliore per controllare la manutenzione della nostra applicazione? Stiamo ancora utilizzando un modo molto strutturato di codifica utilizzando script e funzioni dirette piuttosto che OOP, poiché sono abituato a codificare in C e non mi piace complicare più del necessario.

A parte questi problemi, al momento non utilizziamo nulla come le versioni del nostro software, abbiamo distribuito un ottimo lavoro e i clienti adorano il software che distribuiamo, semplicemente non abbiamo versioni su di loro e non ci sono build o qualsiasi cosa, che è probabilmente un grosso errore in sé.

Qualsiasi idea o suggerimento o anche un link a qualche parte che possa aiutarci a capire come strutturare meglio il nostro processo di sviluppo (se questo è un problema) sarebbe molto apprezzato.

    
posta jnker 16.05.2012 - 18:55
fonte

2 risposte

0

Risponderò in un modo generale, non affrontando problemi specifici di PHP. La radice del problema è che il tuo team è cresciuto da 1 sviluppatore a 6 sviluppatori. Man mano che ogni nuovo sviluppatore si avvicina al codice base, vedrà modi per innovare con il codice e utilizzare la struttura in modi che non si aspettavano. Inoltre, senza un sistema di controllo delle versioni e delle versioni, più sviluppatori che commettono modifiche simultanee possono portare al caos. Ecco i passaggi che consiglio:

  1. Approccio per risolvere questo problema come una squadra. Tutti dovrebbero essere consapevoli di il problema, e dovrebbe partecipare all'integrazione delle migliori pratiche nel processo di sviluppo. Il team, nel suo insieme, dovrebbe essere d'accordo su quale sarà la versione in corso, il processo di compilazione e test.

  2. Accetta la procedura di rilascio, in modo che le persone non stiano procedendo i cambiamenti dell'altro. Ciò significa definire una versione, il tagging della versione codice e ramificazione se necessario.

  3. Inizia a creare test di unità / regressione automatizzati eseguiti dagli sviluppatori prima di ogni check in. Ciò consente ad ogni sviluppatore di registrare le sue ipotesi sul codice e avviserà gli altri sviluppatori se interrompono tali ipotesi. Esistono molti buoni framework per i test web. Scegline uno e inizia a usarlo.

Suppongo che almeno alcuni di questi altri 5 sviluppatori abbiano esperienza di lavoro in un ambiente di squadra e abbiano già alcuni suggerimenti su come andare avanti.

    
risposta data 16.05.2012 - 21:37
fonte
0

Prima di tutto, affermi che le tue "core" legacy librerie sono solide. La mia posizione sarebbe quella di isolarli dal team di sviluppo. Abbraccia solo un po 'di OOP avvolgendoli in wrapper sviluppati appositamente. Quindi se hai bisogno del codice db per filemanager, scrivi un intermediario dbfilemanager in modo che tu possa cambiarlo e non rovinare le "pagine". allo stesso modo aggiungi un dbpages per lo stesso motivo.

La "buona pratica" è quella di non sporcare il codice robusto e invecchiato e di estenderlo semplicemente per scopi specifici.

Personalmente non mi interessa se il codice è duplicato nell'universo, soprattutto se consente la leggibilità e la coesione nella progettazione di un sistema. In altre parole, anche se si ha una funzione prevalentemente simile in DBFileManager e DBPages, almeno i percorsi del codice non hanno dipendenze incrociate. Sembra che il codice stia diventando rapidamente spaghetti, dato che le funzionalità specifiche del sottosistema vengono inserite nelle librerie principali. Sarai più felice prima smetterai di farlo.

Per quanto riguarda le versioni, sono solo etichette per aiutarti a identificare il colpevole più probabile quando qualcosa non funziona. Le versioni possono anche far pensare alle persone che hanno bisogno di acquistare le ultime perché il loro numero di versione è così vecchio. Entrambe le ragioni sono molto buone e dovrebbero essere utilizzate per convincere la tua azienda a iniziare a usarle.

    
risposta data 16.05.2012 - 21:35
fonte

Leggi altre domande sui tag