Cuando la embarras nombrando tus proyectos y haces checkin

Algunos podrían decir que soy maníaco del nombrado de los proyectos dentro de una solución de Visual Studio. Pero con el tiempo me he dado cuenta de que una mala solución de software comienza con una mala convención de nombrado. Los developers que llegan nuevos a la solución llegan perdidos y con unos nombres arbitrarios en los proyectos no saben ni por dónde empezar. Y lo que es peor, con ese ejemplo, siguen nombrando todo a las patadas.

Bueno; y cómo me obstino en nombrar los proyectos?

Pues me gusta mucho usar jerarquías, separadas por puntos.

Por ejemplo:

 Cliente.NombreProducto.NombreCapa.[NombreProyecto]

No mucho, no muy poco; diría yo.

Un ejemplo puntual:

 BancoWHB.Credihoy.Types

Aquí el cliente mío es BancoWHB. El producto se llama Credihoy. Y la capa que estoy trabajando es la de tipos transversales a la solución. Aquí vendrían las clases POCO, etc.

 BancoWHB.Credihoy.DataAccessLayer

Aquí podría hacer implementaciones del EF, u ORM de preferencia.

 BancoWHB.Credihoy.TestClients.Core

Obviamente la funcionalidad central del producto

 BancoWHB.Credihoy.TestClients.WindowsForms

 BancoWHB.Credihoy.TestClients.ConsoleApp

 BancoWHB.Credihoy.TestClients.Javascript

Estos tres pertenecen al conjunto de proyectos usados para hacer testing de los servicios ofrecidos

 BancoWHB.Credihoy.Cloud.TcpCommunicator

 BancoWHB.Credihoy.Cloud.CustomerWebFront

 BancoWHB.Credihoy.Cloud.InternalWebFront

Un worker role que recibe peticiones a través de TCP/IP y dos web roles con sitios para los clientes y para los empleados respectívamente. y así sucesivamente...

La gracia eso sí es que todo esto quede bien organizado dentro de una solución. Y sobre todo soportado por un manejador de código fuente; primera opción, el TFS online.

Así pues, entro a TFS Online desde el web y me creo un Team Project llamado BancoWHB si es que quiero trabajar varios proyectos con ese cliente, o, uno que se llame BancoWHB.Credihoy, si sé que solo estaré trabajando con ellos ese proyecto puntual.

Luego de esto le doy abrir en Visual Studio y la solución vacía llamada BancoWHB.Credihoy queda abierta. Y sobre ella comienzo a agregar proyectos, nombrándolos como describí anteriormente.

Si por otro lado, arrancamos con una solución creada localmente, y luego ésta se asigna a un proyecto en TFS, lo que recomiendo es que antes de crear cualquier proyecto, se cree una solución vacía que en este caso tendría el nombre BancoWHB.Credihoy y luego a ella se le comiencen a agregar los proyectos.

El template de solución vacía se encuentra aquí:

Supongamos ahora que voy a hacer el proyecto que puse como ejemplo:

 BancoWHB.Credihoy.Cloud.TcpCommunicator

Aquí hay algo especial. Y es que un worker o un web role implican dos proyectos. El proyecto del role como tal y el proyecto de lo que contiene el role por dentro. El role es solo un contenedor que tiene opciones de configuración. Pero lo que se ejecuta va en otro tipo de proyecto que para un worker role es una Class Library y para un WebRole es un website. Lo que pasa es que cuando usamos el wizard de creación de proyectos, no vemos que esto sucede, porque todo queda integrado.

Hace tiempo no desarrollaba sobre un Worker Role de Azure. Últimamente solo había hecho cosas con Web Apps y otros servicios modernos. Así que ya había olvidado un pequeño detalle con el nombrado de los worker y web roles.

Así que al principio no recordaba el hecho que les mencioné y creé el siguiente proyecto Cloud:

Al darle ok, me sale el diálogo para agregar roles a este proyecto

Pero el resultado fue este:

Obviamente, aquí el error que cometí fue no escribir todo el nombre para el WorkerRole. Así que esto es completamente necesario.

A primera vista, esto no es una gran complicación. Solo basta con pararse sobre el proyecto, darle F2, renombrar y tal vez entrar a las propiedades del proyecto para cambiar el namespace por defecto del proyecto. Pero si por ejemplo le hubiésemos dado checkin a este error de naming y luego hacemos checkin y descargamos (GLV) la solución con el nombre de proyecto cambiado desde otra máquina, vamos a comenzar a tener un montón de errores incómodos bastante incómodos de solucionar.

Una recomendación para solucionar esto de manera que aún el repositorio de código en TFS quede bien organizado, es:

1. Verificar que nadie esté trabajando en los proyectos que están mal nombrados. Todos los cambios deben estar commited.
2. Copiar el código que ya se haya hecho en una ubicación segura.
3. Remover los proyectos implicados de la solución.
4. Ejecutar un checkin de la solución ya con los proyectos removidos.
5. Eliminar las carpetas generadas por los proyectos que quedaron mal nombrados.
6. Crear de nuevo los proyectos ahora sí con el nombre correcto.
7. Recuperar el código que ya se había creado antes dentro de los proyectos que estaban mal nombrados.
8. Verificar que todo compila y funciona bien y,
9. Hacer checkin nuevamente.

Cuando se haga Get Latest Version de la solución nuevamente en otra máquina, ya todo bajará correctamente.

Comments

• Anonymous
  August 10, 2016
  Muy bueno, solo que yo aplico todos los nombres y métodos propios en Español
  • Anonymous
    January 19, 2017
    Gracias por el feedback!