¿Cómo se deben administrar las constantes en varios idiomas?

Tengo una situación en la que apoyo lo que funcionalmente es la misma biblioteca en varios idiomas. A menudo hay constantes que deben compartirse entre ellas (por ejemplo, claves de nombre de campo json o códigos de error).

La forma en que hago esto actualmente es tener un código que defina las constantes en cada idioma.

El problema viene en mantenimiento. Si agrego un nuevo código de error, necesito actualizarlo en cada biblioteca manualmente. Si bien esto está bien para algunos, se vuelve tedioso si tengo 5 sdks para actualizar. Sería bueno tener una sola fuente de verdad para estos también.

He pensado en algún tipo de archivo de configuración, pero luego debe incluirse en cada paquete implementado que agrega complejidad a nuestro proceso de compilación / lanzamiento.

¿Hay una mejor manera de manejar el mantenimiento de constantes que se comparten entre varios idiomas?

Aunque creo que su enfoque actual es probablemente el más simple y directo, aquí hay algunas ideas alternativas:

• Extraiga sus constantes (y quizás modelos) en un paquete diferente que se compila en todos sus idiomas. Es posible que pueda realizar una compilación cruzada de toda la biblioteca, pero eso puede conllevar una gran cantidad de problemas. Solo las constantes de compilación cruzada deben ser lo suficientemente simples como para que no haya tantos problemas. Puede publicar su paquete de constantes y depender de él en las bibliotecas específicas de su idioma. Haxe probablemente pueda hacerlo. Este enfoque es bueno porque aún tendrá verificación en tiempo de compilación (para idiomas compilados)
• Almacene la configuración en un servicio central. Por ejemplo, los servicios web de soap tienen el lenguaje de descripción de servicio web (WSDL) y los servicios REST tienen el lenguaje de descripción de aplicación web (WADL) que describe las operaciones y los mensajes del servicio. También hay servicios de configuración centralizados genéricos como Spring Cloud Config
• Archivo de configuración. Sé que ya lo has sugerido, pero no creo que deba complicar mucho tu proceso de compilación / lanzamiento. Coloque su archivo de configuración en un proyecto de compilación separado (donde puede versionarlo). Publique el proyecto en sus repositorios de paquetes específicos de todos los idiomas (Maven, Nuget, NPM, etc.) y luego en sus bibliotecas específicas de idiomas puede confiar en el paquete. Esto no debería ser más complejo que tener un proyecto adicional en su canal de compilación.
• Como RubberDuck sugirió, la generación de código es una buena alternativa a la compilación cruzada. Puede generar definiciones constantes para cada idioma utilizando una configuración común.

Gran pregunta! Yo tengo exactamente el mismo problema; mis constantes son esencialmente: qué idiomas son compatibles con mis aplicaciones e información adicional sobre esos idiomas en lo que respecta a la funcionalidad de la aplicación.

Desafortunadamente, lo mejor que he encontrado (como lo has hecho) es simplemente redefinir las constantes para cada idioma, como lo estás haciendo actualmente (lo sé, definitivamente querías escuchar eso ).

Obviamente se siente mal porque es lo contrario de DRY ( WET ?? ). Sin embargo, las constantes deben cambiar con tan poca frecuencia que los 5-10 minutos de redefinirlas para cada idioma realmente no me molestan. Al final del día, los pequeños problemas con alguna solución 'elegante' como la configuración compartida o la generación de código podrían tardar horas o días en resolverse, entonces, ¿qué se gana realmente? La complejidad añadida con el riesgo de que algo salga mal que podría requerir un esfuerzo adicional para solucionarlo no es algo con lo que quiera tratar.

Además, si su aplicación tiene tantas constantes que redefinirlas por idioma cuando las agrega o cambia toma una cantidad de tiempo considerable, es posible que tenga que lidiar con un olor a código más significativo y, en ese momento, es posible que desee cambiar a algo más complejo

En resumen, redefinirlos para cada idioma ha sido mi mejor solución, y todavía tengo que pensar en algo más SECO que no tenga más factor de riesgo del que quiero tratar.

Sin embargo, una cosa que debe hacer definitivamente es asegurarse de que sus constantes estén bien documentadas de manera generalizada (y agnóstica del lenguaje) (tenemos un repositorio de documentación de la compañía con especificaciones, documentos misceláneos, documentos de 'tablero de dibujo', etc., donde guardamos este documento). También asegúrese de tener mecanismos establecidos para mantener sus definiciones sincronizadas. Eso es un problema tan grande con el enfoque de duplicación como lo tendrá, excepto por una pequeña cantidad de angustia psicológica por la duplicación intencional de código. Pero al final, sus cambios constantes deberían ser muy deliberados e infrecuentes , por lo que los problemas de sincronía deberían ser esencialmente nulos.

También debo mencionar que a lo largo de los años, he visto puertos en varios idiomas de varias bibliotecas (demasiado cansados ​​para recordar lo que son en este momento) escritos por el mismo grupo que invariablemente tienen constantes definidas en los propios idiomas. Sin configuración compartida, sin generación de código (excepto para las bibliotecas de cliente API de Google ... pero vamos, Google tiene los recursos para permitirse tal complejidad). Así que creo que hemos golpeado una pared de ladrillos en este caso. Quizás alguien finalmente encuentre una biblioteca para tratar este problema;)

Con suerte, el núcleo de su biblioteca está escrito en un idioma, y ​​las otras bibliotecas usan FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) para llamar a la biblioteca principal. Esto le daría la ubicación central para proporcionar una API para publicar las constantes y definiciones. De esta manera, todo está contenido en la biblioteca. Solo menciono esto, ya que no parece estar incluido en la respuesta de Samuel.

Creo que realmente depende de cuán capaz sea su base de usuarios. ¿Son lo suficientemente capaces de manejar pasar un archivo de configuración diferente? ¿Son capaces de configurar un nuevo servicio? Para la gran mayoría de los usuarios que he apoyado, me gustaría que todo fuera autónomo, de esta manera los usuarios no tendrían que pensar en ello.