Cuando se habla solo del espacio de desarrollo (es decir, excluyendo las aplicaciones y los requisitos del sistema operativo), realmente depende del tipo de proyecto (s) con el que se está tratando. Por ejemplo, los lenguajes compilados crean muchos archivos temporales que a su vez se vuelven a empaquetar en archivos más grandes. En mi entorno actual, actualmente estamos ejecutando aproximadamente 20 GB para el código fuente + los archivos de objetos compilados. Eso solo incluye la versión compilada DEBUG, también sería más para RELEASE compilado.
No olvide la sobrecarga del 20% que NTFS u otro sistema de archivos de registro en diario (suponiendo que Windows aquí) necesita tener espacio para el registro en diario y mantener el disco duro en buen estado. Tendrá que dimensionar el disco duro que necesita .
Al proyectar las necesidades de disco duro de su proyecto, deberá tener en cuenta los siguientes aspectos:
- ¿Qué activos son los productos finales? Los elementos de esta clase incluyen elementos de arte, imágenes, archivos de sonido, etc. que no se combinan en otro archivo. En una aplicación web, esto también incluye sus archivos CSS y JavaScript. No olvide sus scripts de compilación y otros elementos que no están compilados.
- ¿Qué activos generan resultados intermedios? Los elementos de esta clase incluyen el código fuente para los idiomas compilados, los archivos de enlace, etc. Al comienzo del proyecto, tendrá que proyectar qué tan grande espera que lleguen y revisar esas estimaciones al menos dos veces más a medida que avanza el proyecto. .
- ¿Qué tan grandes son los productos finales? Sus archivos DLL o bibliotecas compartidas también ocupan espacio. Lo mismo que si empaquetara su aplicación web en una unidad fácilmente desplegable (similar a un archivo WAR de Java o un archivo EAR).
Para una estimación aproximada de cuán grande es su estimación final, use la siguiente fórmula:
(2 * _static_) + (2 * _intermediate_) + (2 * _final_) * 1.2
Si estás pensando para ti mismo, ¿cómo puede ser eso? Considera lo siguiente:
- El proceso de compilación copia archivos estáticos en el directorio de compilación, así como las clases compiladas.
- La etapa de vinculación y empaquetado creará binarios finales que serán más pequeños que los archivos intermedios combinados y los archivos estáticos en el directorio de compilación, pero no borrará esos archivos a medida que se combinan.
- El producto final es solo marginalmente más pequeño ya que los binarios no pueden comprimirse muy bien, pero puede eliminar la redundancia.
- Debe tener en cuenta el espacio temporal para permitir que el compilador funcione. Para eso es el espacio extra asignado en el producto final.
- Por último, debe asegurarse de que el entorno de desarrollo tenga un respiro para que el sistema operativo pueda mantener la unidad feliz. Para eso es el aumento del 20% al final.
Si está al comienzo de un proyecto, haga que sus desarrolladores proporcionen un SWAG (Seriously Wild A ** Guess) sobre cuántas clases se necesitarían para implementar la función. Multiplique eso por 16 KB. Algunas clases generarán archivos de objetos mucho más pequeños, y otras generarán archivos más grandes. Pero esto debería ser suficiente para su estimación SWAG de espacio en disco. También suponga que sus productos finales tendrán el mismo tamaño que las clases que calculó.
Supongo que su empleador desea establecer cuotas para cada perfil de usuario. Espero sinceramente que no estén entreteniendo perfiles móviles con el entorno de desarrollo. El problema con los perfiles móviles es el volumen de corte de los archivos que deben transferirse. El sistema operativo Windows (y el protocolo Samba) son notoriamente ineficientes para transferir grandes cantidades de archivos. Se necesitará un orden de magnitud más largo para transferir 100 archivos de 1k que 1 archivo de 100k.
Esperemos que esto le brinde suficiente información para negociar con su empleador.