Gli sviluppatori dovrebbero compilare una libreria interna prima del programma effettivo?

Recentemente uno sviluppatore senior con cui lavoro ha avanzato la richiesta che gli sviluppatori ottengano l'ultima versione e compilino come parte del loro progetto una grande libreria interna. Ciò è in contrasto con l'argomentazione contraria secondo cui i team di progetto dovrebbero lavorare su una versione stabile che ottengono da un repository Maven interno a cui lo sviluppatore ha sostenuto che avere il codice sorgente disponibile sui computer degli sviluppatori fa risparmiare tempo in quanto possono leggere l'origine delle librerie codice per determinare se è disponibile la funzionalità richiesta.

Lo sviluppatore senior ha un argomento valido? O è necessario che gli sviluppatori leggano il codice sorgente delle librerie in contrasto con la filosofia di base dell'incapsulamento e che abbiano anche la libreria in primo luogo?

L'argomento di questo sviluppatore senior non ha senso per me.

Vogliono aggiungere un sovraccarico per il costante recupero e compilazione di una libreria interna solo in modo che gli sviluppatori possano leggere occasionalmente il codice sorgente? Questo sprecherà molto più tempo rispetto al fatto che gli sviluppatori vadano a vedere il codice sorgente solo quando devono verificare se una funzione è disponibile.

Questa è una cattiva idea se la libreria e i client vengono sviluppati da diversi gruppi di sviluppo e la libreria viene attivamente sviluppata. Gli sviluppatori client non avranno alcun isolamento dall'instabilità nella libreria.

Non vedo perché il codice sorgente non possa essere reso disponibile agli sviluppatori senza costringerli a far parte del loro normale build.

Il suggerimento è

Possiamo risparmiare tempo dagli sviluppatori lato client leggendo il codice sorgente della libreria per determinare se la funzionalità richiesta è disponibile

Potresti dare un suggerimento alternativo

Possiamo risparmiare tempo da qualcuno che documenta la biblioteca per indicare quale funzionalità è disponibile.

Non comprerei l'argomentazione secondo cui avere la possibilità di sfogliare la fonte localmente è un vantaggio, ma se la libreria è in fase di sviluppo attivo (possibilmente per aggiungere supporto per le esigenze del tuo progetto), non credo sia irragionevole richiedere agli sviluppatori di scarica gli aggiornamenti frequentemente (possibilmente più volte al giorno). Penso che abbia senso per il business rendere disponibile un binario compilato (e testato in unità) invece di richiedere agli sviluppatori di compilare dal sorgente, comunque.

Hai la possibilità all'interno del tuo progetto di impostare una sorta di repository condiviso in cui sarebbe disponibile l'ultima versione compilata? Idealmente, si vorrebbe un server CI che eseguisse il recupero e la compilazione in base a una pianificazione, ma anche se è solo una risorsa di rete che uno dei responsabili del team è responsabile dell'aggiornamento periodico, potrebbe essere utile. Ovviamente, questo dovrebbe essere sul piatto del team della biblioteca, ma ovviamente non sono interessati, quindi dovrai prendere il loro gioco.

Lavoravo per una grande azienda di software che "alimentava costantemente" il proprio software con sistemi aziendali interni.

Hanno visto questo come un altro livello di test.

Il fatto che io sia d'accordo, per un'azienda, è una buona cosa.

Penso che costringerti a scaricare e compilare l'ultima versione sia un passo troppo avanti, a meno che il passo della compilazione non sia una parte importante dell'offerta della tua azienda di vendere o addirittura esternalizzare una biblioteca.

Avere a disposizione il codice sorgente può essere un vantaggio, se si dispone di un agente di build CI che monitora il repository, ha più senso fare in modo che l'agente compili questa libreria e lo copi in progetti dipendenti come esterno, piuttosto che richiedere agli sviluppatori di eseguire due diversi passaggi di compilazione durante la creazione della loro copia.

Attualmente sto lavorando a un progetto non collegato a un agente di compilazione, che richiede la creazione di un'applicazione secondaria prima di creare l'applicazione principale. È un dolore grave nel mio posteriore; per apportare una modifica alla sub-app, devo prima costruire l'intero progetto, quindi andare in una cartella di sub-build, estrarre il prodotto compilato e copiarlo in un'altra sottocartella, prima di costruire l'intero progetto NUOVAMENTE per assicurarsi che l'ultima versione dell'app secondaria sia inclusa nella build dell'app principale. Questo NON è come dovrebbe essere fatto; per lo meno dovrebbe esserci uno script MSBuild che automatizzerà questo processo, e preferirei che l'agente di costruzione aggiorni gli esterni ogni volta che viene inserito nuovo codice nel trunk.

Poiché così tante persone hanno risposto che non ha senso costruire tutti una biblioteca interna, presenterò il punto di vista opposto che potrebbe giustificare le ragioni:

1. Usi molto la biblioteca e non c'è documentazione. Quindi tutti dovrebbero avere la fonte di riferimento. Se si tratta di una libreria che viene utilizzata molto frequentemente, può essere utile avere il riferimento a portata di mano

   • Certo, si direbbe che dovrebbero lavorare sulla documentazione e molto probabilmente il vostro sviluppatore senior è consapevole di questo fatto. Ma affrontiamo la realtà, molte volte i team di sviluppo finiscono con una tonnellata di codice non documentato, quindi quando hai bisogno di sapere come funziona, vai alla fonte. Non dovresti farlo, ma a breve termine, questa è la migliore alternativa.
   • Di solito le persone migliori per mettere a punto la documentazione sono quelle che conoscono meglio la biblioteca. Sfortunatamente, quelle sono le stesse persone che sono in genere le più occupate, quindi spesso non è così facile per loro far cadere tutto e iniziare a documentare.

