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

Question

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

 |
 |_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) хранят свои текущие выпуски. В каталоге проекта хранятся не связанные с кодом элементы проекта.

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

|
|___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

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

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

Answer 4

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

• PROJ_NAME
  • код
    • 1008 * ЦСИ *
    • тест
    • 1012 * сборка *
  • дизайн
  • документ
  • инструменты

Answer 5

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

• Тесты \

  • test_a <- проверка модуля для исследования и разработки (использует некоторые коды из папки src) </p>

  • test_b <- проверка модуля для b для исследований и разработок (использует некоторые коды из папки src) </p>

  • ...

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

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

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

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

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

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

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

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

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

Answer 6

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

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

Тогда внутри этих папок у меня есть:

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

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

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

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

Answer 7

Файлы в 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
...

Answer 8

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

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

Answer 9

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