Progetto di casa e progetto di lavoro che condivide la libreria comune in fase di sviluppo

4

Quelli tra noi che sviluppano software non solo per vivere, ma anche per hobby, hanno probabilmente riscontrato il seguente scenario:

Dì, c'è un progetto al lavoro chiamato WorkApplication su cui lavori insieme a un certo numero di colleghi. Supponiamo che questa applicazione stia utilizzando una libreria chiamata SharedLibrary che è in fase di sviluppo, il che significa che verrà eseguito il refactoring su SharedLibrary , e qualsiasi refactoring deve essere convertito a WorkApplication , in modo che WorkApplication compili sempre e corre.

Ovviamente, affinché funzioni, ogni volta che qualcuno apre WorkApplication nel proprio IDE, deve anche aprire SharedLibrary .

  • Nel linguaggio di Visual Studio, questo renderebbe sia WorkApplication che SharedLibrary "project" sotto la stessa "soluzione".

  • Nel linguaggio IntelliJ IDEA sarebbero "moduli" sotto lo stesso "progetto".

  • Nel linguaggio di Eclipse, sarebbero "progetti" sotto lo stesso "spazio di lavoro".

Ora, supponiamo che tu abbia anche un progetto di casa HomeApplication con cui giochi a casa, (da solo,) in cui vuoi anche usare SharedLibrary . (Supponiamo che al posto di lavoro non importi se usi SharedLibrary per le tue cose, proprio come non ti importa se il posto di lavoro beneficia del lavoro che hai messo su SharedLibrary mentre lavori a casa.)

Ovviamente, ogni volta che si rifatta il SharedLibrary , si desidera che questo venga applicato in cascata non solo a WorkApplication , ma anche a HomeApplication . Supponiamo che tu sia l'unico sviluppatore responsabile per SharedLibrary , quindi è improbabile che i tuoi colleghi lo modifichino, quindi non devi preoccuparti del fatto che SharedLibrary venga mai rifattorizzato da qualcuno che non sa nulla di HomeApplication . Quello che vuoi essere sicuro è che ogni volta che rifattori SharedLibrary , indipendentemente dal fatto che lo stai facendo nel contesto del lavoro o dell'hobby, sia WorkApplication che HomeApplication saranno sempre aggiornati.

Come fai a destreggiarti tra queste tre entità per mantenere tutto aggiornato?

Il problema sembra essere che diverse parti della soluzione / progetto / spazio di lavoro dovranno trovarsi in diversi repository di codice sorgente: WorkApplication e SharedLibrary devono essere nel repository del tuo posto di lavoro, mentre HomeApplication ha bisogno essere nel tuo repository home.

Non sono sicuro di come combinare più repository di codice sorgente sotto la stessa soluzione / progetto / spazio di lavoro. Può essere fatto? Qualcuno l'ha provato? Funziona? Quali problemi sono comuni?

Posso immaginare scenari in cui perdi i vantaggi delle operazioni del sistema di controllo della versione dall'interno dell'IDE, e invece fai tutto il tuo aggiornamento / impegno usando strumenti esterni, ogni volta separatamente per ciascun repository, ma può farlo in qualche modo dall'interno l'IDE?

Non voglio legare questa domanda a nessun IDE specifico, ma lasciatemi solo menzionare che l'IDE che mi interessa di più è IntelliJ IDEA. (Sfortunatamente, trovo che le opzioni relative a VCS di IntelliJ IDEA siano molto confuse: sembra che potrei essere in grado di definire più server VCS all'interno dello stesso progetto, ma non è chiaro come.)

    
posta Mike Nakis 15.02.2015 - 18:07
fonte

1 risposta

1

Potresti pensare in termini di pacchetti, il che rende irrilevante la posizione della sorgente.

