как вы организуете свою работу по программированию - PullRequest
14 голосов
/ 12 января 2011

Я новичок в этой области, но в ближайшее время мне нужно разработать приложение для друга (я уже поработал над приложением, и друг счастлив).

Я предполагаю, что мне нужно 3 места для хранения моей работы, но я не уверен, что это лучший подход. Мне нужны ваши советы, мнения, ссылки, книги, блоги на эту тему.

Я планирую иметь:

  1. место, где я разрабатываю приложение
  2. место, где я храню резервную копию приложения
  3. место с приложением, готовым к использованию

Я буду использовать git на этапе разработки, но в дальнейшем я не знаю, какие инструменты использовать или каковы хорошие практики. Можете ли вы дать мне совет?

PS: в данный момент я использую cakephp для создания некоторых веб-приложений, но время от времени я тоже играю на C ++.

Ответы [ 9 ]

9 голосов
/ 13 января 2011

1: место, где я разрабатываю приложение

Это будет ваша локальная касса.

2: место, где я храню резервную копию приложения

Вы имеете в виду источники или какой-либо скомпилированный результат? Для источников вы можете

  1. Используйте общедоступную службу, такую ​​как http://github.com или http://gitorious.org, в качестве системы резервного копирования. Я рекомендую это, если вы не против использовать услугу, которая не находится под вашим контролем.
  2. Настройте собственный git-сервер (достаточно linux-бокса с установленными sshd и git). Вы должны знать, что при настройке удаленного репозитория существуют некоторые подводные камни (репозитории должны быть пустыми, и вам нужно правильно настроить разрешения, когда есть несколько пользователей Unix, которые должны иметь возможность проталкиваться в репозиторий) *

В любом случае вы git push фиксируете свои действия в удаленном хранилище, чтобы получить резервную копию вашей работы.

3: место с приложением, готовым к использованию

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

Я буду использовать git на этапе разработки, но позже я не знаю, какие инструменты использовать, или каковы хорошие практики. Можете ли вы дать мне совет?

Как уже сказал @Navi, автоматизированный инструмент сборки - это большой плюс. Рекомендуется использовать сборку из одной команды, что означает, что вам нужно выполнить ровно одну команду, чтобы собрать полное программное обеспечение после проверки.

Вам также следует рассмотреть систему непрерывной интеграции 1039 *, это программное обеспечение, которое отслеживает изменения в центральном хранилище исходного кода и автоматически создает программное обеспечение в среде чистой комнаты, когда обнаруживает что-то новое. Системы CI особенно удобны, если над программным продуктом работает много (> 1) человек, поскольку они могут очень быстро показывать испорченные сборки.

8 голосов
/ 12 января 2011

Обычной практикой является создание среды разработки, тестирования, интеграции и производственной среды. Интеграционные испытания и производство будут более или менее одинаковыми.

Я предлагаю вам также использовать какой-нибудь инструмент для сборки. Из вашего вопроса не ясно, какие платформы / технологии вы используете, но, вероятно, есть подходящая для вас.

Если вы используете Maven, то условием является различие между стабильными выпусками и экспериментальными версиями снимков.

5 голосов
/ 22 января 2011

Самый полезный совет уже дан:

  • Использовать контроль версий / контроль версий. И резервные копии. Действительно, действительно сделай это.
  • имеет отдельные экземпляры для разработки, тестирования, интеграции / постановки и производства. Если вам не хватает аппаратного обеспечения, виртуализируйте - есть несколько хороших коммерческих решений, но даже Virtualbox (бесплатно) будет часто выполнять эту работу.

Кроме того, я также рекомендую

  • Делайте резервные копии своих стабильных экземпляров на вехах. Когда это сработает, сохраните копию.
  • Используйте систему отслеживания проблем, например JIRA , Bugzilla или аналогичную. По крайней мере, имейте текстовый файл со списком дел и хорошим grep.
  • Помещайте в ваш код метки, такие как @TODO и @FIXME, где это применимо; большинство IDE, которые я знаю, найдут их автоматически и предоставят вам список из них. Это может или не может интегрироваться с трекером.

