Проблемы и пути их решения при командной разработке проектов

1. Проблемы и пути их решения при
командной разработке проектов
Digital-агентство AlterEGO
Иван Машканцев, веб-разработчик

2. Когда пригодятся эти знания?
 Вы делаете систему со сложной бизнес-
логикой
 Функционал богат на сложные решения
 Вы применяете не только стандартные
компоненты
 Планируется длительная поддержка и
развитие проекта

3. Зачем работать командно?
 Современный сайт — результат труда
нескольких специалистов
 Современный сайт — большой функционал,
скрытый от глаз пользователя
 Разработка в сжатые сроки
 Нет незаменимых людей

4. И в чем проблема?
 Нет единого стандарта — программистам
трудно работать с кодом друг друга
 Разработка на ФТП — проблема с
коллективной работой с файлами
 Невозможность исправить ошибку быстро и
безопасно
 Трудность в дальнейшей поддержке
 Вносим правки «в базу» вживую

5. Мужайтесь

6. А решить-то можно?
 Разработка стандартов кодирования
 Документирование кода
 IDE
 VCS
 WIKI
 Таск-трекер
 Миграции
 Тестирование

7. Разработка стандартов
кодирования
 Согласовать или придумать внутри студии
правила оформления php-кода, отношение к
коротким тэгам, отступам, определению
переменных, методов, классов....
 … Или взять готовое!

8. Нужно соглашение о кодировании

9. IDE
 Использовать обязательно
 Индексация структуры проекта — экономит
время
 Помогает соблюсти стандарты кодирования
 Подсветка кода (а вдруг?)
 Подсказки для разработчика
 Интеграция с VSC, выгрузка файлов, дебаг

10. Варианты?
 Eclipse
 Netbeans
 PhpStorm
 NuSphere PhpED

11. Какую же выбрать?

12. Документирование кода
 Поможет ориентироваться в проекте
 Ускоряет работу разработчика
 Написание не занимает много времени

13. Но как упростить работу с API
Битрикс?
 Живое описание АПИ
 http://www.bxapi.ru/ — веб-версия живого
описания АПИ
 Плагин для вашей любимой IDE —
например, BitrixStorm для PhpStorm
 BxApiDocs — для Eclipse или для PhpStorm
 Сниппеты стандартных компонент Bitrix —
для Eclipse или для PhpStorm

14. Система контроля версий
 Имеем историю изменений
 Можем работать с одним и тем же файлом
 Не боимся ничего менять — в любой момент
мы можем откатиться
 Делаем код чище
 Полезно даже для одного разработчика
 SVN, Git или Mercurial

15. GitHub или Bitbucket для
командных проектов

16. WIKI
 Что вообще происходит с проектом?
 Какие особенности есть, о чем стоит знать?
 Механизм тестирования, узкие места,
критичные вещи
 Все доступы — в одном месте
 Повторное использование знаний
 Легко поделиться

17. Настройки сайта
 Храним в WIKI
 Выносим изменение стандартных настроек
модулей или сервисов
 Члены команды знают, почему изменена та
или иная настройка и не пытаются этого
поменять

18. Таск-трекер
 Задачи не теряются
 Возможно оценить готовность этапа
 Есть история действий над задачей
 Удобство обсуждения
 Внятное разделение ответственности
 Учет потраченного времени

19. Чего изволите?
 Mantis
 JIRA
 Redmine
 Bitrix24

20. Как будем работать?
 Обсуждаем задачи и рабочий процесс
 Продакшн — непосредственно боевой сайт
 Тестовый сайт для показа изменений
 Локальная копия сайта у всех
разработчиков
 Каждый разработчик имеет свою ветку в
VCS
 Одна задача — новая ветка
 Каждый разработчик - отдельный
пользователь на сайтах

21. А так можно?
 Да!
 Битрикс по правилам лицензирования
позволяет иметь сайты, которые «не
смотрят» в интернет, т. е. локальные
 Если нужна более сложная схема —
есть NFR ключи
 Поддержка Битрикса склонна идти на
встречу

22. Наконец-то начнем
 Создаем репозиторий
 Формируем .ignore - файл
 Делаем первый коммит
 Инициируем репозиторий на сервере
его на сервере
 Добавляем разработчиков, раздаем
права

23. Что не нужно выносить в
репозиторий?
 Резервные копии
 Данные кэша
 Логи
 Пользовательские данные (загружаемые
файлы, картинки и.т.п)
 Конфиг — подключение к БД
 Все прочие файлы, не имеющие отношения
к коду - *.txt, *.xml и.т.п.

24. Как обновлять систему?
 С большой осторожностью — что-то
может отвалиться
 Делать бэкапы
 Обновлять тестовую площадку,
смотреть, затем переносить изменения
всюду

25. Перенос изменений БД
 В Битрикс нет встроенного механизма
миграций

26. Houston, we have a problem

27. И что делать?
 Смириться
 Собирать изменения структуры, а
затем рассылать изменения всем
участникам
 Назначить ответственного «повелителя
проекта», который будет проводить все
манипуляции с БД
 Написать механизм миграции самому
или найти готовый:)

28. Зачем выбирать механизм
миграций?
 Это удобно
 Экономит время разработчика
 Возможность «откатиться» обратно
 Помогает участникам вносить
изменения, не боясь что-то поломать
 Снижает риск ошибок

29. Но помни!
 Любое внесение критичных изменений
в структуру базы данных боевого сайта
должно сопровождаться созданием
бэкапа
 Трата 10 минут — потенциальная
экономия нескольких часов на
восстановление данных и потерянного
доверия клиента

30. Тестирование
 Ручное тестирование — хорошо, но
мало
 Сложные места хорошо тестировать
автоматизированно
 Стандартный инструмент — Selenium

31. Что лучше тестировать
автоматически?
 Длинные сценарии
 Многовариантное заполнение форм
 Критичный функционал, ошибка в
котором недопустима

32. Все получилось! Как ускорить
работу над следующим
проектом?
 Продумай перечень стандартных задач
 Заведи общую базу знаний
 Заведи общую базу кода со стандартными
решениями для использования в будущих
проектах
 Вершина дао — свой модуль Marketplace —
помощь сообществу и удобство доступа

33. Спасибо за внимание!
Остались вопросы?
Email: depechemodefan@alterego.biz.ua
Skype: depechemode_fan1