Как свести концы с концами. Практики кросс-командного взаимодействия.

SECR 2018
Дмитрий Туфанов
Старший системный аналитик, Райффайзенбанк

Сейчас в разработке практически любого сложного проекта участвуют несколько команд, и один из решающих факторов успеха – это правильно организованный процесс создания кросс-командных фич.

Я расскажу о рабочем процессе, к которому мы пришли в ходе разработки нашего нового интернет-банка для юрлиц.

Подход основан на предварительном проектировании модели данных, автоматической генерации JSON schema, чётких критериях приёмки разработанного API.

Transcript

1. Как свести концы с концами Практики кросс-командного взаимодействия Дмитрий Туфанов Systems Analyst
2. Raiffeisen Business Online (RBO) • Интернет-банк для юридических лиц • В проектном чате 34 человека • Front-end и back-end разрабатываются разными командами
3. Front-end Developer Back-end Developer Systems Analyst Исходная позиция Подготовка требований Разработка Front-end Разработка API Подключение API Обсуждение формата обмена Переделываем 
4. Исходная позиция • У нас более 30 различных бизнес-сущностей
5. Исходная позиция • У нас более 30 различных бизнес-сущностей • Эти сущности сильно пересекаются по набору атрибутов
6. Исходная позиция • У нас более 30 различных бизнес-сущностей • Эти сущности сильно пересекаются по набору атрибутов • Но в реализации эти пересекающиеся атрибуты не всегда передавались одинаковым образом между Front и Back-end
7. Исходная позиция • У нас более 30 различных бизнес-сущностей • Эти сущности сильно пересекаются по набору атрибутов • Но в реализации эти пересекающиеся атрибуты не всегда передавались одинаковым образом между Front и Back-end • Код для сериализации и парсинга этих атрибутов не переиспользовался
8. Решение
9. Модель данных Информация о документе • Номер • Дата • Статус Сумма в валюте • Сумма • Валюта Подразделение банка • Наименование • Местоположение • БИК Организация • Наименование • ИНН Ответственное лицо • ФИО • Телефон
10. Модель данных Кредитная заявка • Номер кредитного соглашения • Дата кредитного соглашения • Срок кредита • Дата предоставления кредита • … Информация о документе • Номер • Дата • Статус Сумма в валюте • Сумма • Валюта Подразделение банка • Наименование • Местоположение • БИК Организация • Наименование • ИНН Ответственное лицо • ФИО • Телефон
11.  Визуализация структуры данных помогает в ходе согласования формата обмена Что получили
12.  Визуализация структуры данных помогает в ходе согласования формата обмена  Сразу видны общие и специфические сущности Что получили
13.  Визуализация структуры данных помогает в ходе согласования формата обмена  Сразу видны общие и специфические сущности  Модель можно подготовить быстро и на ранних стадиях работы Что получили
14. «А где у нас передаѐтся счѐт»? «Если изменим этот атрибут, какие компоненты надо будет протестировать?» Sparx Enterprise Architect
15. Модель может быть прочтена по-разному Проверка реализации по модели – только вручную Модель – это хорошо, но… Помимо модели нужны схемы данных
16.  Xml Schema (XSD)  JSON Schema  RDFS Генерация JSON Schema по модели *Для выгрузки используем Schema Composer
17.  Схемы трудно читать  В больших схемах сложно ориентироваться Минусы JSON Schema { "$id": "https://example.com/person.schema.json", "$schema": "http://json-schema.org/draft-07/schema#", "title": "Person", "type": "object", "properties": { "firstName": { "type": "string", "description": "The person's first name." }, "lastName": { "type": "string", "description": "The person's last name." }, "age": { "description": "Age in years which must be equal to or greater than zero.", "type": "integer", "minimum": 0 } } } { "firstName": "John", "lastName": "Doe", "age": 21 }
18.  Web-версия: https://json-schema-faker.js.org/  Npm-пакет для Node.js: https://github.com/json- schema-faker/json-schema-faker Генерация примеров по схеме
19. Front-end Developer Back-end Developer Systems Analyst К чему мы пришли Сбор требований и подготовка модели данных Согласование модели Генерация JSON Schema и примеров Разработка Front-end на заглушках (mockups) Разработка API Валидация API, доработка Front-end и API Переключение c заглушек на разработанный API Внесение изменений в модель
20. Плюсы Сокращение общих затрат на разработку за счѐт меньшего количества переделок
21. Плюсы Сокращение общих затрат на разработку за счѐт меньшего количества переделок Меньше повторяющихся багов, так как часть кода переиспользуется
22. Плюсы Сокращение общих затрат на разработку за счѐт меньшего количества переделок Меньше повторяющихся багов, так как часть кода переиспользуется Не надо выяснять, «кто виноват». Схема – контракт
23. Подход рекомендуется, если Система сложная, с длительным циклом жизни
24. Подход рекомендуется, если Система сложная, с длительным циклом жизни В разработке участвует несколько команд или в команде более трѐх разработчиков
25. Подход рекомендуется, если Система сложная, с длительным циклом жизни В разработке участвует несколько команд или в команде более трѐх разработчиков Различные системные сущности имеют общие части
26. Дмитрий Туфанов Dmitriy.Tufanov@gmail.com Спасибо за внимание @DTufanov