Какова структура вашего каталога разработки программного обеспечения?

Я экспериментировал с структурами каталогов и в настоящее время использую ниже:

 |
 |_projects__
 |           |
 |           |_blog.com_
 |           |          |_mockups
 |           |          |_user stories
 |           |          |_....
 |           |
 |           |_noteapp__
 |                      |_mockups
 |                      |_....
 |
 |_webs______
 |           |
 |           |_dev______
 |           |          |_blog.com_
 |           |                     |_app
 |           |                     |_config
 |           |                     |_....
 |           |
 |           |_prod_____
 |           |          |_blog.com_
 |           |                     |_app
 |           |                     |_....
 |           |_qe_....
 |           |_uat_....
 |
 |
 |_desktops__
             |
             |_dev______
             |          |_noteapp_
             |                    |_app
             |                    |_config
             |                    |_....
             |
             |_prod...
             |_qe....
             |_uat....

                                                 KEY
                                                 dev  - development
                                                 prod - production
                                                 qe   - quality engineering
                                                 uat  - user acceptance testing

Веб-магазины хранят веб-приложения, настольные компьютеры хранят настольные приложения. Каталог dev управляется версиями, в то время как другие каталоги (prod, qe, uat) хранят свои текущие выпуски. Каталог проектов хранит элементы проекта, не связанные с кодом.

Какова структура каталогов разработки программного обеспечения и есть ли причина, по которой вы рекомендуете эту структуру?

ОТВЕТЫ

Ответ 1

Я делаю следующее:

  • Проекты
    • Проект 1
      • Дизайн
      • Docs
      • Код
    • Проект n
      • Дизайн
      • Docs
      • Код
    • Неактивно
      • Проект 1
        • Дизайн
        • Docs
        • Код
      • Проект n
        • Дизайн
        • Docs
        • Код

По какой-то причине он помогает мне сохранить все файлы, сгруппированные по проекту, и сохранить мои неактивные проекты (те, на которых я сейчас не работаю) в следующей папке внизу. Наверное, я отвлекаюсь на них в противном случае.

Ответ 2

Я большой поклонник ваших более гранулированных листьев, но на верхнем уровне я намного лучше использую файловую систему, организованную проектом. Я, скорее всего, буду в кодовой директории и подумаю: "Эй, какова была спецификация для этого?" чем быть в справочнике спецификаций и подумать: "В каком проекте я хотел получить спецификацию?" Чтобы изменить диаграмму:

|
|___webs____
|           |
|           |_blog.com_
|           |          |
|           |          |_docs_
|           |          |      |
|           |          |      |_mockups
|           |          |      |_user stories
|           |          |      |_...
|           |          |
|           |          |_code_
|           |          |      |
|           |          |      |_dev_
|           |          |      |     |
|           |          |      |     |_app
|           |          |      |     |_cfg
|           |          |      |     |_...
|           |          |      |
|           |          |      |_prod_ 
|           |          |      |_qa_
|           |          |      |_uat_
|           |
|           |_blah.com_
|           |          |
|           |          |_...
|
|_desktop___
|           |
|           |_noteapp__
|           |          |
|           |          |_...
|           |_...


                                                KEY
                                                dev  - development
                                                prod - production
                                                qe   - quality engineering
                                                uat  - user acceptance testing

Тем не менее, организация в моем офисе следует вашим методам и, похоже, поддерживает довольно большую среду разработки. Лично мне очень сложно искать макеты и другие случаи в каталогах, отличных от того, в котором работает мой проект (в частности, как аналитик, имеющий спецификации отдельно от моделей маркетинга, но я отвлекаюсь), но из процесса - точка зрения делегации, разделяющая эти концепции, вероятно, имеет большой смысл.

Только мои два цента.

Ответ 3

Я храню все в каталоге "c:\projects" на моей машине Windows и ~/проектах в наших средах unix-oid (linux и solaris). Ниже, что у меня есть "обучение" (для экспериментов кода и фрагментов/каталог), а затем один каталог для каждого проекта. Через некоторое время, когда проект не работает, я удаляю локальное хранилище, и код архивируется только в SVN.

Ответ 4

  • src\< - Исходные коды для нескольких проектов (ниже)

  • Тесты\

    • test_a < - модуль test для a для r & d (использует некоторые коды из папки src)

    • test_b - тест модуля для b для r & d (использует некоторые коды из папки src)

    • ...

  • main_app_folder < - Основной файл проекта для производства (использует большинство кодов из папки src)

  • doc\< - Документы

  • инструменты\

    • tool_a < - tool a (использует некоторые коды из папки src)

    • tool_b < - tool b (использует некоторые коды из папки src)

  • cleanup.exe/.ini < - утилита для очистки временных файлов сборки.

