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

Ответ 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
...