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

Когда работаешь в одиночку, можно обойтись простым блокнотом. Notepad++ для написания кода и лист бумаги с карандашем для заметок. Я конечно утрирую, но, по сути, это так и есть. В командной разработке всё немного иначе.

Системы управления проектами

Здесь нужно постоянно общаться с другими участниками процесса, при этом необходимо, чтобы история переписки сохранялась и к ней был удобный доступ. Для этого используют сервисы и веб-приложения для управления проектами. В нашем случае это Redmine. До него пробовали TeamLab. Есть как SAAS версия, так и веб-приложение для установки на свой сервер, кстати opensource. Но последний как-то не прижился.

Подобных инструментов нынче много, как платных, так и opensource. Они помогают распределять задачи между разработчиками и задавать для них приоритет, отслеживать затраченное время и многое другое. Для менеджера проекта это просто незаменимый помощник по управлению процессом разработки.

Системы контроля версий

Так же при командной разработке возникает проблема версионности. Если два разработчика одновременно открыли один и тот же файл и начали его редактировать, то при сохранении результатов неизбежно возникнут проблемы. Второй просто перезапишет изменения первого. Для избежания подобных ситуаций существуют системы контроля версий, например SVN или GIT. Мы пользуемся SVN. Это еще одна незаменимая вещь при командной разработке.

В SVN (наверняка и в GIT тоже) есть крайне полезные функции, называемые хуками. В их числе post commit. Этот хук при выполнении коммита загружает на сервер все отредактированные файлы. Очень удобная вещь, например при работе с версткой. Сверстал макет — сделал коммит — дал ссылку заказчику. Если он обнаружил баги — исправил, сделал коммит — ответил, что можно проверять. Никаких загрузок архивов на сервер, которые при большом количестве правок отнимают много времени.

IDE

Раз уж я заговорил об автоматизации, не правильно будет не упомянуть IDE — (Integrated Development Environment — интегрированная среда разработки). Как ни странно, но многие разработчики, особенно это касается программистов, пользуются примитивным софтом, например Notepad++. Ничего не имею против этой программы и сам ей часто пользуюсь, когда нужно что-то быстро отредактировать. Загружается он моментально, это несомненный плюс. Но когда речь заходит о ежедневном использовании, подобные миниатюрные приложения должы уступать место полноценным IDE со всеми их преимуществами. Лично я пользуюсь PHPStorm’ом. Перечислю только самые полезные, на мой вгляд, функции:

• Встроенная поддержка систем управления версиями. Открыл проект, нажал Сtrl + T — апдейт сделан. Внес изменения, нажал Сtrl + K — коммит сделан.
• Автовыгрузка на FTP. Устанавливать и настраивать SVN на сервере у каждого клиента — дорогое удовольствие. Приходится работать по-старинке — через FTP. Но PHPStorm и здесь нам облегчит жизнь — при сохранении файл автоматически обновляется на сервере. А при загрузке проекта программа обновляет все файлы до последней версии, если они за это время изменились.
• И множество других стандартных для нормального IDE плюшек: удобный интерфейс, красивые темы оформления, автокомплит кода, инспекция кода на ошибки (например встроенный W3C валидатор для HTML и CSS) и т.д.

Облачные хранилища данных

Помимо текстовых файлов, при работе в команде нужно обмениваться и бинарными (напр. изображения). Для этих целей системы контроля версий использовать смысла мало: при возникновении конфликта все равно объединить два файла не удастся, при большом количестве ревизий репозиторий будет иметь огромный размер. В случае с PSD файлами, которые зачастую весят по 20 мегабайт и более, эта проблема вообще становится критичной. По этому для таких целей лучше подойдет облачное хранилище данных, мы используем Dropbox. У этого сервиса есть очень достойная альтернатива — Google Drive, которая имеет ряд преимуществ, например хорошую систему распределения прав доступа к файлам. Но, когда мы выбирали такой инструмент для своей команды, последний был просто до безобразия сырым.

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

Автор: smartseven

Источник