Проект (в main_app_folder, тесты или инструменты) может быть .vcproj(visual studio c/С++),.mmp(Symbian makefile), Makefile (linux makefile). Каждый проект имеет свой собственный .cpp файл - всегда содержащий минимальный набор функций, все остальное имеет тенденцию быть более или менее многоразовым (в src\папке).

Разница между тестовым приложением и инструментальным приложением заключается в том, что инструмент отображает что-то более или менее полезное, в то время как проверка только проверяет, работает оно или нет.

Разница между тестом и основным приложением заключается в том, что тестовое приложение не содержит целых функциональных возможностей, а также тестовое приложение может включить некоторые специальные #define, необходимые для тестирования. Обычно тестовое приложение уменьшает набор основных приложений без дополнительных #define.

Ответ 5

Я обычно использую эту структуру каталогов:

  • PROJ_NAME
    • код
      • ЦСИ
      • тест
      • построить
    • дизайн
    • документ
    • Инструменты

Ответ 6

Я склонен группировать все мои проекты в три основных каталога:

  • Webdesign = > для любого веб-сайта;
  • Программирование = > Для всего, что не связано с Интернетом (даже если оно имеет сетевые возможности);
  • Исследование = > Для чего угодно, где я должен читать документы, чтобы это сделать;

Затем внутри этих папок я:

  • Инкубатор = > Для новых проектов или проектов, которые я принимаю;
  • Выход на пенсию (или atic) = > Для проектов, которые неактивны;
  • n каталогов для каждого из моих активно разрабатываемых проектов;

Также каждый проект поддерживается в репозитории git с файлом doap, описывающим его (наряду с обычным материалом, например README, INSTALL, NEWS, AUTHORS, LICENSE (обычно apache2), docs dir и srcs dir и, возможно, каталог libs и файл сборки). Если какие-либо проекты подключены, то файл doap говорит об этом (или я просто создаю папку для корневого проекта и размещаю в нем все связанные проекты). Единственным исключением из этих двух абзацев выше, являются некоторые проекты в atic (некоторые из них написаны в Delphi 2...).

Кроме того, хранятся только источники, так как я могу быстро создавать из них двоичные файлы.

PS: Если это напоминает вам то, что вы знаете, это потому, что я вдохновил себя на разработку программного обеспечения Apache для организации своих проектов, поэтому у меня есть лаборатории (или исследования), atic, инкубатор, файлы doap, и т.д. Потому что в наши дни я в основном человек-джава, и пришла в голову мысль...

Ответ 7

Я предпочитаю более плоскую структуру каталогов и хотел бы рекомендовать держать ее как можно проще. Помните, что, по крайней мере, в Windowsland существует ограничение на длину командной строки. Таким образом, наличие очень глубоких структур может вызвать некоторые неприятные ошибки сборки.

Ответ 8

Я просто использую сокращенное имя для каждого проекта и бросаю все соответствующие файлы и каталоги в этот один каталог. Что-то вроде этого:

  • имя_проекта (название проекта, сокращенное название)
    • dir1/(На самом деле это не названо в действительности.)
    • dir2/
    • DIRN/
    • file1
    • file2
    • file3
    • fileN

Ответ 9

Файлы в svn:

SomeLibraryX
  SomeLibraryX.sln
  SomeFunctionA.cs
  SomeFunctionB.cs
  ..

SomeApplicationY
  SomeApplicationY.sln
  SomeApplicationY.cs          <-- might use SomeLibraryX as one of the dependencies

SomeApplicationZ
..

Файлы в некоторых общих \\intra-pc\Releases\

SomeApplicationY 1         <-- folder used to execute compiled binary. Contains all the necessary input files needed for execution.
  Model                    <-- all input files like xml:s and 3ds:s 
  Textures                 <-- all pictures 
  Depencies                <-- all dependency executables and dlls
  SomeApplicationY.exe     <-- main exe
  SomeApplicationY.ini     <-- execution parameters file, that can be drag&dropped onto main exe

SomeApplicationY 2
  Model 
  Textures
  Depencies
  SomeApplicationY.exe
  SomeApplicationY.ini

SomeApplicationY 3            <-- the last demo-release of this project that is currently under construction (used for executing and debugging the exe)

  Model 
  Textures
  Depencies
  SomeApplicationY.exe
  SomeApplicationY.ini

SomeApplicationZ 1
...