Procedura di sviluppo e commit delle API interne

Question

Procedura di sviluppo e commit delle API interne

#1 da (1 voti)
#2 da (0 voti)

2

Ora sono impegnato nell'estensione e nel refactoring di un set di API e di strutture dati principali da cui dipende la maggior parte degli altri componenti. La squadra è piccola (5 persone).

Un manager mi ha detto che prima di verificare le mie modifiche, dovrei cercare in tutto il codice, scoprire tutte le funzioni che dipendono dalle API che ho modificato e, se necessario, modificarle per assicurarmi che l'intero software funzioni . Sono rimasto un po 'sorpreso da questa richiesta.

In termini di procedura, penso che tutto ciò che dovrei fare è testare le mie cose, documentare e fornire istruzioni affinché gli altri aggiornino di conseguenza. Ciò che rende questa richiesta ancora peggiore è che so che i test unitari non sono completamente condotti per alcuni componenti. Come posso essere sicuro che il mio cambiamento non creerebbe bug nel componente di qualcun altro? E lo sviluppo è attivo, è quasi certo che la mia spinta verso i cambiamenti per qualcun altro creerebbe conflitti locali ovunque.

Prima di rifiutare questa richiesta, qualcuno può fornire qualche altra prospettiva a questa richiesta? Qual è la pratica comune per l'aggiornamento dell'API interna? Grazie.

api

posta Feischi 05.12.2014 - 01:03

fonte

2 risposte

Leggi altre domande sui tag api

Come accedere ai servizi Web protetti da un'applicazione desktop? Soluzioni per il recupero ORM parziale

score 1 · Answer 1

Sembra che la grande preoccupazione del tuo manager sia quella di assicurarsi che il software sia sempre in uno stato funzionante nel repository. Questa non è una richiesta irragionevole, in quanto potrebbero essere richiamati e compilati per il rilascio in qualsiasi momento, e vorrebbero essere certi che non stiano rilasciando una brutta build.

Il tuo manager ha proposto un'opzione, ma questa opzione ha i problemi che hai citato. Devi cercare l'intera base di codice per le chiamate nell'API (che potrebbe non essere affidabile al 100%). Devi modificare il codice in fase di sviluppo attivo da parte di altri team, il che può portare sia a unire conflitti che a conflitti interpersonali. Proverai a codice refactoring che potresti non capire completamente (e non hai il supporto per i test). Questo approccio può portare a ... sfide.

Ci sono altre opzioni. Ad esempio, potrebbe essere opportuno rifattorizzare la vecchia API in una scheda per la nuova API. In questo modo, il nuovo codice viene chiamato internamente, mentre esternamente nessuno dovrebbe aver bisogno di modificare immediatamente il proprio codice. Nel corso del tempo, puoi eseguire la conversione lavorando con gli altri sviluppatori, non attorno a loro, il tutto mantenendo il codice completamente funzionante.

Un vantaggio è che è possibile aggiungere la registrazione alle vecchie chiamate API per scoprire dove vengono effettuate tali chiamate, e con quale frequenza vengono visualizzate chiamato. In questo modo, puoi dare la priorità a determinate aree per la conversione senza dover cambiare tutto in una volta.

Questa strategia non sarebbe senza le sue sfide. Ad esempio, potresti avere conflitti di denominazione tra le due API. Lo sviluppo di uno schema di versioning per la tua API ti aiuterà e risolverà questo problema in futuro. Dovrai supportare entrambe le API per un po 'di tempo. Poiché la vecchia API semplicemente avvolgerà la nuova API, le modifiche dovrebbero per lo più ricadere sulla nuova API. Potrebbe essere necessario risolvere alcune incompatibilità (strutture di dati deprecate, ecc.). Questo è il par per il corso, ma limiterebbe questo problema a un singolo posto nel tuo controllo diretto.

score 0 · Answer 2

Il mio trucco è assicurarmi che il compilatore stia facendo tutto il lavoro per te.

Contrassegnerò un metodo o una classe come [Obsolete] per trovare tutti i posti in cui è utilizzata, o semplicemente utilizzare la funzione Trova tutti i riferimenti. il metodo [Obsolete] è migliore in quanto ciò informerà i consumatori in fase di compilazione che è stata fornita una tecnica alternativa.

Diagram le classi e le strutture delle API in modo da poter identificare funzionalità autonome, funzioni di supporto, temi comuni e dipendenze. Se possibile, documenta le classi utilizzate dai consumatori per vedere quanto delle classi / campi / eventi dell'API possono essere resi privati o interni senza danneggiare i consumatori. Più piccola è l'interfaccia pubblica di cui hai bisogno per mantenere il più flessibile possibile nella rielaborazione.

Può anche essere utile creare letteralmente interfacce pubbliche e aggiungerle nell'API come primo passo, successivamente qualsiasi modifica che devi apportare a questa interfaccia si rifletterà in un errore del compilatore e puoi facilmente trovare i consumatori che usano trova tutti i riferimenti o simili.

Cerca i punti di estensione incorporati nell'API e usali, non reinventare la ruota o ridefinire ampie porzioni di codice .. prova a lavorare con il codice che è già lì il più possibile.

Se usi Visual Studio prova questo addin di Microsoft che può aiutarti a trovare casi angolari in un codice base che potrebbe essere necessario affrontare e implementare System.Diagnostics.Contracts che può aiutarti a trovare il codice che rientra quei casi angolari.

Cerca di includere il maggior numero di utenti critici dell'API nel build per le API, in questo modo, anche se la compilazione richiederà più tempo, riceverai una notifica in fase di compilazione di eventuali problemi emersi dalle modifiche apportate alla libreria.