Los proyectos de arquitectura suelen desarrollarse en periodos largos de tiempo y generan un gran número de archivos y directorios. Si no hemos sido rigurosos y ordenados, la tarea aparentemente trivial de recuperar un plano concreto desarrollado hace unos meses o unos años (una situación bastante cotidiana en la profesión) puede convertirse en una auténtica odisea que puede desembocar en graves errores.
Mantener un orden de archivos y seguir un patrón al darles nombre que nos permita saber en todo momento y de manera rápida qué es lo que contienen cobran una importancia vial.
Este artículo se centrará en dar unos criterios para crear un código propio para nombrar los archivos de manera eficiente que nos permita saber el tipo de información que contiene, su versión, el proyecto al que pertenecen...
Versiones anteriores
Soy partidario de no eliminar archivos antiguos, ya que el proceso proyectual a veces nos obliga a volver a soluciones que anteriormente habíamos desechado pero que por algún motivo vuelven a tener validez, eso origina un gran número de archivos y ponerles un nombre adecuado para identificar cual es la versión válida con la que deberemos trabajar puede ser complicado. Un sistema sencillo para identificarlos es añadir un número al archivo que nos permita identificar su número de versión. Sin embargo antes de aplicar este método tan sencillo en apariencia cabría hacer algunas consideraciones: ¿lo añadimos como prefijo o como sufijo? ¿la última versión será siempre la de número más alto? ¿cuantas versiones podemos tener de un mismo archivo?
Por defecto, los sistemas operativos suelen ordenar sus archivos alfabéticamente, lo que puede hacer desaconsejable añadir un prefijo que determine el número de versión al nombre de archivo: si tenemos tres archivos (A, B y C) y cada uno tiene un par de versiones (1-A, 2-A, 1-B, 2-B, 1-C, 2-C) al ordenarse alfabéticamente el orden sería este: 1-A, 1-B, 1-C, 2-A, 2-B, 2-C... y así sucesivamente. Los archivos se mezclarían y estarían ordenados por el número de versión.
La tendencia habitual es la de ir añadiendo números a la última versión y cuanto más elevados sean será sinónimo de tener una versión más actual. Esto conlleva un problema cuando se trabaja con archivos vinculados o referenciados: al añadir un sufijo, el nombre del archivo cambia, y por lo tanto el vínculo se pierde o no se actualiza. Cambiar el vínculo no suele suponer mucho engorro pero es algo que no se debería hacer más que una sola vez (esa es la filosofía de los archivos vinculados al fin y al cabo). Una buena opción para evitar ese problema es que la última versión sea siempre la única que no tiene sufijo, y las copias serán las que se numeren. Cuanto mayor sea el número, quiere decir que la copia es más actual.
Otro sistema podría ser añadir una fecha al archivo, si bien esta información es redundante por estar en las propiedades de cada archivo, es mucho más fácil y rápida de leer. Pueden aplicarse las mismas reflexiones hechas anteriormente.
Nombre del proyecto
Una opción interesante que puede facilitarnos el nombre de archivo es la de informar acerca del proyecto al que pertenecen. Esta información puede parecer algo redundante, pues los archivos suelen estar emplazados en un directorio que contiene esa misma información, sin embargo la experiencia dice que a veces los archivos no están en el sitio donde deberían estar (máxime si intercambiamos varios emails con nuestros colaboradores). Si a los proyectos les añadimos un código y a cada archivo le dotamos de ese código, será evidente si un archivo está fuera de su localización y será muy fácil moverlo al lugar correcto.
Información del contenido
Este es quizá el aspecto más evidente del nombre de un archivo, pero no por ello menos importante: el archivo debe informarnos de qué tipo de información contiene sin que sea necesario abrirlo para ver si se trata de una memoria, un presupuesto, un plano de instalaciones o un render. Una breve descripción bastará para satisfacer este propósito, sin embargo hay que tener en cuenta que aunque los sistemas operativos actuales permiten escribir nombres de muchos caracteres no hay que abusar de ello. No hay que olvidar que lo que estamos intentando es leer en el menor tiempo posible la mayor cantidad de información posible. Además, se da el caso de que algunos programas no admiten nombres más largos de 21 caracteres + la extensión: si usamos nombres cortos nos ahorraremos problemas de incompatibilidades.
Otro método puede ser establecer un código de letras; puede que al principio sea engorroso y su lectura no sea tan inmediata, pero con el tiempo este sistema puede ser tremendamente eficaz a la vez que rápido.
Otros datos
Algunas personas opinarán que además de todo lo expuesto anteriormente, el nombre de un archivo también debería dar información sobre si se trata de un archivo de arquitectura, ingeniería, urbanización... o de la fase de proyecto en la que se encuentran (estudios previos, proyecto básico, proyecto ejecutivo...), por dar algunos ejemplos.
Consideraciones generales
Llegados a este punto, un error habitual suele ser el de idear un código que trate de dar solución a todos los temas que aquí se han planteado e incluso otros nuevos, lo cual suele ser contraproducente pues resultan en nombres de archivo muy complicados, largos y difíciles de leer. El método utilizado lejos de ser un sistema rígido e inmutable debe de ser lo suficientemente flexible como para permitir mejoras en el tiempo, y para ello será imprescindible hacer un análisis exhaustivo de la realidad de cada uno que permita diseñar un sistema que satisfaga nuestras necesidades tanto presentes como las que preveamos que pueden ocurrir en un futuro no lejano y deseado.
Nombrar los archivos es algo muy personal y no existen fórmulas magistrales: el sistema que nos funciona de maravilla puede no servirle para nada a otro despacho de arquitectura. La experiencia, propia o ajena (este artículo es un ejemplo de ello), será de gran ayuda en estos casos.
Autor: Carlos Cámara Menoyo
Fecha: 14/01/2007
Permalink: ver enlace original
Contexto: A raiz de una consulta en el foro de +arquitectura decidí poner por escrito las reflexiones a las que había llegado respecto este tema durante mi experiencia laboral.
Comentarios
Victor
Mar, 16/01/2007 - 18:42
Enlace permanente
sobre la fecha y su
sobre la fecha y su redundancia me gustaría comentar dos cosas.
yo utilizo el sistema estadounidense (poner el mes antes que el día) ya que soluciona uno de los problemas que comentas, el orden alfabético.
En España sería...
Archivo 03.12.2006
Archivo 04.11.2006
Archivo 05.09.2006
es decir, sin u norden real y rápido para encontrar los archivos.
El otro sistema sería:
Archivo 2007.09.05
Archivo 2007.11.04
Archivo 2007.12.03
la parte de la redundancia que comentas es cierto en casi todos los casos. ahora bien, acostumbrados a hacer backups, copias de copias, retocar una pequeña cosa etcétera... puede hacer perder la fecha de creación del archivo que a veces puede resultar bastante útil.
Saludos,
Víctor
Fotocasa.es
MiTH
Mar, 16/01/2007 - 23:27
Enlace permanente
Yo el método que utilizo para
Yo el método que utilizo para nombrar los archivos es bastante ajustado a los comentarios que se han realizado.
El archivo principal no tiene subfijos de versión para no tener que andar "revinculando" otros archivos. Añado un código inicial correspondiente al proyecto y añado un texto corto para indicar el contenido del archivo. A veces marco si son planos de estructura, instalaciones, etc con un pequeño código antes de la descripción del archivo.
Un saludo
edgargonzalez.c...
Sáb, 27/01/2007 - 08:38
Enlace permanente
[...] PD: Antes de acabar
[...] PD: Antes de acabar perdiendo los DWG´s en vuestro disco duro, podéis probar a ser ordenados como este chico, que parece mucho más útil y efectivo… [...]
Carlos Cámara Menoyo
Dom, 11/02/2007 - 07:52
Enlace permanente
Perdonad la demora en
Perdonad la demora en contestar. Gracias a los que habéis añadido algún comentario al artículo o habéis hecho referencia a él en vuestros blogs respectivos.
Mith: me alegra leer que hayamos llegado a conclusiones similares por caminos distintos. Será buena señal, ¿verdad?
Victor: tienes razón en lo que comentas de que las copias de seguridad pueden hacer que se pierda la fecha. Personalmente no suelo usar demasiado el formato de fecha, porque no me suele interesar cuando se hizo, sino si se hizo antes o después de tal o cual archivo. Las veces que tengo que poner fechas a los archivos lo hago siempre como tú comentas: año/mes/día para que todo quede bien ordenado.
Espero que sea de utilidad el artículo.
Carlos Cámara M...
Vie, 03/08/2007 - 21:28
Enlace permanente
[...] los problemas más
[...] los problemas más habituales de trabajar con varias personas en un mismo proyecto (además del de reconocer los ficheros) es que finalmente el archivo puede tener tantas capas, tipos de texto, acotaciones, colores, etc. [...]
Carlos Cámara M...
Jue, 08/01/2009 - 03:55
Enlace permanente
[...] llegando a dificultar
[...] llegando a dificultar enormemente la tarea de encontrar el archivo y la versión que necesitamos (1) para trabajar o imprimir. El problema crece exponencialmente cuanto más complejo es el proyecto o [...]
Del CAD al BIM ...
Vie, 09/01/2009 - 22:11
Enlace permanente
[...] llegando a dificultar
[...] llegando a dificultar enormemente la tarea de encontrar el archivo y la versión que necesitamos (1) para trabajar o imprimir. El problema crece exponencialmente cuanto más complejo es el proyecto o [...]
Marti
Jue, 14/05/2009 - 14:17
Enlace permanente
Pues yo debo decir que la
Pues yo debo decir que la idea de añadir prefijos o sufijos me parece nefasta. Los dibujos puede que esten referenciados en multiples hojas de impresion (hablo de archivos CAD) y la modificacion de su nombre de archivo nos obligaria consecuentemente a rerutear los archivos de referencia.
Yo personalmente copio los dibujos de versiones antiguas en una carpeta llamada "Archivo" o "Viejo", de manera que todos los dibujos deben mantner SIEMPRE su nombre inicial para que no se pierdan las referencias.
EN entornos multiusuario el renombrar archivos tiene otra desventaja. Mientras tu trbajas en Archivo 2009-02-02, puede que yo sin saberlo haya creado Archivo 2009-02-03 basado en una version anterior, al intentar averiguar que archivo es el bueno, probablemente acbaremos perdiendo infomacion y sobretodo tiempo...
Bueno ahi esta mi miga de pan
Carlos Cámara
Sáb, 16/05/2009 - 19:34
Enlace permanente
Hola Marti! Muchas gracias
Hola Marti!
Muchas gracias por el comentario, que por otra parte comparto en parte contigo por el problema con las rutas de las referencias externas (precisamente en el artículo original apuntaba ese mismo problema y comentaba que sería bueno solo renombrar las versiones, dejando la última versión con el nombre intacto). Lo que planteas de moverlo a una carpeta está muy bien, pero creo que no debería limitarse solo a eso, ya que debería haber alguna manera de distinguir el orden de la copia de seguridad y de distinguir la última versión de una copia más allá de la carpeta donde esté. Imaginemos dos casos:
A) soy un colaborador que no ha trabajado en el proyecto y tengo que hacerlo por primera vez. Como no se cual es la última versión ni dónde está guardada le doy a abrir archivos recientes porque se que mi compañero ha estado trabajando en ello. Pero como la ruta es muy larga, solo se muestra el final de ella, por tanto se muestran dos instancias que aparentemente son iguales pero solo cambia la ruta de la carpeta (la copia está en la carpeta "archivo"), por lo tanto tengo un 50% de posibilidades de equivocarme y trabajar en la versión incorrecta.
B)Quiero recuperar una versión concreta, pero como no la renombré, al moverla a la carpeta "archivo" he sobreescrito la versión anterior (en realidad solo hay una versión de copia) y por tanto es imposible hacer lo que quiero.
Por último me gustaría añador que hace ya bastante desde que escribí el artículo original. En este tiempo he ido metiéndome más en el mundo de desarrollo de aplicaciones web y he descubierto un concepto muy interesante y ligado en cierta manera al open-source que usan los programadores: el CVS o sistema de control de versiones. Todavía no he podido investigar a fondo con él, pero está claro que la solución podría venir por allí, ya que es lo que se utiliza en proyectos de programación desde pequeños hasta enormes en los que colabora un gran número de gente y es, por lo tanto, imprescindible poder restaurar versiones concretas.
Saludos
Marce
Jue, 17/09/2009 - 03:23
Enlace permanente
Hola Carlos, agradezco tu
Hola Carlos,
agradezco tu aporte fue muy valioso para mí, quiero instaurar un procedimiento de nombre de archivos ya que trabajo en una empresa informática donde se maneja mucha informacion en el transcurso de un proyecto y muchas veces no la suelen encontrar rápidamente, por tanto tus consejos me dan una luz de como pudiera conseguirlo, aunque el manejo de versiones lo tienen super claro.
Carlos Cámara
Jue, 17/09/2009 - 10:02
Enlace permanente
Hola Marce, Me alegra leer
Hola Marce,
Me alegra leer que te ha servido de algo. Comentas que en tu empresa tienen muy claro el tema de las versiones, ¿podrías contarnos cómo lo hacen? Así podríamos aprender mucho, porque lo que yo comento no es para nada la solución a todos los problemas...
Saludos
Pol Maresma
Mié, 28/09/2011 - 15:01
Enlace permanente
Control de versiones
Cualquier sistema manual tiende a generar errores. Aunque todo puede fallar, un sistema de control de versiones CVS es imprescindible a mi entender. En su defecto herramientas cómo Dropbox nos permiten tenen un repositorio de versiones sin que debamos configurar nada, además de sincronización entre ordenadores y copias de seguridad.
carlos
Mié, 28/09/2011 - 15:33
Enlace permanente
CSV, GIT, Dropbox... en arquitectura
Muchas gracias por tu aportación, Pol.
Ciertamente todo lo que sea automatizar tareas cotidianas ayuda a minimizar los errores, y el uso de un sistema de control de versiones puede ayudar a ello. Sin embargo, los sistemas como CVS solo solucionan una parte del problema, como su nombre indica: saber cual es la última versión de un archivo y tener copias de versiones anteriores. Así pues, todo aquello que tenga que ver con el orden (saber dónde poner un archivo, saber si un archivo está donde tiene que estar, saber si la memoria que queremos abrir pertenece a un proyecto u otro... ) no lo va a poder resolver. Para ello podríamos usar un gestor documental, utilizar metadatos en los archivos (en aquellos formatos que lo admitan, que no son todos)... que servirían para ayudar en el orden, pero en cualquier caso no solucionarían al 100% toda la problemática y obligan a ciertas tareas manuales. Y es que a fin de cuentas cuando ordenamos estamos decidiendo, y esas decisiones no las puede tomar otro o una máquina, tenemos que tomarlas nosotros.
Con dropbox ocurre más o menos lo mismo: solucionamos el tema de control de versiones y la sincronización de archivos, pero una vez más no se soluciona el orden, y menos cuando queremos compartir carpetas con terceros (¡es un horror! la lógica de un tercero no es la lógica que nosotros tendríamos, y se mezcla todo). De ahí que estuviese hablando de orden y de criterios en este artículo. Un artículo que por otra parte no pretende sentar cátedra sino que se trata de un compendio de experiencias propias y ajenas a las que he tenido acceso durante mi experiencia profesional.
Dicho esto me gustaría añadir que me encantaría poder integrar un sistema tipo CVS o, incluso mejor, Git en el ámbito de los estudios de arquitectura, pero me temo que estos sistemas funcionan bien para un tipo de profesiones que utilicen un tipo de archivos (básicamente programadores) y no tanto para otros formatos de archivo como son los de CAD, BIM... ¡y a pesar de todo es lo que necesitamos! ¿Cómo lo ves tú? ¿cual es tu experiencia? ¿Crees que pueden adaptarse estos sistemas a cualquier tipo de archivo/programa? ¿Cómo?
Soluciones intermedias serían utilizar herramientas como sparkleshare o owncloud en un servidor propio y parece que BIMserver va hacia este sentido dentro del campo del BIM.
Pol Maresma
Mié, 28/09/2011 - 16:48
Enlace permanente
CVS
Tienes razón, cuando no se trabaja en un sistema de ficheros prefijado como sería un CMS, Framework de programación u otros, cada uno debe crearse su orden particular.
Sería interesante un sistema tipo GIT/CVS que guardase información de cambios entre archivos pero para eso seria imprescindible que los formatos fueran abierto, o bien que lo desarrolle el propio fabricante.
Otro añadido interesante sería algo similar a los patches que en programación permiten realizar modificaciones o añadidos a un archivo, aunque supongo que los programas de CAD ya deben tener importación / exportación de partes del proyecto.
Salut, salud.
carlos
Mié, 28/09/2011 - 16:58
Enlace permanente
Un motivo más para usar formatos abiertos
Hola Pol,
Apuntas algo muy importante en tu comentario: la importancia de usar estándares abiertos para poder implantar sistemas como CVS, GIT... de lo contrario deberán ser las empresas desarrolladoras quienes lo hagan y difícilmente optarán por usar un sistema abierto de control de versiones, sino que realizarán uno propio.
Y es cierto que en frameworks, CMS o incluso GNU/Linux te enseña a ser ordenado, ya que todo tiene una lógica (que está bien documentada) y si no está donde tiene que estar y no se llama como se tiene que llamar, no funciona.
Muchas gracias por tus aportaciones!
PD: ojalá los programas de CAD tuviesen bien resuelto el tema de importar/exportar partes del proyecto. Desafortunadamente son muy pocos los que están preparados para el trabajo colaborativo.
Añadir nuevo comentario