¿En qué medida debemos cambiar el nombre del código y los datos cuando cambian las nomenclaturas de los usuarios finales?

Para mí, definitivamente es mejor cambiar todo lo relacionado con el elemento en cuestión.

Es una forma de degradación del código, y aunque 1 elemento que no se cambia no es un gran problema, establece el tono para la base del código.

También podría generar confusión en el futuro y dificultar que los nuevos desarrolladores entiendan el código base / dominio.

A partir del contenido de la pregunta y las etiquetas, supongo que estás usando un lenguaje ubicuo.

En mi experiencia, UL es excelente, pero, como mencionó, puede llevar a tareas de mantenimiento adicionales a medida que el lenguaje evoluciona. Esto, en sí mismo, no es algo malo. Claro, es un inconveniente, pero también se espera.

Lo que normalmente he hecho (y he visto hecho) es:

• Refactorización inicial de 1 disparo: Refactoriza todas las capas de la aplicación para adoptar el lenguaje actualizado; o
• registrar deuda técnica: puede cambiar el código orientado al usuario de inmediato y luego registrar las tareas de deuda técnica para que el resto de las capas de la aplicación estén en línea con el idioma actualizado. Esto generalmente resulta en un puñado de tareas aburridas (pero manejables). (Perfecto para 5pm!)

Creo que la clave aquí es que lo que estás describiendo es deuda técnica y debería ser reconocido como tal.

He tenido gerentes que han argumentado que no deberíamos perder el tiempo en tareas tan triviales que no agregan ninguna funcionalidad visible. Esto es cuando la analogía de deuda realmente es útil. Se reduce a esto:

El equipo eligió hacer DDD con lenguaje ubicuo. Eliminar este enfoque al dejar el código en un estado incoherente agrega confusión y elimina muchos de los beneficios que proporcionan DDD y UL. En términos gerenciales, agrega costo al proyecto. El código se vuelve más difícil (costoso) de administrar y más confuso para los nuevos desarrolladores (costoso).

Es posible que desee ver las opciones de Localización (l10n). Si bien puede no parecer tan drástico como pasar del inglés al español, se trata de un término diferente para el mismo concepto. Si esto parece ocurrir con frecuencia, el uso de l10n puede permitirle cambiar rápidamente lo que se muestra en la interfaz de usuario sin tener que cambiar el término utilizado en el código.

Con eso en su lugar, solo use los términos en su código que sean los más entendidos. Elija los nombres del dominio como los desarrolladores lo saben y podrían esperar.

A medida que describe esto adecuadamente, rastree la nomenclatura del usuario final Los cambios en cada parte de la fuente son una gran inversión. Es Sin embargo, definitivamente vale la pena, especialmente para un producto de larga vida. desarrollado por una infraestructura completa (con línea directa, evaluadores, etc.)

El seguimiento de la nomenclatura del usuario final en la fuente es una inversión porque se debe a Hay tantos tipos de componentes donde aparece y no hay Varita mágica trabajando simultáneamente en todos estos componentes. Tal vez Desarrollar una varita mágica, componente tras componente, es un inversión interesante que puede diluir durante la vida útil de la proyecto.

Trabajé en una base de código de 30 años donde la deriva entre el usuario final La nomenclatura y la nomenclatura interna crecieron especialmente grandes. aquí Hay algunos inconvenientes de esta situación, que se suman a la sobrecarga. del trabajo de todos:

1. En ausencia de una política adecuada, los nuevos desarrollos tienden a utilizar el nomenclatura actual del usuario final. Así, el mismo concepto puede tener dos o más nombres en diferentes componentes. Desde los componentes interactuar juntos, esto da como resultado varios nombres sinónimos existentes de forma simultánea en algunas partes locales del código.

2. Cuando se llama a la línea directa / servicio de asistencia, escriben una historia de usuario usando nomenclatura del usuario final. El desarrollador encargado de arreglar el problema debe traducir la nomenclatura del usuario final para que coincida con el nomenclatura de la fuente. Por supuesto no está archivado, y por supuesto es un lío. (Ver 1.)

3. Cuando el programador depura el código, quiere establecer puntos de interrupción en funciones relevantes. Es difícil encontrar el adecuado funciona si la nomenclatura del usuario final y la nomenclatura de origen No estoy de acuerdo. Incluso puede ser difícil o imposible tener confianza que una lista de las funciones relevantes es incluso completa. (Ver 1.)

4. En ausencia de una política adecuada, el mantenimiento de la fuente mediante un La nomenclatura obsoleta pondrá de vez en cuando esta obsoleta Nomenclatura de nuevo frente a los usuarios. Esto produce pobres impresión y causa sobrecarga.

Ya he rastreado durante dos días el mismo lugar donde se encuentran algunos datos lea la base de datos e inyecte en algún componente de este código base. Porque si yo ni nadie en la empresa en la que trabajé pudimos figura un nombre que lleva a este lugar que finalmente desestimé y decidí Encuentra otra solución a ese problema.

Si bien cuesta más de [1] dos días de mantenimiento sin rendir Cualquier cosa (sin conocimiento, sin solución, nada) es probablemente tan mala como puede obtener, discrepancias entre nomenclatura de usuario y nomemlatura de fuente agregue gastos generales a muchas tareas rutinarias en el mantenimiento de un software.

Es importante destacar que los gastos generales aumentan con la empresa. produciendo el software, en una organización grande, un informe de problemas No llegue a su escritorio antes de que haya sido considerado por varios Los colegas y la solución pueden estar sujetos a prueba.

[1] Debido a que hay más de un desarrollador involucrado.

No siempre renombro el código y los datos porque algunos paquetes se comparten entre los clientes. Básicamente están usando lo mismo pero lo llaman de manera diferente. Por ejemplo, en un CMS, un cliente llama a su cliente "Cliente" y otro usa "Cliente". Entonces, reemplazamos Cliente por Cliente en la superficie para un cliente, pero CMS siempre será un Sistema de Gestión de Clientes.

Otro ejemplo es la administración de usuarios con términos como permisos frente a lista de control de acceso, administrador y administrador, etc. Puede ser confuso para los usuarios nuevos, pero para los componentes principales como esos, generalmente hay desarrolladores centrales que se aseguran de que esos componentes funcionen para todos los clientes y también es fácil de implementar por otros desarrolladores (por ejemplo, mediante la creación de etiquetas configurables).

Podría ser útil pensar que si realiza este cambio, es de esperar que no necesite hacerlo nuevamente si otro cliente utiliza la misma pieza, básicamente convirtiéndola en un producto.