Alcuni retroscena primoCompositore suggerito approccio per i pacchetti interni
La nostra azienda, una piccola startup con solo quattro sviluppatori, sta iniziando il refactoring dei nostri prodotti in moduli riutilizzabili per semplificare il processo di sviluppo, aumentare la produttività e, insieme A proposito, vorremmo introdurre dei test unitari dove si adatta.
Come al solito in una piccola startup, non possiamo permetterci di sprecare troppo tempo di sviluppo ma, come vediamo, questo è estremamente importante per il successo della nostra azienda a medio e lungo termine.
Attualmente, abbiamo due prodotti per l'utente finale. Entrambe sono applicazioni Laravel (PHP) basate sul nostro livello aziendale interno, composte principalmente da servizi Web, apis riposante e un enorme database.
Questo livello aziendale fornisce la maggior parte dei dati per questi prodotti, ma ognuno di essi ne fa un uso completamente diverso. Abbiamo in programma di costruire altri prodotti nel prossimo futuro oltre a mantenere e migliorare quei due che sono quasi finiti.
Perché ciò accada, intendiamo astratta logica comune di coloro (e futuro) prodotti in moduli riutilizzabili e disaccoppiati. La scelta più ovvia sembra essere il compositore, anche con la nostra poca conoscenza a riguardo.
Ora per la vera domanda
vorrei chiedere altri pareri su come sviluppare pacchetti interni su un test driven moda. Ogni modulo dovrebbe essere un pacchetto di compositore con i propri test di unità e richiedere le sue dipendenze, oppure dovremmo creare un singolo pacchetto con ogni modulo nominato nello spazio?
Per chiarire un po ', ci piacerebbe avere, ad esempio, un modulo CurlWrapper e che sarebbe richiesto sul nostro modulo InternalWebserviceAPI (e pochi altri).
Personalmente mi piace l'idea di avere pacchetti completamente separati per ogni modulo e di dichiarare dipendenze su composer.json, che implementerebbe mentalmente il disaccoppiamento e ci permetterebbe di pubblicare alcuni di questi pacchetti come opensource un giorno. Può anche semplificare le modifiche di rottura su quei moduli perché potremmo congelare la sua versione sui dipendenti che dovranno essere aggiornati.
Anche se, penso che questa separazione potrebbe aggiungere molta complessità e potrebbe essere più difficile da mantenere e testare, dal momento che ogni modulo dovrebbe essere un progetto a se stante e non abbiamo tutto quel potere umano da mantenere traccia di tanti piccoli progetti.
È davvero Composer la soluzione ideale per il nostro problema? In tal caso, quale consiglio: pacchetto singolo o più pacchetti?
Edit 1:
vorrei far notare che la maggior parte di questi moduli stanno per essere:
- librerie (vale a dire ottenere un ID da un URL di YouTube o la conversione risale al " x secondi fa ")
- wrapper (come un involucro CURL chainable)
- Facciate (dei nostri molteplici servizi web, quelli richiedono gli altri due generi)
Attualmente sto pensando a un modello simile da adottare per un progetto. Le domande che ho sono le stesse, quindi mi piacerebbe sapere come hai fatto a farlo. Soluzione ideale Vorrei che Wouter abbia menzionato qui di seguito, ma come sapete aggiunge uno strato di complessità quando si tratta del bit di integrazione. Ma è un'architettura sonora a lungo termine. Anche se il trade off sarebbe il momento degli sviluppatori, poiché ciò richiederebbe un po 'di tempo. –