Neste post vou falar como eu costumo organizar os arquivos-fonte de meus projetos. A divisao que eu uso obviamente nao e a unica adequada e nem a melhor, mas tem funcionado relativamente bem. As caracteristicas que foram buscadas nesta formatacao sao:Facilidade de localizacao do material.Formato estruturado e hierarquico.Manter todo o material de entrada necessario para o trabalho versionado e baixavel com um comando unico.Possibilidade de usar integracao continua e builds CRISP. Vamos entao a estrutura.project-x code build output (nao guardado no sistema de versionamento) internalDocs TestPlans skels thirdparty bin dll include lib userDeliverables part1 part2 installers userDocs continuous-integration thirdparty-originalsNo primeiro nivel, temos a divisao em code, continuous-integration e thirdparty-originals. Code vai conter o grosso do trabalho, e sera descrito por ultimo. Em thirdparty-originals, coloco todos os arquivos de pecas de software de terceiros que serao usados no projeto. Importante: eu os coloco do jeito que eles vem do terceiro, sem nenhum processamento. Todo o processamento que estes arquivos requeiram eu faco atraves de scripts para garantir a repetibilidade do processo e facilitar no caso de upgrade de uma peca. Os scripts de processamento criados para isto vao ficar em um lugar abaixo do dir code, que sera descrito mais para a frente.Em continuous-integration, coloco os arquivos usados para fazer integracao continua do projeto. Por exemplo, se vai ser usado cruise-control, aqui ficarao um cruise-control-config.xml e um delegating.xml. O diretorio code esta organizado do modo abaixo descrito:No diretorio build, coloco os scripts de build que permitem buildar o sistema em linha de comando. Sempre procuro ter um script que permita, rodando um unico comando, gerar o pacote pronto para envio para clientes. Gosto que este script crie um sub-dir chamado output e coloque seus produtos ali. Notem que este script de build master deve gerar inclusive a documentacao de produto e empacota-la do jeito necessario para a entrega (zip contendo os documentos e o instalador, por exemplo).No diretorio internalDocs coloco a documentacao de projeto. Por exemplo, diagramas de projeto, instrucoes de trabalho para programadores, user stories, planos de teste, etc. Vou usando sub-dirs para agrupar coisas relacionadas. Por exemplo, se tenho mais de um plano de teste, crio um sub-dir chamado testPlans, se tenho varios arquivos de user stories, crio um chamado userStories.Em skels, coloco os arquivos de esqueleto que serao usados no projeto. E interessante que a maioria das pessoas que conheco guardam os esqueletos no armario (ok, normalmente e na pasta da qualidade ou no diretorio de politicas da empresa) e nao junto de onde eles sao usados e, guardando no armario, nao dao oportunidade de customizacao por projeto e muita gente acaba nao usando-os por estarem longe. Eu gosto de meus esqueletos evoluindo, versionados e sempre a mao para serem usados de modo efetivo. A proposito, esqueletos sao aqueles arquivos modelo que ajudam a ter uma homogeneidade visual no codigo e tambem ajudam a gente a se lembrar de detalhes como esconder o copy ctor de classes. Se voce quer uns exemplos de esqueletos, de uma olhada aqui. Em thirdparty ficam os arquivos de pecas de software de terceiros, cujos