Как сделать платежную систему?
Дорогие друзья!
Мы давно хотели рассказать о разработке нашей платежной системы, чтобы поделиться своим опытом. Наконец-то время беспрерывного кодинга прошло и появилось немного времени, чтобы структурировать информацию. Итак, рассказываем, как мы делали наш продукт.
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
