Как не нужно создавать компоненты

в большом приложении

1

Дарья Пушкарская

daria_rrraf

• Frontend, Tinkoff.ru
• Автор школы webheroschool.ru
• Работала в 2GIS и Mail.ru

2

Дарья Пушкарская

daria_rrraf

• Спикер
• Пишу в блогах и телеграмм-каналах
• Делюсь мотивацией и вдохновением
• Вношу вклад в образование

3

Время о**фигительных историй

4

5

6

7

8

9

Я из Казахстана

10

Усть-Каменогорск

11

2GIS

12

Mail.ru

13

Tinkoff.ru

14

15

Полезные ссылки

• webheropublick
• Телеграмм-канал про изучение фронтенда
• iteventsru
• Анонсы всех офлайн и онлайн IT-мероприятий русскоязычного пространства
• Привем докладов по фронтенду
• Work-life balance
• Авторский телеграмм-канал про баланс между работой и жизнью

16

Tinkoff.ru Open Source

• Stapp
• Tinkoff Request
• react-styling-hoc

17

Как не нужно создавать компоненты

в большом приложении

18

19

Tinkoff.ru

20

21

22

23

24

25

Проблема

Нет единого пространства, которое объединяло бы все заказы и покупки совершенные в разных приложениях tinkoff.ru.

26

Решение

Сделать раздел «Мои заказы» в личном кабинете Tinkoff.ru.

27

28

Этапы разработки компонента

1. Постановка и спецификация задачи.
2. Разработка дизайна.
3. Разработка компонента.
4. Тестирование.

29

• Постановка и спецификация задачи.
• Разработка дизайна.
• Разработка компонента.
• Тестирование.

30

1. Спецификация

31

• Спецификация

Должна ли разработка участвовать?

32

Спецификация задачи

• Характеристики, SMART, TOTE…
• “Скетч” того, как должен в итоге выглядеть компонент и работать
• Возможно текстом, но желательно буквально наброски от руки
• Схемы взаимодействия и получения данных

33

• Характеристики, SMART, TOTE…
• “Скетч” того, как должен в итоге выглядеть компонент и работать
• Возможно текстом, но желательно буквально наброски от руки
• Схемы взаимодействия и получения данных

34

35

Что может произойти, если в этом этапе не будет участвовать разработка?

36

Возможные проблемы

• Будет описан функционал, которые невозможно реализовать.
• В дизайн пойдет “скетч”, в котором не учтены технические ограничения.
• Будет выбран не оптимальный путь реализации.
• Неверно оценены сроки реализации.
• Создание конфликтных ситуаций.

37

Маленькая задача, для реализации которой нужно переделать все приложение?

38

39

Разработка должна участвовать на этапе спецификации задачи

40

Вопросы, на которые нужно ответить совместно

• Возможно ли это реализовать?
• Как можно это реализовать?
• Сколько это займет времени?
• Оптимальный ли выбран путь реализации?
• Что стоит учесть при создании дизайна?
• Что будет происходить с компонентом в будущем?

41

42

43

2. Разработка дизайна

44

2. Разработка дизайна

Должна ли разработка участвовать?

45

46

47

48

49

50

51

52

53

Что может произойти, если в этом этапе не будет участвовать разработка?

54

Возможные проблемы

• Выбраны решения, с которыми могут быть технические сложности в будущем.
• Создан дизайн без учета технических ограничений.
• Создан дизайн, для реализации которого потребуются “дорогие” доработки.
• Не учтены пограничные кейсы.
• Будет создан компонент, дублирующий функционал.
• Будет создан дубль компонент со схожей логикой.
• В дизайне не учтено отображение реальных данных.

​

55

В дизайне выглядело хорошо, а в реальности что-то пошло не так?

56

57

Вопросы, на которые нужно ответить совместно

• Возможно ли это реализовать технически?
• Обойдет ли нам реализация “дорого”? Нужно ли упрощать?
• Есть ли уже готовые компоненты для переиспользования?
• Как будут выглядеть и реализованы пограничные кейсы в текущем дизайне?
• Учитывает ли текущий дизайн планы на будущее развитие компонента?

58

59

60

3. Разработка компонента

61

3. Разработка компонента

Последствия

62

63

Этапы разработки

1. Получение данных и агрегация данных
2. Форматирование данных для отображения
3. Создание и использование компонента

64

Мы получили финальный дизайн и не вникая в бизнес принялись реализовывать функционал

65

66

Этапы разработки

• Получение данных и агрегация данных
• Форматирование данных для отображения
• Создание и использование компонента

67

68

Все хорошо

69

А можно подключить еще 100500 6 приложений?

70

В результате

• Теряем производительность из-за числа запросов.
• Мы не заложились на масштабируемость из-за незнания контекста.
• Нервничаем и конфликтуем.

​

71

72

gateway api

73

Этапы разработки

• Получение данных и агрегация данных
• Форматирование данных для отображения
• Создание и использование компонента

74

75

76

77

78

79

Этапы разработки

• Получение данных и агрегация данных
• Форматирование данных для отображения
• Создание и использование компонента

80

81

Все проблемы с этапа дизайна

82

83

А можно использовать в другом 100500 других приложение?

84

85

Tinkoff UI

86

87

88

Казалось всего-лишь карточка...

89

В результате:

• Отдельный МС.
• Конфиг в админке для регулировки МС.
• Вспомогательные пакеты с методами обработки данных и с бизнес-логикой.
• Отдельный пакет-компонент из кита карточки.
• Специально выстроенные процессы для интеграции новых приложений.
• Возможность безболезненно и быстро интегрировать любое количество приложений.
• Учтены кейсы для масштабирования и переиспользования.
• Дизайн разработан в соответствии с техническими ограничениями и планами на будущее.
• Все счастливы.

90

91

Что делать, чтобы создать себе проблемы в будущем?

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

92

93

Разработка должна участвовать на всех этапах создания компонента продукта.

94

Что дальше?

95

Дарья Пушкарская

daria_rrraf

d.pushkarskaya.pr@gmail.com

+ подарок

96

AstanaJS2018

97