Ci si aspetta che gli sviluppatori compilino una libreria interna prima del programma vero e proprio?

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

Vogliono aggiungere un sovraccarico al recupero costante di & compilare una libreria interna solo così gli sviluppatori possono a volte leggere il codice sorgente? Questo significa perdere molto più tempo rispetto a quando gli sviluppatori cercano il codice sorgente solo quando devono verificare se una funzionalità è disponibile.

Questa è una pessima 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 della loro normale build.

Il suggerimento è

We can save time by client-side developers reading the library's source code to determine if required functionality is available

Potresti fare un suggerimento alternativo

We can save time by someone documenting the library to indicate what functionality is available.

Non comprerei l'argomento secondo cui avere la possibilità di esaminare localmente la sorgente è un vantaggio, ma se la libreria è in sviluppo attivo (probabilmente per aggiungere supporto per le esigenze del progetto), allora non penso sia irragionevole richiedere agli sviluppatori di scaricare gli aggiornamenti frequentemente (eventualmente più volte al giorno). Penso che sia più sensato dal punto di vista commerciale rendere disponibile un binario compilato (e testato unitamente) anziché richiedere agli sviluppatori di compilare dal sorgente.

Hai la capacità all'interno del tuo progetto di creare una sorta di repository condiviso dove sarebbe disponibile l'ultima versione compilata? Idealmente, vorresti un server CI che eseguisse il recupero e la compilazione in base a una pianificazione, ma anche se si tratta solo di una risorsa di rete a cui uno dei responsabili del team è responsabile dell'aggiornamento periodico potrebbe essere d'aiuto. Ovviamente, questo dovrebbe essere nel piatto della squadra della biblioteca, ma ovviamente non sono interessati, quindi dovrai prenderti cura di loro.

Lavoravo per una grande azienda di software che era costantemente "dogfooding" del proprio software con sistemi aziendali interni.

L'hanno visto come un altro livello di test.

Sono d'accordo, per un'azienda, è una buona cosa.

Penso che forzare il download e compilare l'ultima versione sia un passo troppo lungo, a meno che la fase di compilazione sia una parte importante delle offerte delle aziende di vendita o persino di esternalizzazione di una libreria.

Pur avendo il codice sorgente disponibile può essere un vantaggio, se si ha un agente di compilazione di elementi di configurazione che controlla il repository, ha più senso avere quell'agente compilare questa libreria e copiarla in progetti dipendenti come esterna, piuttosto che richiedere gli sviluppatori di eseguire due diversi passaggi di compilazione durante la creazione della copia.

Attualmente sto lavorando a un progetto che non è collegato a un build agent, che richiede la creazione di una sotto-applicazione prima di costruire l'applicazione principale. È un dolore serio nel mio posteriore; per apportare una modifica all'app secondaria, prima devo costruire l'intero progetto, quindi andare a una cartella secondaria, ottenere il prodotto compilato e copiarlo in una sottocartella diversa, prima di costruire l'intero progetto ANCORA per assicurarti 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 build aggiorni gli elementi esterni ogni volta che il nuovo codice viene inserito nel trunk.

Poiché così tante persone hanno risposto che non ha senso fare in modo che tutti costruisca una libreria 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 questa è una libreria che viene usata molto frequentemente, avere a portata di mano il riferimento potrebbe essere utile

   • Certo, si potrebbe dire che dovrebbero lavorare sulla documentazione e più che probabilmente lo sviluppatore senior è a conoscenza di questo fatto. Ma affrontiamo la realtà, molte volte i team di sviluppo finiscono con un sacco di codice non documentato, quindi quando hai bisogno di sapere come funziona, vai alla fonte. Non dovresti farlo, ma a breve termine, questa è l'alternativa migliore.
   • Di solito le persone migliori per mettere la documentazione sul posto sono quelli che conoscono meglio la libreria. Sfortunatamente, quelle sono le stesse persone che sono in genere le più impegnate, quindi spesso non è così facile per loro abbandonare 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 lanciare le braccia in aria, se la libreria è costruita localmente, diventa molto facile entrare direttamente nel codice libreria

   • Questo può accadere perché molte librerie sono lontane dall'essere perfette e mentre tutti vogliamo lavorare con una versione "stabile", ci possono comunque essere problemi.
   • Forse stai ottenendo risultati sbagliati 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 (ea volte ci sono molte più persone nuove di quelle che conoscono il progetto dentro e fuori) che lancia le braccia in aria ogni volta che un incidente / qualche altro errore sembra provenire da una biblioteca codice. Quindi, invece di dover venire alla tua macchina e poi al tizio seduto accanto a te, vogliono la possibilità di rispondere con queste domande: 1) dove si trova esattamente l'incidente? quale modulo / file / linea? 2) l'hai messo a punto? cosa hai trovato?
   • I tuoi ragazzi senior hanno lavorato con questa base di codice (applicazione e libreria principale) abbastanza a lungo e potenzialmente potrebbe aver notato che quando il codice è già sulla macchina ed è pronto per essere sottoposto a debug e passaggi, rende la sua vita più facile e fa in modo che le persone imparino il codice base più velocemente. Quindi per questo motivo ti costringe a prendere il costo iniziale della creazione della libreria sul tuo computer.

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

Questo tipo di test dovrebbe essere fatto meglio. Il fatto è che dovrebbe essere fatto dai tester, non dagli sviluppatori . In questo senso, non è né il lavoro del tuo sviluppatore né della tua biblioteca.

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

...saves time as they can read the libraries source code to determine if required functionality is available

Abbastanza ragionamento. Quando la libreria delle versioni più recente non riesce a compilare con il progetto di versione più recente, ci potrebbero essere diversi motivi per farlo: solo scavare nel codice sorgente della lib potrebbe essere inutile.

• Che cosa succede se la libreria è a posto e l'errore di compilazione è causato dall'errore nel codice del progetto? O, se il fallimento della build fosse causato da un cambiamento temporaneo incompatibile che dovrebbe essere corretto un giorno o due dopo? Cosa succede se un errore di compilazione indica un complicato problema di integrazione che richiederà una settimana o un mese per risolvere il problema? Per un problema di integrazione, l'utilizzo di una versione precedente di una libreria può costituire una soluzione alternativa o meno?
  
  Qualunque sia la ragione potrebbe essere, fare un'analisi preliminare del fallimento significherebbe sprecare tempo per gli sviluppatori in un lavoro che dovrebbe essere svolto dai tester.

Un'altra cosa che manca al ragionamento è inevitabile (e piuttosto doloroso nella mia esperienza) di perdite di produttività che seguono quando si deve interrompi il flusso passando da attività di sviluppo e controllo qualità.

Quando ci sono dei tester nel team, queste cose sono davvero semplici e possono essere gestite molto più facilmente. Quello che il tuo sviluppatore "senior" ti ha lanciato è fondamentalmente un requisito per i test di bozza.

Upon every change made to the project or library, make sure that build is successful.

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

• Dalla prospettiva SQA , questo è un compito abbastanza normale di progettazione, impostazione e gestione di un test di regressione procedura che potrebbe essere altamente automatizzata - probabilmente fino al punto che solo l'attività manuale potrebbe creare e mantenere ticket in track tracker e verifica delle correzioni.

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

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

Se hai bisogno del codice più recente, puoi semplicemente distribuire le istantanee della versione.

Questo dovrebbe accadere semplicemente nel tuo script di costruzione:

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

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