¿En qué idioma debo nombrar mis clases de negocios?

Estoy solicitando mejores prácticas con esta pregunta. Creo que esto es solo un problema si la empresa del cliente es estrictamente nacional y tiene un idioma nativo distinto del inglés.

Si el cliente tiene muchas expresiones principalmente muy específicas de dominio (por ejemplo, alemán), mezcladas con algunos nombres menores de dominio específico. El idioma de nuestros comentarios de código, nombres de clase / método / variable es inglés. ¿Traducirías todos los nombres específicos de dominio?

Estoy trabajando en Alemania y prefiero elegir inglés.

A veces, por ejemplo, cosas específicas del dominio, como crear un módulo para "DATEV" (software alemán de facturación / facturación), uso nombres alemanes. Algunas palabras alemanas no se pueden traducir correctamente, por ejemplo, "Referenzbuchungsnummer" (ReferenceBookingNum?) O "Sachkontenlaenge" (..?). También creo que las cosas específicas del dominio terminarían en horror de mantenimiento. Quizás recuerde que ReferenceBookingNum se relacionaría con "Referenzbuchungsnummer", pero ¿qué pasa con sus compañeros de trabajo? Tienen que estudiar la documentación interna sobre nombres, si existe documentación. No estarán muy familiarizados con el módulo sin tener nombres propios. Es una complejidad innecesaria si todos los demás desarrolladores también son alemanes. Pero "CakeFactory" suena mucho mejor que "KeksFabrik";)

Entonces todo depende.

Siendo noruego trabajando en una empresa noruega, nombro mis objetos en inglés. Por supuesto, algunas palabras o conceptos pueden no tener una contraparte en inglés y en ese caso se puede argumentar que una palabra nativa podría usarse en lugar de un mal reemplazo o traducción literal que no tiene significado. Por supuesto, muchos de estos problemas podrían ser el hecho de que algunos de nosotros deberíamos tener un mejor vocabulario, por lo que generalmente le pregunto a un colega si no puedo pensar en un buen nombre en inglés :)

Parte de nuestro personal no es noruego y, por lo tanto, escribir en inglés los beneficia. Poder contratar programadores de la mayor parte de Europa es bueno para la economía, por lo que mi empresa también se beneficia de ello.

Por cierto: recuerdo que leí la fuente de Hermes una vez (implementación de ebXML b2b) y me habría costado mucho si me hubieran escrito y comentado en mandarín.

Creo que, dado que el inglés es la lengua franca del dominio de TI, limitar su código fuente a otro idioma crea obstáculos artificiales para su desarrollo. Primero, limita el grupo de personas que pueden contribuir a las que hablan un idioma específico. La misma razón que solicitó en el intercambio de pila y no en un sitio local.

Tampoco sabe de dónde vendrán las contribuciones ni a dónde irán. ¿Qué pasa si usa una muestra de un sitio, lo traducirá? ¿Qué sucede si el producto se expande para ser utilizado por clientes en otro país? ¿En caso de que necesite contratar un contratista / subcontratar un poco? ¿Por qué limitarse a un grupo y no obtener el mejor ajuste de todo el mundo?

Puede suponer que está bien para algunas estructuras específicas de dominio que no se asignan fácilmente a otros idiomas, o si se mantiene una base de código existente.

Mi último objetivo del proyecto fue modelar el dominio comercial de colaterales e hipotecas. Todos los desarrolladores y la empresa para la que trabajamos son de Polonia. Creamos el software siguiendo los principios de diseño impulsado por dominio. Utilizamos nombres polacos para todas las entidades comerciales y creo que fue una muy buena elección. Creo que pudimos evitar problemas de comunicación gracias a este enfoque. El dominio comercial constaba de muchos términos que ni siquiera sabía en polaco, sin mencionar las traducciones al inglés. Utilizamos solo letras latinas y todas las clases técnicas se nombraron en inglés.

Generalmente es más fácil leer el código fuente escrito en un solo idioma. Esto para la mayoría de los lenguajes de programación implica que debe escribirlo en inglés.

Dicho esto, hay un problema importante con los conceptos de dominio que no se traducen fácilmente al inglés. Un ejemplo típico es un identificador único que la sociedad le da al individuo: en los EE. UU., El concepto más cercano es el número de seguro social, pero no es un mapeo preciso. Los nombres y números de teléfono generalmente se mapean bastante bien.

Creo que, por lo general, es necesario mantener los términos del dominio cada vez que una asignación precisa no está disponible en inglés, pero solo esos: mantenga el resto en inglés. Resultará en identificadores inusuales como KommuneImpl, pero debería tener sentido inmediato para aquellos que conocen el dominio.

Proyectos de código abierto / comunidad internacional

El idioma común de los proyectos comunitarios de código abierto e internacional es el inglés. Caso en cuestión, el idioma de los sitios de Stack Exchange es el inglés. Para una accesibilidad más amplia, se debe usar el inglés para todos los nombres de código y objeto.

Proyectos comerciales

La mayoría de las empresas internacionales de software ordenan que el código se escriba en inglés. Es el máximo común denominador, por lo que tiene sentido usar el inglés como un medio para crear consistencia.

Muchas empresas de software regionales escriben en su idioma nativo. No todos siguen este enfoque, pero tiene sentido desde su punto de vista: usan el lenguaje común para todos sus desarrolladores.

Nombrar objetos comerciales

El lenguaje de codificación del equipo debe usarse para nombrar objetos.
La prioridad es que los desarrolladores puedan comunicarse entre sí con respecto a los objetos y los requisitos del proyecto. Si el equipo escribe en francés, los objetos de negocio deben nombrarse en francés. Si codifican en inglés, entonces nombra los objetos en inglés.

Su pregunta agrega una arruga porque el cliente habla un idioma nativo que no es el idioma de codificación de su equipo. Aún debe usar el lenguaje de codificación de su equipo para nombrar los objetos.
Cuando los analistas de negocios o desarrolladores necesitan comunicarse con el cliente sobre los objetos de negocios específicos, puede ser necesaria una traducción del nombre del objeto del lenguaje de codificación al idioma del cliente según sea necesario. Desde mi experiencia, es bastante raro que haya hablado sobre objetos de código específicos con el cliente, por lo que la traducción al idioma del cliente realmente no ha sido necesaria.

La única excepción a la regla de denominación es cuando un objeto no tiene otro término suficientemente conciso para capturar la intención del objeto. OMI, esto es realmente raro, pero puede ocurrir. Sin embargo, en realidad, es lo mismo que los idiomas hablados hacen para expresar conceptos particulares. " Fachada " es originalmente un término francés, pero ha sido adaptado por el inglés para expresar el concepto, y es un patrón de diseño común. " Schadenfreude " es otro buen ejemplo de un término prestado, aunque no creo que tenga un patrón correspondiente.