Come si dovrebbe gestire le costanti in più lingue?

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

• Estrai le tue costanti (e forse i modelli) in un altro pacchetto che è cross-compilato in tutte le tue lingue. Potresti essere in grado di compilare a croce l'intera libreria, ma ciò potrebbe comportare una notevole quantità di problemi. Solo le costanti di cross-compiling dovrebbero essere abbastanza semplici da non creare altrettanti problemi. Puoi pubblicare il tuo pacchetto di costanti e dipendere da esso nelle tue librerie specifiche della lingua. Haxe probabilmente lo può fare. 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 di sapone hanno la lingua dei servizi Web (WSDL) ei servizi REST hanno Lingua descrizione 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 penso che sia necessario complicare molto il processo di generazione / rilascio. Metti il tuo file di configurazione in un progetto di compilazione separato (dove puoi metterlo in versione). Pubblica il progetto nei tuoi repository di pacchetti specifici per ogni lingua (Maven, Nuget, NPM, ecc.) Quindi nelle tue librerie specifiche della lingua puoi dipendere dal pacchetto. Questo non dovrebbe essere più complesso di un progetto aggiuntivo nella tua pipeline di build.
• Come suggerito da RubberDuck, la generazione del codice è una buona alternativa alla cross-compiling. È possibile generare definizioni costanti per ogni lingua utilizzando una configurazione comune.

Ottima domanda! Ho lo stesso identico problema; le mie costanti sono essenzialmente: quali sono le lingue supportate nelle mie applicazioni e ulteriori informazioni su quelle lingue che riguardano le funzionalità nell'app.

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

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

Inoltre, se la tua applicazione ha così tante costanti che ridefinendole per lingua quando le aggiungi o le cambia richiede una quantità significativa di tempo, potresti avere un odore di codice più significativo da trattare e, a quel punto, potresti vuoi passare a qualcosa di più complesso.

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

Una cosa per sicuramente , tuttavia, è assicurarsi che le tue costanti siano ben documentate in modo generalizzato (e linguistico agnostico) (abbiamo un repository documentarion aziendale con specifiche, documenti vari, documenti "da tavolo" ecc. dove conserviamo questo documento). Assicurati anche di avere meccanismi in atto per mantenere sincronizzate le loro definizioni. Si tratta di un grosso problema con l'approccio alla duplicazione, a parte una piccola quantità di stress psicologico dovuto alla duplicazione intenzionale del codice. Ma alla fine, i tuoi cambiamenti costanti dovrebbero essere deliberati e rari , quindi i problemi di sincronicità dovrebbero essere essenzialmente nulli.

Devo anche menzionare che nel corso degli anni ho visto porte multilingue di varie librerie (troppo stanche per ricordare quello che sono al momento) scritte dallo stesso gruppo che invariabilmente hanno costanti definite nelle lingue stesse. Nessuna configurazione condivisa, nessuna generazione di codice (eccetto per le 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 troverà una libreria per affrontare questo problema;)

Si spera che il nucleo della tua libreria sia scritto in una lingua e che le altre librerie utilizzino il FFI ( link ) per chiamare alla libreria principale. Questo ti darebbe la posizione centrale per fornire una 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 da quanto sia capace la 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 impostare un nuovo servizio? Per la stragrande maggioranza degli utenti che ho supportato, vorrei che tutto fosse autonomo - in questo modo gli utenti non dovrebbero pensarci.