Fornire più API riduce il riutilizzo del codice

1

All'interno di un'organizzazione, si supponga di avere uno strumento interno utilizzato da diversi team e per diversi casi d'uso. Questo pacchetto offre API in diverse lingue.

  • Si potrebbe dire che avere più API consente a più persone di utilizzare lo strumento, poiché non devono imparare una nuova lingua e possono usare quella preferita.
  • D'altra parte, si potrebbe anche sostenere che ciò rende più difficile il riutilizzo del codice. Se la squadra A utilizza il linguaggio X e sviluppa uno script piacevole utilizzando lo strumento, la squadra B può riutilizzare lo script solo se funziona anche nella lingua X.

La mia domanda è: dalla tua esperienza, qual è l'impatto globale di avere più API (potenzialmente più persone che usano lo strumento, ma non possono condividere il loro codice) o una singola (meno persone che usano lo strumento, ma puoi condividere il loro codice)?

Esempio

Un'organizzazione ha creato un pacchetto interno per ottenere previsioni del tempo, con API Python e C.

Un team che lavora con Python crea un nuovo componente da questo, che aggrega le previsioni del tempo e anche il traffico (con l'aiuto di un altro strumento) per la posizione dell'utente.
Sebbene questo codice sia utile, non ha nulla a che fare con l'API dello strumento di previsione meteo e non è generico / a prova di proiettile / abbastanza significativo da diventare un pacchetto separato.

Un altro team che lavora con Python potrebbe riutilizzare questo nuovo componente con alcune piccole modifiche mentre il team che lavora con C dovrebbe riscrivere l'intero componente da zero.

    
posta filaton 09.11.2018 - 16:09
fonte

3 risposte

1

Fornire più API non riduce la capacità dei propri progetti di riutilizzare il proprio codice tra quelle API (se ben progettato), né limita la possibilità di condividere il codice tra i progetti (altrimenti dovremmo riscrivere il sistema operativo ogni volta facciamo un nuovo programma).

Riformulerò la tua domanda come:

Does providing multiple API's limit my clients ability to share and reuse code?

Risposta breve: no.

Risposta più lunga: altre cose, non il numero di API.

Riutilizzare se stesso non ha barriere tecniche che non possano essere facilmente superate. Specialmente in questo giorno ed età.

Ci sono molte librerie là fuori che consentono a una lingua di chiamare in un altro *. Questo potrebbe essere fatto interpretando l'altro programma (embedded put-on, lua, tcl, etc ... (anche c)), o eseguendo il marshalling della chiamata attraverso il componente compilato come da JNI, COM, HTTP, SOAP, ecc., o anche collegando direttamente o dinamicamente il componente.

Anche se il componente non lo supporta già, dovrebbe essere ragionevolmente possibile fornire una shell per il componente che permetta lo scripting della shell (disponibile da qualsiasi linguaggio desktop / server) per lavorare con esso.

Quindi, dal punto di vista dell'utente, non vi è alcun motivo tecnico per cui non possano condividere la loro bella sceneggiatura, con qualcun altro che desidera utilizzarlo.

Il problema principale è in effetti il problema di qualsiasi manutentore di servizi pubblici / biblioteche. Quando condividi il codice ci sono una serie di responsabilità accessorie.

  • Deve essere affidabile: questo codice dipende da, deve funzionare o ragionevolmente fallire.
  • Deve essere stabile - Gli aggiornamenti dovrebbero preservare il comportamento dell'interfaccia. Le modifiche al cambiamento dovrebbero essere contrassegnate, avere soluzioni e percorsi di migrazione.
  • Ha bisogno di essere documentato - Non puoi usare nemmeno lo script più bello senza sapere come.
  • Ha bisogno di essere mantenuto - I bug si verificano, le vulnerabilità vengono scoperte, i sistemi a monte cambiano. Questi devono essere risolti.
  • Deve essere distribuito - Il codice a cui non è possibile accedere è inutilizzabile, dietro un servizio, in un binario o come sorgente.
  • Ha bisogno di circuiti di feedback (una comunità) - Il codice è solo un artefatto di una comunità di individui che conoscono il problema da risolvere, questa è la cosa più importante di sempre. Il codice è solo la soluzione migliore per una soluzione.

Non prenderei in considerazione la possibilità di rendere il mio software dipendente da altri software che non hanno almeno queste proprietà accessorie. Come fornitore di API sei consapevole di quanto possano essere banali queste cose.

Se la capacità dei tuoi clienti di condividere il codice è fondamentale per la tua piattaforma / applicazione. Prendi in considerazione la possibilità di offrire servizi simili a GitHub o qualche forma di gestore di pacchetti. Ciò ridurrebbe l'onere di queste spese accessorie agli sviluppatori a valle, riducendo allo stesso tempo l'onere per i loro clienti. Migliorerebbe ulteriormente il senso di comunità attorno al tuo software, mettendo in contatto queste persone tra loro. Scopriranno come riutilizzare in modo specifico ogni altro codice.

* Nota a margine: C può incorporare un ambiente python completo e Python può essere facilmente esteso dalle librerie C .

    
risposta data 11.11.2018 - 12:43
fonte
0

On the other hand, one could also argue that this makes code reuse more difficult. If team A uses language X and develops a nice script using the tool, team B can reuse the script only if they also work in language X.

Come sottolineato da altri, se la funzionalità è di natura non banale, la centralizzerei in modo che entrambe le lingue possano accedervi (e quindi riutilizzarle).

My question is: from your experience, what is the global impact of having multiple APIs (potentially more people using the tool, but they can't share their code) or a single one (less people using the tool, but they can share their code)?

In generale, ho lavorato su prodotti che spesso supportavano più linguaggi anche di quelli che ne avevano fornito uno proprietario (casi antichi prima che fosse così popolare semplicemente incorporare cose come Python o Lua).

E in pratica si tende ad allentare la collaborazione tra gli sviluppatori che lavorano in questi diversi linguaggi. Generalmente svilupperanno diverse comunità e mentalità e modi di pensare e fare cose. La comunità di scripting pensa e approccia le cose in modo diverso e potenzialmente produce un codice di utilità diverso da condividere rispetto alla comunità di sviluppatori Java JNI o alla comunità di sviluppatori di plugin C ++ nativi. E potrebbe esserci qualche ridondanza di sforzi tra questi gruppi separati, sia che si tratti di duplicare il codice o qualcos'altro (ad es. Pubblicare libri e documentare come programmare il software).

Sul lato positivo, espandi il tuo gruppo demografico di persone che contribuiscono allo sviluppo e l'essere in grado di utilizzare più lingue può talvolta essere utile anche a un singolo sviluppatore. Il linguaggio di scripting incorporato potrebbe essere più veloce per creare qualcosa e più facile da distribuire e port (dato che non ci sono binari da compilare) e più sicuro (es: nessuna possibilità di segfaulting), mentre il codice nativo potrebbe essere utile da raggiungere quando le prestazioni sono un problema legittimo.

Another team working with Python could reuse this new component with some minor adjustments while the team working with C would have to rewrite the whole component from scratch.

Se quel componente è abbastanza utile da essere condiviso, cercherò di evitare questa restrizione. Nel nostro caso i plug-in scritti in script possono eseguire / valutare plug-in scritti in codice nativo e viceversa (quelli erano sempre requisiti pratici nel nostro caso dato che la nostra architettura plugin riguardava i plugin che registravano componenti che si valutavano / eseguivano l'un l'altro, e il punto era rendere irrilevante il linguaggio utilizzato per implementare i plug-in).

Dove ho trovato sforzi duplicati era più nel regno di cose secondarie che non avrebbero migliorato la produttività tanto da cercare di estinguere del tutto come una piccola duplicazione negli sforzi di documentazione, funzioni di utilità, condivisione di frammenti di codice, ecc., e solo il collaborazione più libera che ottieni da sviluppatori che praticamente parlano e pensano in diversi linguaggi di programmazione.

Se riesco a divagare un po ', non sempre trovo produttivo aumentare al massimo il riutilizzo del codice piuttosto che cercare pragmaticamente di mantenerlo entro limiti pratici e mantenibili. Nella peggiore delle ipotesi è possibile vedere comitati emergenti e litigi su come qualcosa di piuttosto banale nella funzionalità che salva a mala pena le persone il tempo di usare dovrebbe essere progettato in una libreria centrale (es: sviluppatori che discutono se una classe di bounding box dovrebbe archiviare centri e metà -misura o due vettori min / max, quando stavano ottenendo molto più lavoro svolto usando semplicemente classi separate in quel caso nei loro progetti locali), con più argomentazioni, passo-passo e, peggio ancora, trovare la funzionalità che viene spostata in posizioni centrali che non sono state testate in modo approfondito e testate in produzione per essere abbastanza stabili da dirigere molte dipendenze nella sua direzione, solo per ricevere ripetute modifiche centrali che interrompono tutto il suo utilizzo.

Quindi in questi giorni non trovo così utile prendere il riutilizzo del codice a un livello così zelante. Non sto parlando di tollerare massicci sforzi nella duplicazione, o bug duplicati, o qualcosa del genere, ma solo per rilassarlo a un livello pragmatico (come forse non passiamo 2 ore in una riunione degli sviluppatori a discutere su come progettare un riutilizzabile classe di bounding box che soddisfa perfettamente le esigenze di tutti quando un accordo unanime sembra impossibile, e non impazzire se un paio di sviluppatori sviluppano uno specifico per i loro bisogni localmente nei loro progetti), e fanno affidamento su ciò che gli sviluppatori stanno producendo l'obiettivo finale anche se c'è un po 'di ridondanza in termini di cosa potrebbero fare.

    
risposta data 10.12.2018 - 17:30
fonte
0

Dovresti guardarlo da una prospettiva diversa. Il punto di avere un modulo con più interfacce in primo piano non è mai riutilizzato in quanto tale. Riutilizzare di per sé non è mai un obiettivo, è nel migliore dei casi un risultato. Il punto è avere un'implementazione di qualche importante pezzo di logica in modo che possa essere controllata e mantenuta centralmente, dalle persone giuste, e sarà sempre la stessa logica usata da qualsiasi utente.

    
risposta data 11.12.2018 - 05:30
fonte

Leggi altre domande sui tag