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

29

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?

naming Zeemee
fuente
11
Inglés. Lingua franca para programación.
Plataforma
66
Uno de los mensajes de error más desafiantes '' PHP tiene un giro interesante en hebreo: unexpected T_PAAMAYIM_NEKUDOTAYIM. Habiendo visto esto algunas veces en mi vida, no tengo dudas de que uno debería usar el inglés.
K.Steff
3
¿Alguna de las expresiones específicas del dominio alemán tiene caracteres no estándar (por ejemplo, umulauts (sp?))? Si contrata programadores fuera de su región, es posible que no puedan encontrar un teclado con los caracteres necesarios (el mío no). Sí, hay formas de cambiar el idioma 'tipeado', pero no quisiera esa molestia.
Clockwork-Muse
2
Griego: el uso de alfabetos no latinos es mejor seguridad laboral que el klingon.
Wyatt Barnett
3
@ X-Zero al salir de ASCII simple abre la lata de gusanos "qué codificación de caracteres usamos". Por lo general, te muerden y no vuelves a ir allí.

Respuestas:

16

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.

lurkerbelow
fuente
2
Esta respuesta refleja mi opinión personal más, después de leer las otras respuestas. Especialmente este punto: "Es una complejidad innecesaria si todos los demás desarrolladores también son alemanes" al traducir todo.
Zeemee
1
@Mulmoth: "Es una complejidad innecesaria si todos los demás desarrolladores también son alemanes" --- ¿Cómo puede estar seguro de que en un momento dado, en algunos años, el proyecto no se subcontratará a otro país? ¿Cómo puede estar seguro de que un desarrollador que no hable alemán no se introducirá en el proyecto en algún momento?
Coral Doe el
55
@Coral Doe: creo que el desarrollador nuevo / otro / subcontratado ya tiene que profundizar en el dominio empresarial y sus expresiones específicas. Entonces, en mi opinión, es más fácil asignar lo que el cliente (que aún será alemán en ese momento) dice a las clases con nombre en alemán en lugar de nombres ingleses mal / mal traducidos.
Zeemee
2
Las "cosas" relacionadas con la facturación / impuestos alemanes nunca serán subcontratadas a un país de habla no alemana. En la universidad, alguien me dijo que el 85 por ciento de todos los libros de facturación / impuestos se refieren a las leyes alemanas y están escritos en alemán. en todo el mundo.
lurkerbelow
3
Estoy de acuerdo, pero un problema que casi siempre ocurre es que el lenguaje utilizado por los desarrolladores se filtra a los usuarios y otras partes interesadas. No como parte de la interfaz de usuario, sino cómo se habla sobre el dominio del problema. Esto inevitablemente conducirá a la confusión, ya que no todos hablan inglés con fluidez como la mayoría de los desarrolladores.
Mille Bessö
14

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.

Sylwester
fuente
55
Casi edité "universidad" a lo que supongo que se supone que es "colega", pero no estaba seguro de si fue intencional.
Jacob Schoen
Por supuesto, me refería a colega :)
Sylwester
Of course some words or concepts might not have a English counterpart- Siempre tengo curiosidad cuando eso surge en la programación, casi como si supieras un patrón de diseño que los hablantes de inglés no encontrarían. ¿Tienes un ejemplo rápido?
Izkata
55
@Izkata: la pregunta era sobre las clases de negocios . A menudo están vinculados a las normas y reglamentos específicos de cada país. Por ejemplo, si la ley lo obliga a rastrear la ubicación de todos los camiones con productos químicos peligrosos, bien podría nombrar esa clase después de esa ley.
MSalters
9

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.

Dimitrios Mistriotis
fuente
9

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.

empi
fuente
44
Ese es un buen punto: si todo el conocimiento del dominio está en el idioma local y no existen nombres en inglés acordados para los conceptos del dominio, puede ser una buena idea usar el idioma local.
Joachim Sauer
7

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.


fuente
2

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.


fuente
1
Parece que su párrafo final contradice totalmente el primero,
James
@ James - ¡gracias! Eliminé esa sección ya que no tengo tiempo en este momento para aclarar lo que quise decir. Se suponía que debía ser de apoyo, pero no importa.
1
Muy en desacuerdo. Dado que los conceptos básicos de prácticamente todos los idiomas que conocerá están escritos en inglés, el uso de terminología que no sea inglés conduce a un código fuente menos legible. La mente constantemente tiene que saltar entre el inglés y el otro idioma. El código debe ser fluido y legible.
Mike Adler
@MikeAdler: no está claro si no está de acuerdo con lo que sugiero como regla general (nombre las cosas en el idioma del equipo) o el caso de excepción, que debería ser muy raro.
Concedido. Aclararé: no estoy de acuerdo con que cualquier objeto deba nombrarse en un idioma que no sea inglés. Su primer encabezado 'Código abierto / proyectos tipo comunidad internacional' refleja muy bien mi punto de vista. Todo después de eso, no voy a comprar. La razón, como se dijo, es la mantenibilidad, que debería ser una preocupación primordial para prácticamente todas las decisiones de diseño (incluido el esquema de nombres) que tome, en mi opinión.
Mike Adler