Come si dovrebbero gestire le costanti in più lingue?


13

Ho una situazione in cui supporto quella che è funzionalmente la stessa libreria in più lingue. Esistono spesso costanti che devono essere condivise tra queste (ad esempio chiavi del nome del campo json o codici di errore).

Il modo in cui lo faccio attualmente è avere il codice che definisce le costanti in ogni lingua.

Il problema si presenta nella manutenzione. Se aggiungo un nuovo codice di errore, devo aggiornarlo manualmente in ogni libreria. Mentre questo va bene per alcuni diventa noioso se dico 5 sdks da aggiornare. Sarebbe bello avere una sola fonte di verità anche per questi.

Ho pensato a una sorta di file simile a una configurazione, ma poi deve essere incluso in ogni pacchetto distribuito che aggiunge complessità al nostro processo di compilazione / rilascio.

Esiste un modo migliore per gestire la manutenzione di costanti condivise tra più lingue?


Il tuo approccio va bene, Enderland. Stavo cercando di trovare una soluzione migliore per la ridefinizione perché molte volte più clienti consumano il programma API I e in realtà non esiste una soluzione elegante. La ridefinizione delle costanti è ancora la più semplice.
Andy,

5
@DavidPacker no no no dovresti avere una soluzione davvero elegante per me. Non dirmi che questo è il migliore che ci sia! :-)
enderland

1
Stavo mettendo in discussione le mie scelte ma poi mi sono reso conto che le costanti sono pensate per essere costanti. Sono prevedibili perché sono costanti. Memorizzandoli in un JSON o in qualsiasi altro formato generalmente analizzabile, non sono più realmente costanti. Un tipico esempio nel mio processo di lavoro è un oggetto di notifica contenente un typeattributo per l'identificazione della struttura durante il trasferimento attraverso il filo. Detto questo, i client mobili definiscono solo le costanti (tipi) che comprendono al momento e ignorano qualsiasi tipo sconosciuto. La definizione dinamica causerebbe molti problemi.
Andy,

È necessaria una tabella di tabelle che si associa a righe di costanti da tabelle di lingue.
johnny,

Risposte:


10

Anche se penso che il tuo attuale approccio sia probabilmente il più semplice e diretto, ecco alcune idee alternative:

  • Estrai le tue costanti (e forse i modelli) in un pacchetto diverso che viene compilato in tutte le tue lingue. Potresti essere in grado di compilare in modo incrociato l'intera libreria, ma ciò potrebbe comportare una notevole quantità di problemi. Solo le costanti di compilazione incrociata dovrebbero essere abbastanza semplici da non presentare altrettanti problemi. Puoi pubblicare il tuo pacchetto di costanti e dipenderlo dalle tue librerie specifiche della lingua. Haxe probabilmente può farlo. Questo approccio è buono perché avrai ancora il controllo in fase di compilazione (per le lingue compilate)
  • Memorizza la configurazione in un servizio centrale. Ad esempio, i servizi web soap hanno il linguaggio di descrizione dei servizi Web (WSDL) e i servizi REST hanno il linguaggio di descrizione dell'applicazione Web (WADL) che descrive le operazioni e i messaggi del servizio. Esistono anche servizi di configurazione centralizzata generici come Spring Cloud Config
  • File di configurazione. So che l'hai già suggerito, ma non credo che debba complicare molto il tuo processo di compilazione / rilascio. Metti il ​​tuo file di configurazione in un progetto di costruzione separato (dove puoi versione). Pubblica il progetto nei tuoi repository di pacchetti specifici per tutte le lingue (Maven, Nuget, NPM, ecc.), Quindi nelle tue librerie specifiche per la lingua puoi dipendere dal pacchetto. Questo non dovrebbe essere più complesso di avere un progetto aggiuntivo nella pipeline di compilazione.
  • Come suggerito da RubberDuck, la generazione di codice è una buona alternativa alla compilazione incrociata. È possibile generare definizioni costanti per ogni lingua utilizzando una configurazione comune.

