Ao falar apenas sobre o espaço de desenvolvimento (por exemplo, excluindo aplicativos e requisitos de SO), isso realmente depende do tipo de projeto com o qual você está lidando. Por exemplo, idiomas compilados criam muitos arquivos temporários que são reembalados em arquivos maiores. No meu ambiente atual, atualmente estamos executando cerca de 20 GB para o código fonte + os arquivos de objeto compilados. Isso inclui apenas a versão compilada DEBUG, seria mais para o RELEASE compilado também.
Não se esqueça dos 20% de sobrecarga que o NTFS ou outro sistema de arquivos de registro em diário (assumindo o Windows aqui) precisa ter espaço para registrar em diário e manter o disco rígido em bom estado. Você terá que dimensionar o disco rígido necessário .
Ao projetar as necessidades de disco rígido do seu projeto, você deverá considerar os seguintes aspectos:
- Quais ativos são produtos finais? Os itens desta classe incluem materiais de arte, imagens, arquivos de som etc. que não são combinados em outro arquivo. Em um aplicativo da web, isso inclui também os arquivos CSS e JavaScript. Não esqueça seus scripts de construção e outros itens que não são compilados.
- Quais ativos geram resultados intermediários? Os itens desta classe incluem código-fonte para idiomas compilados, arquivos de link etc. No início do projeto, você terá que projetar o tamanho que espera obter e revisar essas estimativas pelo menos duas vezes mais à medida que o projeto avança. .
- Qual o tamanho dos produtos finais? Suas DLLs ou bibliotecas compartilhadas também ocupam espaço. O mesmo que se você empacotasse seu aplicativo da web em uma unidade facilmente implementável (semelhante a um arquivo Java WAR ou EAR).
Para uma estimativa aproximada do tamanho da sua estimativa final, use a seguinte fórmula:
(2 * _static_) + (2 * _intermediate_) + (2 * _final_) * 1.2
Se você está pensando consigo mesmo, como pode ser isso? Considere o seguinte:
- O processo de compilação copia arquivos estáticos para o diretório de compilação, bem como as classes compiladas.
- O estágio de vinculação e empacotamento criará binários finais que serão menores que os arquivos intermediários combinados e os arquivos estáticos no diretório de construção, mas não os apagarão à medida que forem combinados.
- O produto final é apenas um pouco menor, pois os binários não podem ser compactados muito bem - mas você pode remover a redundância.
- Você precisa levar em consideração o espaço temporário para permitir que o compilador funcione. É para isso que serve o espaço extra alocado no produto final.
- Por fim, você precisa garantir que o ambiente de desenvolvimento tenha espaço para respirar, para que o sistema operacional possa manter a unidade feliz. É para isso que serve o aumento de 20% no final.
Se você estiver no início de um projeto, peça aos desenvolvedores que forneçam um SWAG (Seriously Wild A ** Guess) sobre quantas classes seriam necessárias para implementar o recurso. Multiplique isso por 16 KB. Algumas classes geram arquivos de objeto muito menores e outras geram arquivos maiores. Mas isso deve ser suficiente para sua estimativa do SWAG de espaço em disco. Suponha também que seus produtos finais terão o mesmo tamanho das classes estimadas.
Presumo que seu empregador esteja querendo configurar cotas para cada perfil de usuário. Eu sinceramente espero que eles não estejam entretendo perfis de roaming com o ambiente de desenvolvimento. O problema com os perfis móveis é o volume de cisalhamento dos arquivos que precisam ser transferidos. O sistema operacional Windows (e o protocolo Samba) é notoriamente ineficiente na transferência de um grande número de arquivos. Levará uma ordem de magnitude mais longa para transferir 100 arquivos de 1k do que 1 arquivo de 100k.
Espero que isso lhe dê informações suficientes para negociar com seu empregador.