¿Deberían cambiarse los nombres internos (clases, métodos, tablas de bases de datos, etc.) de las entidades si cambian los nombres de marketing y UI?

Hemos tenido un producto de larga vida durante aproximadamente 8 años. Con el tiempo, los nombres de conceptos y entidades cambian. ¿Deberíamos poner el trabajo para cambiar el nombre de todas las tablas y columnas de base de código y base de datos para que coincidan con estos nuevos nombres?

¿Se ha publicado un estudio sobre esto o algunas de las mejores prácticas?

Gracias

La falta de coincidencia entre los nombres internos y externos definitivamente huele. Como Rinzwind señala, los homófonos y sinónimos huelen peor.

La verdadera pregunta que debe responder es: ¿Cuál es el compromiso costo / beneficio al hacer el cambio?

El costo de no cambiar es una curva de aprendizaje más pronunciada para los nuevos miembros del equipo y una mayor probabilidad de errores futuros. El costo de cambiar es el tiempo obvio involucrado, una nueva curva de aprendizaje para los veteranos en el proyecto y la posibilidad de nuevos errores.

Si espera tener un número relativamente grande de nuevos miembros del equipo, es más probable que tenga sentido hacer el cambio. Si no espera ninguna rotación, el equipo actual no tiende a confundirse y el equipo está satisfecho con el statu quo, entonces no tiene sentido cambiar el nombre de las cosas.

Si se espera que el código viva por mucho tiempo y haya nuevos desarrolladores trabajando en él, haría los cambios.

Puede ser muy confuso y llevar mucho tiempo que un nuevo desarrollador entre en un proyecto y descubra que los nombres de las entidades son engañosos.

También existe el argumento válido de ... Si no está roto, no lo arregles.

Con respecto a su segunda pregunta, no conozco ningún estudio publicado o mejores prácticas. Con respecto a la primera pregunta, puedo ofrecer algunas observaciones de la experiencia personal con un producto similar de larga duración donde los nombres 'internos' y 'externos' a veces son diferentes.

Los nombres que realmente me gustaría arreglar son los "homófonos", donde un nombre se usa tanto interna como externamente para diferentes cosas. Esto puede ser realmente confuso, particularmente si las dos cosas no son completamente diferentes (de modo que el contexto ayuda a desambiguar). Un ejemplo (abstracto) de eso en mi experiencia personal es cuando internamente tienes algo así como Foouna colección de múltiples FooEntity; externamente, solo este último es visible y se llama "Foo". Me tomó un tiempo darme cuenta de que cuando el manual del cliente hablaba de múltiples "Foo", en realidad significaba múltiples FooEntity(en un solo Foo), si eso todavía tiene sentido para usted.

En segundo lugar, me gustaría arreglar cualquier "sinónimo" donde algún nombre externo se haya usado internamente. Al igual que en los nombres de variables, partes de nombres de métodos / funciones, etc. Esto sucede a menudo cuando los desarrolladores implementan algo directamente de la descripción de los requisitos del cliente y se olvidan de "traducir" los nombres. Una vez que eso sucede, el nombre 'incorrecto' también tiende a difundirse, porque otros desarrolladores copian / pegan parte de ese código para usarlo como plantilla para un nuevo código, por ejemplo. Estos sinónimos no son tan confusos, pero pueden ser molestos porque si está buscando referencias en el código, Bardebe tener en cuenta que algunas partes pueden referirse a él comoQux, así que tienes que buscar dos veces. (Sin embargo, esto puede ser peor en los idiomas de tipo dinámico que en los estáticos, ya que debe buscar en partes del nombre de variables / funciones / ... en lugar de en el nombre de su tipo). En cuanto al caso inverso de "sinónimos ", Donde un nombre interno se ha utilizado externamente: esto tiende a no suceder tan a menudo, ya que los empleados de atención al cliente, etc., generalmente son menos conscientes de los nombres internos, aunque supongo que es confuso para los clientes cuando sucede.

Si puede evitar o solucionar al menos las dos situaciones anteriores, no estoy seguro de si debe ir tan lejos como para hacer que todos los nombres internos sean los mismos que los externos. Probablemente haya una buena razón por la cual los nombres internos no se cambiaron también cuando el nombre externo se hizo diferente del interno en primer lugar. En mi experiencia personal, esa buena razón es la necesidad de admitir versiones anteriores del producto; podría ser difícil fusionar una corrección de errores de una versión de limpieza anterior a la versión más reciente si se tiene que cambiar mucho código.

Es un problema bastante común. Varios proyectos en los que he trabajado usan nombres de códigos en lugar de nombres de productos (que pueden no haberse decidido en ese momento), y usan una terminología muy diferente en el código que la que se muestra al usuario. Probablemente dejaría las cosas como están, a menos que esté experimentando un cambio de propósito masivo del código o si hay algo específico que causa problemas. No sirve para alterar el carrito de manzanas. Además, ¿quién puede decir que dentro de 5 años no habrá más cambios? Y luego tendrías que pasar por el cambio de nombre nuevamente. Y no olvide, eso también afecta cualquier documentación de código separada que pueda tener (API publicadas), lo que podría ser un problema particularmente costoso si se imprime (copia impresa).

Digo arreglarlo en cualquier caso donde el código está destinado a mantenerse durante cualquier período de tiempo. Probablemente ahorrará confusión y tiempo en el futuro.

Creo que a menudo las entidades de "marketing" no se corresponden exactamente con las entidades internas. En tales casos, tiene más sentido introducir una entidad en un nivel diferente de abstracción, lo que hace que las diferencias de terminología sean un punto discutible.

Por ejemplo, tenemos un modelo que representa una jerarquía. Cada nivel en la jerarquía tiene un término asociado basado en cómo se usa la jerarquía para modelar las relaciones del mundo real, pero internamente no hay una diferencia en el comportamiento de un nivel de la jerarquía al siguiente. La terminología es esencialmente solo un nombre para ese nivel en la jerarquía, por lo que para un nodo particular en el árbol, el nombre simplemente describe qué es el nodo; no prescribe ningún comportamiento en particular.

Además, el árbol tiene múltiples raíces, por lo que hay varios nodos sin un padre. Aunque conceptualmente existe una raíz (representaría esencialmente el universo), e incluirla en el modelo sería muchas operaciones mucho más simples, no existe un "término de marketing" para ello.

Por supuesto, los diferentes componentes de nuestro sistema utilizan una terminología diferente. Fueron desarrollados en diferentes momentos por diferentes equipos, y no tenemos control sobre todos ellos. En realidad, en algún momento, alguien agregó o eliminó un nivel en un componente, por lo que los otros niveles se desplazan uno con respecto al otro. Los mismos tres niveles están representados por A, B y C en un componente, pero como B, C y D en otro.

Dar un paso adelante en la abstracción y simplemente modelar todo como un "nodo" o algo igualmente genérico hace que este tipo de modelos sea mucho más fácil de razonar. Cada nodo sabe cuál es su "término de marketing", y el tipo que representa un término de marketing particular puede saber qué significa ese término en cada contexto.