![image](https://habrastorage.org/getpro/habr/post_images/d1f/353/f47/d1f353f47e2bb1f92ad36f7e86acc473.png)
Дорогие друзья!
Мы давно хотели рассказать о разработке нашей платежной системы, чтобы поделиться своим опытом. Наконец-то время беспрерывного кодинга прошло и появилось немного времени, чтобы структурировать информацию. Итак, рассказываем, как мы делали наш продукт.
Payler был разработан относительно в короткий промежуток времени. Мы попробовали различные методологии управления процессами, но в реалиях нашей команды следуем некоторой своей системе управления.
Преамбула: «Что такое Payler сегодня?»
● Основные компоненты продукта: антифрод, ядро шлюза, публичные и внутренние API, модули процессинга, административные интерфейсы мерчанта, мобильные клиенты, внутренние утилиты;
● Продукту несколько месяцев, получен сертификат на соответствие PCI DSS, появились первые клиенты;
● Используемые технологии: C#, Python, Ruby, MySQL, Redis, Angular.js etc.;
● Команда:
○ Backend: 3 разработчика, которые периодически переключаются между компонентами;
○ Frontend: 1 разработчик;
○ Mobile: 2 разработчика — 1 iOS, 1 Android;
○ Системный администратор.
А теперь расскажем подробнее о процессе самой разработки.
1. Не технические практики
Сначала расскажем о тех практиках, которые мы наработали по части организации рабочего процесса, взаимодействия между членами команды, оценки результатов и так далее.
Трекинг задач и хранение документации
Исторически сложилось, что продукты Atlassian прочно закрепились в нашей компании. Мы используем комбинацию Jira+GreenHopper — для задач, а Confluence + иногда Google Drive в рамках домена — для файлов.
Цикл
Для этого мы используем Kanban. Поскольку команде приходится меняться между задачами внутри компонент, а так же оперативно выпускать релизы и баг-фиксы, данная методология как нельзя лучше нам подошла. Критичные баг-фиксы мы выпускаем в течение дня, остальные деплоим глубой ночью или ранним утром когда практически нет активности транзакций. Новая же функциональность выходит примерно раз в неделю-две.
Оценки
Разработка платежного шлюза зависит от многих факторов, основной из которых — это взаимодействие с банками и их процессинговыми центрами. Поэтому в основном сложно давать какую-либо временную оценку той или иной задаче, однако там, где это возможно, например, в мобильных приложениях, административные кабинеты и так далее, мы все же ее проводим. В остальных случаях стараемся фокусироваться на более важных вещах.
Митинги
Проводим только при необходимости в рамках какой-то функциональности. В остальных случаях стараемся избегать.
Рабочее время
Рабочее время сотрудников мы не отслеживаем. У нас относительно гибкий график, но с одним обязательным правилом — начало рабочего дня не позже 11:00. Главное – это выполнение поставленных задач, так что в этом плане у нас хорошие условия для тех, кто умеет себя контролировать.
Мини-команды
1-2 человека в зависимости от задачи. Но этого сейчас становится недостаточно, поэтому мы стремимся наращивать команду исходя из расчета на 3-4 человека в мини-команде.
2. Технические практики
Здесь мы расскажем о некоторых практиках, которые мы применяем у себя в разработке по части технических задач.
Парное программирование
Используем в редких случаях, опять же для решения сложных задач. Две головы, два монитора.
Контроль версий
Как и многие компании, мы любим Git и каждую новую фичу или фикс бага льем в отдельную ветку. В master отражается релизная версия, в development отражается версия содержащая изменения за день.
Тесты
Мы (разработчики) сами пишем тесты. Для частей системы написанных на C# мы начали с TDD (XUnit), потихоньку двигаемся в сторону BDD (SpecFlow etc.). Так же у нас есть часть тестов на Python для тестирования ответов от банка, API, а так же BDD (RSpec, Cucumber) для Ruby-проектов и юнит-тесты для кода мобильных клиентов. Сейчас мы стараемся внедрять практику для фронтенда на Angular.js, а так же стремимся к 70-80% покрытию.
P.S. Кстати, в Брянске нам ОЧЕНЬ нужны серверные разработчики (C#/Java, Ruby/Python, Go), JavaScript разработчики, iOS разработчики. Если вы проживаете здесь и ищете работу по указанным специальностям – пишите нам на hello@payler.com.
Наш следующий пост будет посвящен разработке смс-шлюза Billingrad, мы поделимся своими наработками. На любые вопросы с радостью ответим в комментариях.
С любовью,
Payler