¿Cómo lidiar con el cambio de características y nombres de productos en el código fuente?

¿Cuál es una buena estrategia para tratar con cambiar los nombres de productos y características en el código fuente? Esta es la situación en la que me encuentro una y otra vez (¿la mayoría de ustedes pueden relacionarse?) …

  1. El nombre del producto comienza como "DaBomb"
  2. Las principales características son "Exploder", "Lantern" y "Flag".
  3. El time pasa, y los nombres de las funciones se cambian a "Boom", "Lighthouse" y "MarkMan"
  4. El time pasa y el nombre del producto cambia a "DaChronic"
  5. Bla, bla, bla … una y otra y otra vez

Y ahora tenemos una gran base de código con 50 nombres diferentes salpicados alnetworkingedor del tree de directorys y los files fuente, la mayoría de los cuales están obsoletos. Solo los veteranos restringn lo que significa cada nombre, la historia etimológica completa, etc.

¿Cuál es la solución a este lío?

Aclaración: no me refiero a los nombres que los clientes ven, me refiero a los nombres de directorys, files fuente, classs, variables, etc. que los desarrolladores ven en donde se tejen los nombres cambiantes de productos y características.

Dada su aclaración de que "no se refiere a los nombres que los clientes ven, [usted] significa los nombres de directorys, files fuente, classs, variables, etc. que los desarrolladores ven", sí, esto puede ser un problema molesto.

La forma en que los equipos en los que he trabajado se han enfrentado mejor cuando teníamos una política de usar siempre solo un nombre para cada cosa en la base de códigos. Si el nombre cambia más tarde, permanecemos con el nombre anterior en el código o migramos todas las instancias del nombre anterior al nuevo. Lo importante es nunca comenzar a usar el nuevo nombre en el código a less que todas las instancias del nombre antiguo hayan sido migradas. De esa manera, solo tendrá que conservar 2 nombres para algo en su cabeza: el "nombre antiguo", utilizado en el código, y el nombre que todos los demás usan.

También a menudo hemos elegido un nombre muy genérico / descriptivo para las cosas cuando comenzamos si sabemos que la "marca" probablemente cambie.

Considero que renombrar las convenciones de nomenclatura mejoradas es solo otra forma de refactorización. Cree una twig, realice cambios de nombre, ejecute testings de unidad / integración, confirme, fusione, repita. Se trata de control de processs para mantener la consistencia en el proyecto.

La solución al desastre es no crearlo en primer lugar. Una vez que se nombra una ruta de código, rara vez hay una buena razón para cambiarla y nunca una buena razón para usar un nombre nuevo junto con el anterior. Cuando "Exploder" se convierte en "Boom", tiene dos opciones: seguir usando Exploder exclusivamente, y nunca mencionar Boom en ningún lado, ni cambiar todas las instancias de Exploder a Boom y luego continuar usando Boom exclusivamente y nunca volver a mencionar Exploder.

Si usa tanto Exploder como Boom en la misma base de código, lo está haciendo mal.

Además, sé que usted aclaró que no está hablando de los nombres visibles para el usuario, pero si comienza a trabajar con sus propios nombres internos que son relevantes para lo que hace el código y completamente independientes de lo que el marketing desea llamar al producto / function, entonces esto es mucho less probable que se convierta en un problema. Si ya se está refiriendo a Exploder internamente como TNT, ¿qué diferencia hay si Exploder cambia a Boom?

¿Cómo manejas la localización? La misma cosa; mismo método.

Usamos un nombre interno y externo. Podría ser tan simple como una definición de variable estática como

public static final String EXPLODER = "Boom"; 

Y en el código siempre usará la reference a EXPLODER. Lo mismo para los nombres de las routes y cosas por el estilo – la encoding difícil de esos paths en diferentes lugares es un no-go de todos modos. Si algunos chicos comienzan a investigar cosas internas (como fonts JS o files ini o lo que sea), ¿a quién le importa si descubren a Exploder?

Solo use nombres internos e ignore los cambios en los nombres de marketing / oficiales: https://softwareengineering.stackexchange.com/a/208578/55472 .