Как вы организуете свою работу по программированию?

Ответ 1

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

Это будет локальная проверка git.

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

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

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

В любом случае вы git push заносите в удаленный репозиторий резервную копию своей работы.

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

• Настройка рабочей среды (www.mysite.com)

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

• Контроль внешней версии (github, bitbucket)
• Eg. rsync в папку Dropbox
• Производственный материал должен генерироваться программно из некоторой версии инструмента, управляемой на шаге 1

Ответ 9

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

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

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

Пример карты разума