Рекомендации по организации различных веб-проектов (rails, asp.net, binaries и git repos) - PullRequest
0 голосов
/ 12 февраля 2011

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

За последние несколько лет я работал над многими проектами на многих платформах (классический asp, asp.net webforms, asp.net MVC, рельсы и т. д.).Большинство из них являются веб-сайтами, но некоторые нет.Эти проекты имеют не только исходный код, но также некоторые файлы фотошопа, текстовые документы, электронные таблицы и т. Д.

Мне также нравится клонировать интересные репозитории git, которые я найду на github.com, и загрузить исходный код с sourceforge.net.1005 *

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

/sourcecode
  /non_web_projects
  ...
  /websites 
    /classic_asp
      /project1/website  # the source code
      /project1/misc     # everything else
      /project2/website
      /project2/misc
      ...
    /asp_net
      /project1/website  
      /project1/misc     
      ...
    /asp_net_mvc
      /project1/website
      /project1/misc    
      ...
    /rails
      /project1/website  
      /project1/misc     
      ...
    /git_repos
    ...
    /source_forge
    ...

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

Ответы [ 3 ]

0 голосов
/ 12 февраля 2011

Все мои проекты организованы с использованием иерархии \ Projects \ Language \ SubProject, что-то вроде того, что у вас есть.Однако в этом соглашении есть подводные камни, поскольку иногда в проекте участвуют несколько компонентов, написанных на разных языках, и перемещение между языковыми папками становится проблемой.

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

0 голосов
/ 12 февраля 2011

Я храню все свои активные проекты, независимо от типа, непосредственно в ~ / Projects.Периодически я запускаю этот скрипт ruby ​​, который дает мне возможность либо архивировать, либо удалять старые проекты.Эта комбинация работает очень хорошо, чтобы держать меня в фокусе на происходящем.

На пределе, я буду держать проекты в разных местах, основываясь на том, для кого они предназначены и на каком компьютере я работаю.В моих личных системах я храню личные проекты в ~ / projects и проектах для других, таких как мой работодатель в ~ / client_name_here / projects.На своем рабочем компьютере я храню связанные с работой проекты в ~ / projects и все.

Для меня это все о навигации.Попасть в правильный каталог должно быть максимально безболезненно.Вот почему я держу все в стороне от ~ / Projects.У меня есть ~ в моем пути к компакт-диску, поэтому независимо от того, где я нахожусь в файловой системе, я могу напечатать cd Pro, и я нахожусь в папке моего проекта.Оттуда это просто вопрос записи в правильный каталог проекта.

0 голосов
/ 12 февраля 2011

Я организовал что-то вроде следующего:

/type(OS specific, website, application, script, etc)
  /sourcecode
    /snippets(sections of code that I use frequently in many different projects)
      /language(perl, java, batch, bash, etc)
        /version(either version number or completion date depending on the project)
    /test_code(very raw form, pieces from here may work or may complete trash)
      /language
        /version
    /dev_code(slightly more refined code, but still buggy)
      /language
        /version
    /pprd_code(code that is being tested prior to delivery to the production environment)
      /language
        /version
    /prod_code(code that is currently completed and is either being used in production or is fully ready to be placed in production)
      /language
        /version
    /patches(special patches that do not have their own specific version)
      /language
        /version
  /compiled_projects
    /test_apps(very raw form, applications here may work or may be junkers yet to be deleted)
      /language
        /version
    /dev_apps(slightly more refined applications, but still buggy)
      /language
        /version
    /pprd_apps(applications that are being tested prior to delivery to the production environment)
      /language
        /version
    /prod_apps(applications that are currently completed and are either being used in production or are fully ready to be placed in production)
      /language
        /version
    /patches(special patches that do not have their own specific version)
      /language
        /version
/graveyard(I put all code or apps that I want to delete here for at least 6mo to a year just in case I may need something that I forgot about)
  /language
    /old_project_name_expected_deletion_date
...