Aggiornamenti dell'API specifici del contesto allo sviluppatore

Suppongo che tu stia parlando di un sistema in cui hai accesso al codice sorgente completo di tutti gli sviluppatori coinvolti, ed è tutto all'interno di un'unica organizzazione, giusto?

Non penso che funzionerà bene a livello di API, devi fare qualcosa di simile a livello di componente / modulo / libreria. Anche se non si modifica sintatticamente l'API, le modifiche interne in una libreria possono influire sul codice di tutti quelli che utilizzano quella libreria (e l'unico modo per assicurarsi che le tue modifiche non si interrompano è che deve fare o eseguire test sufficienti). Tuttavia, se conosci un programma o un modulo che non fa riferimento a un altro componente / modulo / libreria, allora una modifica non può romperlo facilmente.

Quindi un modo migliore è di avere le tue modifiche (semanticamente e sintatticamente) documentate per modulo. E per informare attivamente lo sviluppatore giusto, quelli che potrebbero essere interessati da un cambiamento in un modulo specifico (e nessun altro), hai bisogno di due cose:

• un grafico di riferimento, il quale applicazione o modulo sta usando / referenziamento / collegamento quale altro modulo

• un elenco di chi è responsabile per ciascun modulo

(e si presume che tu abbia quei documenti, dovrebbe essere chiaro come usarli).

Per il grafico di riferimento dei moduli, a seconda delle dimensioni del sistema e dell'ecosistema del linguaggio di programmazione utilizzato, è possibile mantenerlo manualmente, provare a trovare alcuni strumenti per la generazione di riferimenti incrociati o implementare uno scanner di riferimento manualmente (forse in una sorta di linguaggio di scripting). Il secondo è probabilmente meglio gestito manualmente.

Ritengo che questa sia una soluzione in cerca di un problema. Non ho mai visto gli sviluppatori preoccuparsi che un log delle modifiche contenga informazioni extra: cadono in 2 grandi gruppi, quelli che non leggono comunque il changelog e quelli che leggono tutto per vedere cosa sta succedendo.

Ciò che puoi fare è rendere più facile leggere e analizzare il registro delle modifiche.

Vorrei semplicemente classificare le modifiche in ogni versione, eventualmente includendo la funzione API o la classe o l'area che è cambiata e contrassegnare bug o funzionalità. per esempio. Il changelog di Jenkins ha punti colorati per le funzioni, le caratteristiche, i principali bug ecc. così puoi vedere a colpo d'occhio se un aggiornamento può essere ignorato o ha bisogno di da applicare presto. il log delle modifiche di Boost contiene gruppi per correzioni di errori, modifiche generali o rompere i cambiamenti.

Ciò che entrambi mancano è un indicatore per mostrare quale area è stata cambiata. Dato una cosa del genere (ad es. Un boost su cui si applica la modifica) sarebbe altrettanto buono di un changelog personalizzato per sviluppatore, significativamente più facile da creare e mantenere, e soddisferebbe la curiosità di coloro che leggono i changelog.

Oh, e alcuni sviluppatori non useranno una particolare API a causa della mancanza di funzionalità o bug .. come saranno informati quando l'API verrà migliorata o aggiustata per renderla adatta a loro per voler iniziare a usarla se non possono vederlo nel changelog?!