Контроль версий
Поскольку вы работаете в команде, в ваших же интересах, чтобы вы работали с чем-то распределенным. Ваши кандидаты - Git и Mercurial. Это означает, что ваша команда может выполнять коммиты локально, не нарушая проект, но все же отслеживать свою работу, а затем передавать эти коммиты на центральный сервер. Это также намного быстрее и имеет меньше конфликтов слияния, так как код отслеживается как наборы изменений, а не как ревизии. Прочтите руководство по hginit (написанное соучредителем переполнения стека не меньше), и вы немного больше поймете, что такое DVCS. http://hginit.com/
Вы также должны использовать репозиторий для развертывания вместо rsync или ftp.
Разработка через тестирование
В зависимости от того, что вы делаете, тестирование может тратить много времени. Я не говорю, что вы должны полностью пропустить это, для небольших проектов это накладные расходы. Если вы пишете библиотеку или большой долгосрочный проект, обязательно напишите для него тесты. Тесты помогут на этапе технического обслуживания. Имейте в виду, что TDD не может найти все ваши ошибки. Будут проблемы с пользовательским интерфейсом, проблемы с компоновкой, проблемы с производительностью и так далее.
Отладка
Xdebug в основном ваш единственный выбор здесь. Хорошо интегрируется с Netbeans. Если вы чувствуете необходимость когда-либо печатать переменные, вы должны использовать файл журнала. Используйте функцию logs frameworks, это намного безопаснее в производстве.
Планирование / Диаграммы
Если вы используете хороший фреймворк, вам не нужно создавать слишком подробные диаграммы. Сохраняйте это простым и работайте в более коротких циклах выпуска, его легко перепланировать. Требования и спецификации проекта обязательно изменятся, поэтому я бы не стал тратить на них все свое время. Помните, что спецификация кода на самом детальном уровне.
Используйте инструмент отслеживания ошибок (см. Ниже), чтобы разбить спецификацию на задачи, которые вы можете назначить членам команды. Используйте центральный инструмент для документирования проектов, у трекера ошибок, вероятно, будет вики.
Вы можете использовать такой инструмент, как Mysql Workbench, чтобы создавать схемы баз данных в диаграммах и экспортировать их в виде SQL.
Каркасы и ООП
Это, наверное, самая важная часть. Найдите себе популярный фреймворк, который будет поддерживать быструю разработку и повторное использование кода. Некоторым людям не понравится, когда я это говорю, но рамки должны определять, как вы работаете. Он должен обеспечивать структуру, чтобы один разработчик мог переключать проект и точно знать, где находится контроллер для определенной страницы, какие именно переменные шаблона и как запрашивать модель. Некоторые фреймворки допускают слишком большую гибкость, и вы обнаружите, что разработчики не всегда используют фреймворк одинаково. Мне нравится философия питона; должен быть один очевидный способ сделать все. Вот почему мне нравятся django и rails, они довольно самоуверенные, и это означает, что я могу посмотреть на чей-то код и понять, что он делает. Symfony выглядит как лучший вариант здесь,
Существует много вопросов о том, «что такое фреймворк» о переполнении стека, например:
/programming/2648/what-php-framework-would-you-choose-for-a-new-application-and-why
Отслеживание
ошибок Получите хорошую команду для отслеживания ошибок, разработанную для разработчиков. Не используйте что-то сверх упрощенное, как базовый лагерь. Redmine и Unfuddle - это два примера отличных баг-трекеров, которые также могут отслеживать время и интегрироваться в ваши репозитории. Ваша команда должна использовать этот инструмент для общения по вопросам, а не по электронной почте или IM. Это облегчает задачу для нового разработчика, когда существует история ошибок и документов. Эта статья объясняет, что именно должен делать любой хороший баг-трекер и почему. http://www.joelonsoftware.com/articles/fog0000000029.html