2. Quando le persone iniziano a scrivere il proprio codice che dipende dalla libreria e qualcosa nella libreria non funziona, invece di gettare le braccia in aria, se la libreria è costruita localmente, diventa molto facile entrare nel codice della libreria

   • Questo può accadere perché molte librerie sono tutt'altro che perfette e mentre tutti noi vogliamo lavorare con una versione "stabile", ci possono essere ancora problemi.
   • Forse stai ottenendo risultati negativi a causa di incomprensioni su come utilizzare un'API. Anche con la documentazione, le persone spesso fanno ipotesi errate
   • Il tuo ragazzo anziano è probabilmente stanco di nuove persone (e a volte ci sono molte più persone nuove di quelle che conoscono il progetto dentro e fuori) che gettano le braccia in aria ogni volta che un incidente / qualche altro errore sembra provenire da un codice della biblioteca. Quindi, invece di dover venire alla tua macchina e poi al ragazzo seduto accanto a te, vogliono l'opzione di rispondere con queste domande: 1) dov'è esattamente l'incidente? quale modulo / file / linea? 2) hai eseguito il debug? cosa hai trovato?
   • I tuoi ragazzi senior hanno lavorato con questa base di codice (applicazione e la tua libreria principale) abbastanza a lungo e potenzialmente potrebbero aver notato che quando il codice è già sulla macchina ed è pronto per il debug e il passaggio, semplifica la sua vita e rende le persone per apprendere più rapidamente la base di codice. Quindi, per questo motivo, ti costringe a sostenere i costi iniziali della costruzione della libreria sulla tua macchina.

Non sto dicendo che la sua decisione sia giustificata, sottolineando solo che a) la domanda presentava un lato della storia eb) potrebbero esserci motivi plausibili.

Questo tipo di test sarebbe meglio fare davvero. Il fatto è che dovrebbe essere fatto dai tester, non dagli sviluppatori . In questo senso, non è né il tuo né il tuo sviluppatore di biblioteche.

_{Da quello che descrivi sembra che non ci siano tester nel progetto - se questo è il caso, questo è un problema di gestione, e piuttosto grave.}

... consente di risparmiare tempo in quanto possono leggere il codice sorgente delle librerie per determinare se è disponibile la funzionalità richiesta

Abbastanza ragionamento. Quando la libreria della versione più recente non riesce a compilare con il progetto della versione più recente, potrebbero esserci diverse ragioni per questo - solo il drill nel codice sorgente della lib potrebbe essere una perdita di tempo.

• Cosa succede se la libreria è OK e l'errore di compilazione è stato causato dal bug nel codice di progetto? Oppure, se l'errore di compilazione fosse causato da una modifica temporanea incompatibile che dovrebbe essere corretta un giorno o due dopo? Cosa succede se un errore di compilazione indica un problema di integrazione complicato che richiederà una settimana o un mese per risolvere? Per un problema di integrazione, l'utilizzo di una libreria di versioni precedenti potrebbe risolvere il problema o no?
   
  Qualunque sia la ragione, fare un'analisi preliminare del fallimento significherebbe perdere tempo nello sviluppo di un lavoro che si suppone debba essere svolto dai tester.

Un'altra cosa che manca ai ragionamenti è l'inevitabile (e abbastanza dolorosa esperienza) delle perdite di produttività che si verificano quando si deve interrompere il flusso passando tra lo sviluppo e le attività di controllo qualità.

Quando ci sono tester nella squadra, queste cose sono davvero semplici e possono essere gestite molto più facilmente. Ciò che il tuo sviluppatore "senior" ti rivolge è fondamentalmente una bozza di test.

Ad ogni modifica apportata al progetto o alla libreria, assicurarsi che la compilazione abbia esito positivo.

I passaggi per procedere da lì sono tipiche attività di controllo qualità: chiarire i dettagli dei requisiti, progettare uno scenario di test formalizzato, negoziare su come gestire i fallimenti dei test.

• Dal punto di vista SQA , questo è un compito abbastanza ordinario di progettazione, impostazione e mantenimento di una procedura di test di regressione piuttosto semplice che potrebbe essere altamente automatizzata - probabilmente fino al punto che solo l'attività manuale creerebbe e manterrà i ticket nel tracker dei problemi e la verifica di correzioni.

Ciò che lo Sr Dev sta suggerendo non ha molto senso per me. È bello poter sfogliare le fonti, ma ci sono modi migliori per farlo.

Quale repository di artefatti stai usando? Dovresti essere in grado di distribuire un jar di origine per ogni versione da vivere accanto alla libreria compilata. La maggior parte degli IDE ti consentirà quindi di allegare questo alla libreria compilata per la navigazione di origine. Eclipse con il plugin Maven lo farà automaticamente.

Se hai bisogno del codice più recente, puoi semplicemente distribuire gli snapshot della versione.

Questo dovrebbe accadere semplicemente nel tuo script di build:

1. controlla se è disponibile una nuova versione. salta 2 altrimenti.
2. scaricarlo e compilarlo ed eseguire tutti gli strumenti necessari per generare un riferimento API dal codice sorgente localmente. mostra un registro delle modifiche.
3. costruisci la tua app

Non vedo perché o come questo sia un problema. Inoltre, quando manca qualcosa nel riferimento, è possibile aggiungerlo alle fonti e inviare le modifiche. Naturalmente potrebbe sembrare un po 'spaventoso che la biblioteca possa cambiare proprio sotto i tuoi piedi, ma se i manutentori della biblioteca fanno il loro lavoro correttamente, questa è una buona cosa.