Ad esempio, se lavori con C #, la tua libreria condivisa può essere pubblicata come pacchetto NuGet . Quando rifattori la libreria, non esegui una cascata immediatamente per l'applicazione di lavoro ; invece, pubblichi una nuova versione del pacchetto, e quando sei pronto migri l'applicazione di lavoro alla nuova versione, come faresti se, ad esempio, Microsoft rilasciasse una nuova versione di Entity Framework (non inseriresti la sorgente EF nella tua base di codice e chiedi agli sviluppatori di Microsoft di mettere in cascata le loro modifiche alle tue app aziendali, giusto?).

Questa è una relazione tra editore e consumatore . Fornisci un pacchetto gratuito (eventualmente open source) alla tua azienda che funge da cliente. Sono liberi di aggiornare le loro app alle nuove versioni del pacchetto o di continuare a utilizzare le versioni obsolete se lo desiderano.

Il fatto che lavori in questa azienda è irrilevante: immagina di agire come un consulente che conosce molto bene il pacchetto in questione e quindi si occupa della sua effettiva implementazione all'interno del prodotto.

Mescolare progetti fatti in casa con il tuo lavoro come livello sorgente non è una buona idea.

Se li ospitali separatamente (ad esempio, la tua biblioteca personale rimane nel tuo repository personale sul tuo server di casa), questo è problematico per l'azienda, poiché:

  • Non c'è alcuna garanzia che possano accedere alla fonte per sempre. Cosa succede se decidi di rimuoverlo o di spegnere il tuo server di casa? Persino la perdita della connettività Internet è problematica: almeno gli sviluppatori dovrebbero poter accedere al repository aziendale se è ospitato nello stesso edificio.

Se li ospitali insieme, questo crea una serie di problemi diversi:

  • L'azienda può applicare regole specifiche che non si desidera seguire per il proprio progetto personale, come le linee guida sullo stile. La società potrebbe richiedere una copertura di codice specifica o un codice conforme al linter o semplicemente che qualsiasi codice impegnato venga esaminato dalle coppie. Quegli standard, normali nell'ambiente aziendale, non dovrebbero applicarsi al tuo progetto personale.

    Peggio ancora, l'azienda potrebbe non aver bisogno di qualcosa in questo momento, ma stabilire un nuovo requisito di qualità un giorno. Cosa faresti? Modifica la tua libreria personale per abbinare? Rimuovere la libreria dal codice sorgente?

  • Alcuni manager potrebbero non capire quello che stai facendo e trovarlo scomodo. Nel peggiore dei casi, potrebbero considerare che stai spendendo il tuo tempo lavorando al tuo progetto sul lavoro, che può essere percepito molto male.

    Nel punto precedente, ho menzionato l'aggiornamento del tuo progetto personale in base agli standard aziendali. Che cosa succede se il tuo capo nota che stai lavorando su questo (e così su il tuo progetto ), mentre ci si aspetta che risolva bug per la prossima versione pianificata per la prossima settimana?

  • La proprietà intellettuale potrebbe essere un'altra preoccupazione. In molti casi, il codice all'interno del repository aziendale è di proprietà dell'azienda. Potresti non essere in grado di utilizzare, modificare o distribuire il tuo progetto se lasci la compagnia. Più in generale, tutto può sembrare a posto tra te e il tuo datore di lavoro, ed è così, fino a quando la relazione diventa un disastro e dovrebbe essere trattata dagli avvocati.

Il modello editore-consumatore risolve tutti e quattro i problemi:

  1. La compagnia sa che sarà in grado di accedere per sempre alla versione corrente del pacchetto. La rimozione di un pacchetto da NuGet è possibile, ma molto difficile.

  2. Non è necessario seguire regole e standard di terze parti. Questo è il tuo progetto, quindi le tue regole.

  3. Non c'è modo di biasimarti per aver lavorato sui tuoi progetti personali al lavoro. Sono chiaramente separati.

  4. Mantieni la proprietà intellettuale del tuo progetto e imposta la licenza del tuo gusto. Di nuovo, il tuo progetto, le tue regole.

risposta data 15.02.2015 - 18:22
fonte