Инструменты, которые мы используем для командной разработки

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

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

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

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

Отдельно хотелось бы сказать об управлении ролями. Для каждой такой роли можно индивидуально настроить права доступа. Возьмем частный случай. По умолчанию в redmine есть роль reporter, т.е. человек, который только сообщает об обнаруженных проблемах, не принимая участия в их решении. Мы настроили ее таким образом, чтобы пользователь с этой ролью видел только проекты, в которых он участвует. Так у нас получилось вовлечь заказчиков непосредственно в процесс разработки. Если они находят баги или хотят сделать доработки, то заходят в редмайн и самостоятельно добавляют задачи с соответствующим трекером (ошибка, улучшение, разработка или поддержка). Конечно менеджер всё это контролирует и при необходимости корректирует, а так же предварительно проводит с каждым клиентом инструктаж. Так же можно написать для них инструкцию при помощи плагина Q&A.

Как говорится, встречают по одежке. По этому редмайн с первого взгляда не впечатляет и выглядит уныло по сравнению с его платными аналогами вроде JIRA, basecamp и т.п. Это обычное дело для opensorce. Но для redmine есть красивые темы оформления, при чем высокого качества, например A1.

Так же Redmine можно превратить в почти полноценную CRM при помощи бесплатного плагина от RedmineCRM, который добавляет контакты, сделки, заметки и отправку сообщений прямо из интерфейса, в связке с бесплатными Invoices (счета), Finance (финансы) и People (люди).

Еще у этого же производителя есть плагин Helpdesk для организации службы поддержки клиентов. Он платный, но стоит не дорого — от $156. Конечно это не лучшее решение на рынке, но его несомненным преимуществом является полная интеграция с redmine.

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

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

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

IDE

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

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


Само собой, что PHPStorm разрабатывался специально для PHP-программистов. Если вы работаете c другим языком, можете выбрать необходимый для ваc IDE от тех же разработчиков (JetBrains) на этой странице. На данный момент у них есть программы для следующих языков программирования:

  • IntelliJ IDEA (Java, а так же Flex и Air)
  • RubyMine (Ruby)
  • ReShaper (.NET)
  • PyCharm (Python)
  • WebStorm (HTML, CSS, JS)


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

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

Так же мы используем дропбокс для демонстрации дизайна заказчикам. Это очень удобно — загрузил PNG-превьюшки макетов в отдельную папку, нажал «Share link» и получил ссылку с вот такой галереей. Изображения нужно загружать именно в PNG, потому что JPG макеты дропбокс дополнительно сжимает и они становятся совсем низкого качества. Главным преимуществом такого способа демонстрации дизайна заказчику является то, что он всегда видит самые свежие версии макетов по одной и той же ссылке. Например, дизайнер внес правки в макеты, обновил превьюшки и они обновились в галерее по ссылке, которую ранее дали заказчику. Осталось только сказать заказчику, чтобы обновил страницу в браузере.



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

Comments 11

    +13
    Добро пожаловать в 2013.
      +1
      Помимо этого полезно упомянуть еще системы для автоматического построения билдов. Без этого сейчас никуда, как минимум CI стоит внедрять. В команде из 3-4 человек это уже будет полезно.
      Тулов очень много — TeamCity, Jenkins, Go, MSBuild и т.д. Вообще много работал с TeamCity для небольших коммерческих проектов в самый раз. Недавно решил еще заценить Go от ThoughtWorks
        +3
        Ну как-то совсем мало. Почитайте тест Джоэла Спольски, датированный 2000 годом.
          +3
          Я как-то не понял, а где в этой статье, собственно, инструменты для командной разработки?
            –5
            SVN, по-вашему, таковым не является?
              +3
              Это статья, в которой говорится, что существует SVN и Notepad++? Для таких объёмов информации есть твиттер.

              UPD: Поясню, от статьи с таким заголовком ожидается увидеть множество названий, и для каждого — назначение, возможности, цены, плюсы и минусы, собственный опыт работы, а также возможные связки приведенных инструментов.
                –4
                Я разве где-то в статье говорил, что перечислю все инструменты? Или она называется «Все инструменты для командной разработки»?

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

                  Вы получаете минусы за то, что написали статью очень низкого качества. Настолько, что и статьёй это назвать тяжело. Поэтому, во избежание дальнейших минусов рекомендую убрать ее в обратно в черновики. Если вам все же хочется написать статью на эту тему, то добавьте еще раз 40 по столько же текста, добавьте скриншоты, расскажите про свой опыт работы с различными инструментами, как это помогло командной работе, насколько эти решения масштабируются на большие команды.

                  А если кроме SVN и Notepad++ вам написать не о чем, то вам не стоит пока писать статьи для хабра на эту тему.
                    0
                    Добавил примеров и собственных наработок по redmine. Специально растягивать текст и добавлять воду смысла не вижу, так же как и писать о инструментах, с которыми не работал.
            0
            Комментарий на правах feedback-a…
            Для такого названия поста слишком несистемно представлена информация, больше похоже на обрывки мыслей. Значительно ценнее опыт применения для решения конкретных задач, желательно с указанием особенностей проекта(ов), «граблей», на которые Вы наступили, и находках (нестандартные варианты использования, например), которые позволили получить синергетический эффект от использования, пусть даже в Вашем конкретном проекте.

            Мы у себя, например, два года выстраивали процессы коллективной разработки распределенной команды программистов (два офиса в Москве, один в Дубне). Используем, собственно, описанные Вами инструменты: redmine, svn и др. Думаю, принципиально ничего бы не поменялось, если бы вместо redmine был trac, а вместо svn — git. Само сложное и основное было правильно выстроить процессы. Использование конкретных инструментов — дело вторичное. Если нечего автоматизировать, то можно и кучу денег вбухать в коммерческие инструменты — работа не станет эффективнее.

            Делитесь реальным опытом и люди к Вам потянутся!:)
            Удачи.
              0
              Извините, что не оправдал Ваши ожидания. Изменил заголовок, надеюсь так он больше соответствует содержанию статьи.

            Only users with full accounts can post comments. Log in, please.