Я считаю важным отслеживать, что еще нужно сделать и насколько это важно, различать ошибки, улучшения, необходимые задачи и полезные элементы и так далее. Легко заблудиться в разработке и забыть о вещах - программирование требует от вас как углубиться во внутреннюю работу кода, так и помнить об общей структуре. Вам понадобится что-то, чтобы ваш разум был свободен от всех этих «и мне тоже придется это делать» вещей. Липкая желтая бумага не работает так же хорошо, как и блокноты для письма, так как при наличии, скажем, более 50 единиц бумаги трудно отслеживать.

Для этого есть программное обеспечение. Используйте это.

3 голосов
/ 21 января 2011

Вот лучшая практика для высокой производительности, но достаточно проста для новичка.

  1. Настройка локальной среды разработки.Используйте VCS, например, TortoiseSVN, или идеально используйте что-то, что полностью интегрируется с вашей IDE.Я использую Aptana с Subclipse для разработки приложений PHP.

  2. Настройка ночных сценариев для удаленного автоматического резервного копирования VCS.

  3. Получение среды удаленного разработчиканастройка (т.е. dev.mysite.com).Используется для тестирования живого сервера, проверки клиента, тестирования обратной связи пользовательского интерфейса и т. Д.

  4. При необходимости настройте промежуточный сервер (stage.mysite.com).Используйте для оперативного тестирования интеграции, тестирования обратной связи и т. Д. Если ваши проекты достаточно малы, вы обычно можете пропустить этот этап и просто использовать свою среду разработки для тестирования интеграции.

  5. Настройка производственной среды (www.mysite.com)

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

2 голосов
/ 18 января 2011

Я нашел минимальный набор кода для разработки и выпуска.Какой-то контроль версий имеет важное значение.Я использую HEAD для разработки, а ветку на релиз.Сделайте резервную копию вашего хранилища или, по крайней мере, поместите его на диск, отличающийся от диска (ов), используемого для разработки и сборки.

Я предпочитаю иметь три набора кода: разработка, тестирование и выпуск.У каждого должна быть автоматизированная среда сборки.Это среды сборки.Для разработки требуется только один набор.

  • Код выпуска используется для изменений в выпущенном коде, которые применяются до следующего выпуска.Любые сделанные здесь изменения либо возвращаются в разработку.или переработан (в случае быстрого исправления).
  • Тестовый код выпущен для тестирования.Это обеспечивает относительно стабильную среду для тестировщиков.Сборки обычно помечены, но не разветвлены.Тег используется как основа для ветки релиза.
  • Разработка должна собираться автоматически как минимум ежедневно.Это гарантирует, что код может быть собран вне среды разработки.

Вы можете использовать GIT для разработки и производства, но рабочий процесс отличается от того, который вы имели бы с CVS или subversion.Посмотрите онлайн-книгу ProGIT , чтобы понять процесс.

Избегайте кодирования в среде для приложения.Любые зависимости среды должны исходить из конфигурации среды.Приятно отображать некоторую индикацию сборки и среды в интерфейсе.

1 голос
/ 22 января 2011

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

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

Редактировать: я добавил пример задачи для расширения в моем проекте с открытым исходным кодом:

Пример Mind Map

1 голос
/ 22 января 2011
  1. Внешний контроль версий (github, bitbucket)
  2. Например. rsync в папку Dropbox
  3. Производственный материал должен быть сгенерирован программно из некоторой версии инструмента, контролируемой в шаге 1
1 голос
/ 21 января 2011

Храните ваш код на http://www.github.com. Если вам нужен код, который будет закрытым, вы можете создать размещенный частный репозиторий за номинальную плату, которая будет удовлетворять первым двум вашим требованиям.

Если вы хотите сохранить код и разместить сайт, есть компания облачных сервисов под названием PHP Fog (http://www.phpfog.com/), которая будет размещать код и иметь его готовым к использованию (требование 3).

1 голос
/ 18 января 2011

Быстрый и грязный рабочий процесс для одного разработчика, который не использует управление версиями sw:

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...