2009-06-25 22 views
7

Trabajo con varios desarrolladores en India y una de nuestras mayores dificultades es el nombramiento de variables. Al principio estaba muy frustrado y no podía entender por qué no nombrarían las cosas correctamente (¿era pereza?) Sin embargo, me di cuenta de que probablemente no están acostumbrados a nombrar variables, porque todo el código que leen está en Inglés, y las palabras en inglés que leen tienen poco o ningún significado para ellos. Parece obvio ahora, pero es imposible nombrar las variables bien si no puedes entender el inglés adecuadamente.Nombramiento variable y miembros del equipo que hablan otro idioma

¿Cómo trabajarías para mejorar las prácticas de nomenclatura con un miembro del equipo de habla extranjera?

Disculpa si esto es un poco subjetivo, lo he marcado Wiki de la comunidad.

Gracias!

+0

Este es un problema común en nuestra org. Estoy interesado en ver las respuestas. +1. –

Respuesta

1

Encuentra al único desarrollador con el que estás trabajando por allá que sepa algo de inglés y haz que todos ellos ejecuten nombres de variables por él.

1

Tal vez les pida que nombren las variables descriptivamente en su idioma nativo y luego usen un traductor para convertirlas al inglés? ¿Podría incluso agregar marcas y ejecutar un precompilador para hacer la traducción automática? Solo un pensamiento.

3

La mayoría de los desarrolladores deberían tener una comprensión razonable del inglés técnico (después de todo, las API en la mayoría de los idiomas están escritas en inglés). Por lo tanto, el inglés parece una buena opción. Las variables generalmente no tendrán nombres muy difíciles, por ej. xCounter, isXYZ, etc. Y si son difíciles de nombrar, lo tomaría como una señal segura de que el nivel de abstracción en el que se declara esa variable no es el correcto.

Uno podría proponer la localización de nombres de variables. He descubierto que realmente difícil, más hoy en día cuando es típico para el código para ser tomado por personas situadas en otros continentes, las compañías adquiridas en el extranjero, etc.

tengo que ceder ☺

12

cambiar los requisitos para los miembros de su equipo - Deben tener una comprensión adecuada del inglés escrito.

Editar: en respuesta al comentario de Bill K, me parece que el costo de lidiar con problemas de comunicación pobres no se tiene en cuenta en los cálculos de ahorro. No, nunca he trabajado con desarrolladores en el extranjero, pero sí trabajo con 2 personas que no hablan inglés y la comunicación va un poco más lenta con ellos a veces, a pesar de que ambos han vivido en los EE. UU. Durante 20 años.

Además, no esperaba que mi respuesta fuera la más útil. Solo estoy tratando de hacer un punto. Si no contrata a alguien para trabajar en su oficina, ¿por qué los contrataría para que trabajen para usted desde el otro lado del mundo? Incluso si está en una agencia, indirectamente está contratando a todos los desarrolladores que trabajan en su código.

Mi experiencia ha sido que cuando se trata de talento para el desarrollo, ser barato puede ser bastante costoso.

+0

Generalmente, es algo sobre lo que no tienes control. No sé si has trabajado en la industria, pero normalmente nadie que esté por debajo del nivel de director se ofrecerá como voluntario para trabajar con contratistas de otro país para ahorrar dólares de desarrollo. Tomando en consideración, su respuesta puede ser correcta pero no es útil. –

+0

lo suficientemente cierto, barato = barato y de mala calidad – akf

+0

@Dennis Estoy totalmente de acuerdo, no lo haría. De hecho, podría renunciar si estuviera trabajando para una empresa que quería comprometer su futuro con un equipo de desarrollo de otro país porque lo vería como una empresa condenada, pero mi punto es que nunca he visto un caso donde un desarrollador realmente tenía alguna opción en el asunto. La compañía puede intentar hacerle pensar que tiene una opción en el asunto, pero no importa cuánto objete y cuánto le demuestre que le faltan costos, ellos harán lo que han decidido hacer. –

4

Si todo el mundo habla el mismo idioma y no venderá el código a otra compañía, entonces está bien escribir el código en su idioma nativo.

Si cada miembro habla un idioma diferente, el código debería estar en inglés. Intenta hacer un diccionario de las palabras más comunes usadas en la aplicación donde todo el mundo puede verificar. Elija a alguien con más habilidades de inglés para traducir cuando sea necesario.

Y siempre puede refactorizar cuando algunas palabras se ven mal.

+1

me gusta la idea del diccionario – Shawn

7

Puede hacer que la 'nomenclatura variable' sea un tema para cada revisión de código. Sería un tema de la agenda de hecho que podría ser fácil de discutir. Puede usar la discusión como un indicador de si entienden lo que están tratando de lograr.

+1

De lejos, la única idea viable aquí. Revisar el código y simplemente cambiarlos: debe ser trivial en eclipse/netbeans. Normalmente, si desea que su proyecto tenga incluso algún éxito, debe dedicar un desarrollador por cada 2-4 desarrolladores en el extranjero, así que simplemente agregue esto como una de las cosas que tiene que hacer. Si la administración entendiera este principio, ¡serían menos aptos para ir a buscar ayuda en el extranjero! –

2

No tengo la intención de ser crítico, pero tengo una pregunta real ... Si no son lo suficientemente fluidos en inglés para nombrar las variables, ¿cómo son lo suficientemente fluidas como para comprender un modelo de dominio empresarial basado en el inglés? , mucho menos diseñar y construir un producto de software que resuelva un problema del mundo real en ese dominio.

+0

no hacen mucho diseño, es más la implementación de software personalizado, correcciones de errores, etc. siguen una especificación bastante rígida, pero el mantenimiento del código (aparte de la copia en bloque masivo) puede ser una pesadilla con variables llamadas algo completamente diferente a su tarea – Shawn

+0

Aquí hay un escenario. Un equipo de programadores que son bastante hábiles y que en su mayoría entienden inglés técnico escrito, pero que por lo demás apenas pueden hablar y escribir, han ganado cierta reputación escribiendo software de código cerrado para sus clientes de habla inglesa (gracias a la administración que habla bien el inglés). Hasta aquí todo bien, ya que a nadie le importa cómo nombren sus entidades.Sin embargo, ahora deciden seguir adelante para cooperar con, digamos, una empresa de software estadounidense que se enamora de su reputación, y solo entonces se revela el problema con el error ... ¿el nombramiento feo? Ahí tienes. –

1

No estoy seguro del problema específico, es decir, los nombres de las variables no son descriptivos, o usan nombres de variables que no están en inglés, el estilo de nomenclatura variable es incoherente, etc. De cualquier manera, puede intentar establecer estándares de codificación detallados y quizás use auditorías de código o revisiones para hacerlos cumplir. Por ejemplo:

  • El uso de "temp" como el nombre de las variables locales no se permite
  • Las variables deben ser nombrados de manera que el propósito de la variable es obvio
  • Use siempre un estilo consistente para nombrar las variables (por ejemplo, Camel Case)

La clave sería publicar estas reglas y aplicarlas para toda la organización.

+0

esto es algo que hemos intentado. Desafortunadamente, hacer reglas sobre lo que se debe hacer nunca puede ayudar con el contenido real de los nombres de las variables. pueden dejar de usar la carcasa húngara, pueden usar siempre una carcasa consistente, etc., pero nunca usarán nombres de variables como numberOfMissingPageTemplates; será algo así como un contador – Shawn

Cuestiones relacionadas