5
La generazione del codice di @RubberDuck sembra interessante (in particolare per uno dei miei casi d'uso tangenziali, che comunque coinvolge già un generatore di codice).
enderland

3

Ottima domanda! Ho lo stesso problema esatto; le mie costanti sono essenzialmente: quali lingue sono supportate nelle mie applicazioni e informazioni aggiuntive su quelle lingue in relazione alla funzionalità nell'app.

Sfortunatamente, la cosa migliore che ho trovato (come hai fatto) è semplicemente ridefinire le costanti per ogni lingua, come stai facendo attualmente (lo so, sicuramente lo volevi sentire ).

Ovviamente sembra sbagliato perché è l'opposto di DRY ( WET ?? ). Tuttavia, le costanti dovrebbero cambiare così raramente che i 5-10 minuti di ridefinirle per ogni lingua non mi disturbano davvero. Alla fine della giornata, piccoli problemi con una soluzione "elegante" come la configurazione condivisa o la generazione di codice potrebbero richiedere ore o giorni per risolversi, quindi cosa si guadagna davvero? La complessità aggiunta con il rischio che qualcosa vada storto e che possa richiedere uno sforzo ulteriore per risolvere non è qualcosa che voglio affrontare.

Inoltre, se la tua applicazione ha così tante costanti che la ridefinizione per lingua quando le aggiungi o le cambi richiede un notevole lasso di tempo, potresti avere solo un odore di codice più significativo da affrontare e, a quel punto, potresti voler girare a qualcosa di più complesso.

Quindi, in breve, ridefinirle per ogni lingua è stata la mia soluzione migliore, e devo ancora pensare a qualcosa di più ASCIUTTO che non avrebbe più fattore di rischio di quello che voglio affrontare.

Una cosa da fare sicuramente , tuttavia, è quella di garantire che le costanti siano ben documentate in modo generalizzato (e indipendente dal linguaggio) (abbiamo un repository documentarion aziendale con specifiche, documenti vari, documenti "tavolo da disegno", ecc. Dove conserviamo questo documento). Assicurati inoltre di disporre di meccanismi per sincronizzare le loro definizioni. Questo è un problema tanto grande quanto l'approccio di duplicazione che avrai, ad eccezione di una piccola quantità di disagio psicologico dovuto alla duplicazione intenzionale del codice. Ma alla fine, i tuoi costanti cambiamenti dovrebbero essere molto deliberati e poco frequenti , quindi i problemi di sincronicità dovrebbero essere sostanzialmente nulli.


Devo anche ricordare che nel corso degli anni ho visto porte multilingue di varie biblioteche (troppo stanche per ricordare cosa sono al momento) scritte dallo stesso gruppo che invariabilmente hanno costanti definite nelle stesse lingue. Nessuna configurazione condivisa, nessuna generazione di codice (ad eccezione delle librerie client dell'API di Google ... ma dai, Google ha le risorse per permettersi tale complessità). Quindi penso che abbiamo colpito un muro di mattoni su questo. Forse qualcuno alla fine inventerà una biblioteca per affrontare questo problema;)


0

Si spera che il nucleo della tua libreria sia scritto in una lingua e le altre librerie usano FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) per chiamare la libreria principale. Questo ti darebbe la posizione centrale per fornire un'api da cui pubblicare le costanti e le definizioni. In questo modo tutto è autonomo all'interno della libreria. Sto solo citando questo dato che non sembra essere incluso nella risposta di Samuel.

Penso che dipenda davvero dalla capacità della tua base di utenti. Sono abbastanza capaci da essere in grado di gestire il passaggio di un altro file di configurazione? Sono in grado di configurare un nuovo servizio? Per la stragrande maggioranza degli utenti che ho supportato, vorrei che tutto fosse autonomo, in questo modo gli utenti non avrebbero dovuto pensarci.


1
Hopefully, the core of you library is written in one language, and the other libraries use FFI Sfortunatamente abbiamo librerie sia per un client web che per il codice server (in più lingue) quindi ... non sarebbe banale riuscire a risolverlo (e probabilmente una vulnerabilità della sicurezza se potessimo iniziare con l'app Web).
enderland

Suggerirei di migliorare la tua sicurezza, poiché non mi fiderei mai abbastanza dei miei utenti per mantenere segreti i file di configurazione.
Robert Baron,

Come si distribuiscono le applicazioni Web che gestiscono i codici di errore? O i nomi dei campi json? Sono confuso da quello che pensi che stia facendo, è un problema di sicurezza. L'esecuzione di codice arbitrario sulla macchina del mio client è assolutamente un problema di sicurezza, consentendo loro di analizzare JSON da un server non sembra essere a meno che non mi manchi qualcosa.
enderland

Ho lavorato presso aziende, le cui basi per la sicurezza erano generatori di numeri casuali in stile DOS e valori seed memorizzati come costanti. Questi tendevano a essere risolti molto rapidamente dopo essere stati segnalati. Tuttavia, se metti il ​​valore del seme nel mondo, daresti la chiave del regno. Poiché il tuo software sembra essere principalmente basato sul web, mantieni la configurazione in un oggetto JSON e lascia che ciascuna delle lingue analizzi lo stesso file condiviso.
Robert Baron,

I nomi dei campi JSON probabilmente non dovrebbero e non dovrebbero essere costanti. Quali sarebbero le possibilità che questi nomi di campo debbano cambiare, ma non cambi il nome della costante stessa? Probabilmente avrai maggiori probabilità di trarre vantaggio dalla generazione di codice per accedere alle voci o dall'uso del linguaggio delle espressioni come ObjectPath.
Lie Ryan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.