О себе
О чем буду говорить
О чем буду говорить
О чем буду говорить
О чем буду говорить
О чем буду говорить
О чем буду говорить
С чего все началось?
Бизнес поставил задачу
Бизнес поставил задачу
Бизнес поставил задачу
Бизнес поставил задачу
Но не все так просто…
Проблема №1
Проблема №2
Проблема №3
В результате получили
Набираем команду, решаем задачи
Прошло много часов, ни одного решения
Критерии эффективной команды
Требования к архитектуре
Но мы наступили на грабли :(
Грабли №1
Грабли №2
Выбираем технологии
Не тратить время на изобретение велосипедов
“Если хочешь рассмешить Бога, расскажи ему о своих планах”
Проблема №1
Проблема №2
Еще один пример
Тесты нам помогают
В одной упряжке с дизайнерами
Не попадаем в дедлайн
Но команде прозрачно и бизнесу спокойно
Но для этого…
Нам это удалось, чего и вам желаем!
10.00M
Категория: ПрограммированиеПрограммирование

Как переписать приложение с нуля и не потерпеть фиаско

1.

Как переписать приложение с нуля
и не потерпеть фиаско
Емельянов Михаил,
Android Team Lead

2. О себе

7 лет в Android-разработке
В ЦФТ с 2013 г.
Разработал более десятка проектов

3. О чем буду говорить

1. С чего все начиналось
2. Как набирали команду и решали задачи
3. Оцениваем масштаб разработки
4. Проблемы с архитектурой и технологиями
5. Какая польза от Unit-тестов и других инструментов
6. Не успевали к срокам, что делать

4. О чем буду говорить

1. С чего все начиналось
2. Как набирали команду и решали задачи
3. Оцениваем масштаб разработки
4. Проблемы с архитектурой и технологиями
5. Какая польза от Unit-тестов и других инструментов
6. Не успевали к срокам, что делать

5. О чем буду говорить

1. С чего все начиналось
2. Как набирали команду и решали задачи
3. Оцениваем масштаб разработки
4. Проблемы с архитектурой и технологиями
5. Какая польза от Unit-тестов и других инструментов
6. Не успевали к срокам, что делать

6. О чем буду говорить

1. С чего все начиналось
2. Как набирали команду и решали задачи
3. Оцениваем масштаб разработки
4. Проблемы с архитектурой и технологиями
5. Какая польза от Unit-тестов и других инструментов
6. Не успевали к срокам, что делать

7. О чем буду говорить

1. С чего все начиналось
2. Как набирали команду и решали задачи
3. Оцениваем масштаб разработки
4. Проблемы с архитектурой и технологиями
5. Какая польза от Unit-тестов и других инструментов
6. Не успевали к срокам, что делать

8. О чем буду говорить

1. С чего все начиналось
2. Как набирали команду и решали задачи
3. Оцениваем масштаб разработки
4. Проблемы с архитектурой и технологиями
5. Какая польза от Unit-тестов и других инструментов
6. Не успевали к срокам, что делать

9. С чего все началось?

10. Бизнес поставил задачу

• Масштабироваться
• Увеличить скорость разработки фич
• Новый дизайн
• Улучшить стабильность

11. Бизнес поставил задачу

• Масштабироваться
• Увеличить скорость разработки фич
• Новый дизайн
• Улучшить стабильность

12. Бизнес поставил задачу

• Масштабироваться
• Увеличить скорость разработки фич
• Новый дизайн
• Улучшить стабильность

13. Бизнес поставил задачу

• Масштабироваться
• Увеличить скорость разработки фич
• Новый дизайн
• Улучшить стабильность

14. Но не все так просто…

15. Проблема №1

Архитектура

16.

?
MVPVM?

17.

?
MVPVM?

18.

?

19.

Стартуем Activity
Делаем операции View
Отправляем broadcast

20. Проблема №2

Ресурсы и стили

21.

22.

23. Проблема №3

Рефакторинг

24.

Смотрим покрытие тестами

25.

26. В результате получили

27.

Монолитный проект – сложно масштабироваться
Нет архитектуры – кругом спагетти-код
Нет тестов – делаем одно, ломаем другое
Долгий рефакторинг – тонем в техдолге
Невозможен – «просто» редизайн

28.

Монолитный проект – сложно масштабироваться
Нет архитектуры – кругом спагетти-код
Нет тестов – делаем одно, ломаем другое
Долгий рефакторинг – тонем в техдолге
Невозможен – «просто» редизайн

29.

Монолитный проект – сложно масштабироваться
Нет архитектуры – кругом спагетти-код
Нет тестов – делаем одно, ломаем другое
Долгий рефакторинг – тонем в техдолге
Невозможен – «просто» редизайн

30.

Монолитный проект – сложно масштабироваться
Нет архитектуры – кругом спагетти-код
Нет тестов – делаем одно, ломаем другое
Долгий рефакторинг – тонем в техдолге
Невозможен – «просто» редизайн

31.

Монолитный проект – сложно масштабироваться
Нет архитектуры – кругом спагетти-код
Нет тестов – делаем одно, ломаем другое
Долгий рефакторинг – тонем в техдолге
Невозможен – «просто» редизайн

32.

33. Набираем команду, решаем задачи

34.

Вася – Senior
Петя – Senior
Монолит
Модульная
Марк – тоже Senior
Какая
структура
проекта будет?
Feature-модульная?
Зачем сейчас
об этом думать?
Кирилл – Junior
Как скажете
Иннокентий – почти Senior

35.

Вася – Senior
Петя – Senior
MVP
MVVM
Марк – тоже Senior
Паттерн
проектирования?
Давайте MVI
Очевидно же!
MVP!
Кирилл – Junior
Иннокентий – почти Senior

36. Прошло много часов, ни одного решения

37.

Правило
«Команда из сильных разработчиков,
не всегда делает разработку сильной»

38.

Решение
Уволить всех Senior?

39.

Решение
Оставить 1-го

40.

Ваня – Middle
Джон – Middle
Вася – Senior
Кирилл – Junior
Гриша – Middle

41. Критерии эффективной команды

42.

Единомышленники
1 tech lead
Уровень знаний не ниже среднего
Прагматичный выбор технологий
1 команда = 4-5 человек

43.

Единомышленники
1 tech lead
Уровень знаний не ниже среднего
Прагматичный выбор технологий
1 команда = 4-5 человек

44.

Единомышленники
1 tech lead
Уровень знаний не ниже среднего
Прагматичный выбор технологий
1 команда = 4-5 человек

45.

Единомышленники
1 tech lead
Уровень знаний не ниже среднего
Прагматичный выбор технологий
1 команда = 4-5 человек

46.

Единомышленники
1 tech lead
Уровень знаний не ниже среднего
Прагматичный выбор технологий
1 команда = 4-5 человек

47.

Разбираем приложение по кирпичикам

48.

~ 5 месяцев
• 1 фича = 1 стикер
• Оценка на 1 чел (S, M, L, XL),
участвует вся команда
• Считаем, отдаем бизнесу

49.

Строим архитектуру

50. Требования к архитектуре

• Масштабируется
• Бизнес-логика отделена от представления и данных
• Не зависит от реализации: UI, библиотек, платформы
• Тестируется
• Простая в понимании и применении

51.

:data
:domain
:presentation
:app
Entity
Model
import
import
import
import
<<interface>>
<<interface>>
<<interface>>
DataSource
Interactor
View
Fragment
InteractorImpl
Presenter
Activity
<<interface>>
Repository
<<interface>>
EntityConverter
DataSourceImpl
RepositoryImpl
Router
RouterImpl

52. Но мы наступили на грабли :(

53. Грабли №1

Бизнес-логика == представлению

54.

?

55.

56.

Решение
Переделываем на UseCase

57.

:domain
Entity
import
<<interface>>
Interactor
InteractorImpl
<<interface>>
Repository

58.

:domain
Entity
import
UseCase
UseCase
UseCase
<<interface>>
Repository

59.

60.

61.

62.

63.

64.

65. Грабли №2

Бойлерплейт с конвертерами

66.

:data
Model
import
import
<<interface>>
DataSource
EntityConverter
DataSourceImpl
RepositoryImpl

67.

68.

69.

70.

Решение
Убираем модели и конвертеры

71.

:data
:domain
Entity
Model
import
import
import
<<interface>>
DataSource
EntityConverter
DataSourceImpl
RepositoryImpl
import

72.

:data
:domain
Entity
import
import
<<interface>>
DataSource
UseCase
UseCase
UseCase
DataSourceImpl
RepositoryImpl
<<interface>>
Repository

73. Выбираем технологии

74. Не тратить время на изобретение велосипедов

75.

76.

?
Dagger2
или Toothpick

77.

Retrofit
Dagger2
Room

78. “Если хочешь рассмешить Бога, расскажи ему о своих планах”

“Если хочешь рассмешить Бога,
расскажи ему о своих планах”

79. Проблема №1

Dagger2

80.

81.

Решение
AndroidInjector, @Binds и @Contributes

82.

83.

84.

85.

86. Проблема №2

Rx Hell

87.

:presentation
:domain
:data
Rx
Rx
:app
Rx

88.

89.

90.

91. Еще один пример

92.

93.

Правило
«Логика использования технологии
не должна быть сложнее
логики решения задачи»

94. Тесты нам помогают

95.

Не принимаем код без Unit-тестов

96.

97.

98. В одной упряжке с дизайнерами

99.

100.

101.

102. Не попадаем в дедлайн

103.

Строим итеративный
план спринтов

104.

105.

Даты

106.

Задачи

107.

108. Но команде прозрачно и бизнесу спокойно

109.

Эпилог
“Если головоломка не сложилась,
и тебе уже не собрать пазлы
— начни сначала”© Death Note

110. Но для этого…

Переписать приложение с нуля
и не потерпеть фиаско – можно!
Но для этого…

111.

Задать вопрос – «А нужно ли?»
Собрать команду единомышленников и оценить масштаб
Построить архитектуру решающую задачи бизнеса
Выбрать технологии, основываясь на опыте команды
Использовать Unit-тесты, они сэкономят время на отладке
Дизайнеры могут помочь, для этого есть все инструменты

112.

Задать вопрос – «А нужно ли?»
Собрать команду единомышленников и оценить масштаб
Построить архитектуру решающую задачи бизнеса
Выбрать технологии, основываясь на опыте команды
Использовать Unit-тесты, они сэкономят время на отладке
Дизайнеры могут помочь, для этого есть все инструменты

113.

Задать вопрос – «А нужно ли?»
Собрать команду единомышленников и оценить масштаб
Построить архитектуру решающую задачи бизнеса
Выбрать технологии, основываясь на опыте команды
Использовать Unit-тесты, они сэкономят время на отладке
Дизайнеры могут помочь, для этого есть все инструменты

114.

Задать вопрос – «А нужно ли?»
Собрать команду единомышленников и оценить масштаб
Построить архитектуру решающую задачи бизнеса
Выбрать технологии, основываясь на опыте команды
Использовать Unit-тесты, они сэкономят время на отладке
Дизайнеры могут помочь, для этого есть все инструменты

115.

Задать вопрос – «А нужно ли?»
Собрать команду единомышленников и оценить масштаб
Построить архитектуру решающую задачи бизнеса
Выбрать технологии, основываясь на опыте команды
Использовать Unit-тесты, они сэкономят время на отладке
Дизайнеры могут помочь, для этого есть все инструменты

116.

Задать вопрос – «А нужно ли?»
Собрать команду единомышленников и оценить масштаб
Построить архитектуру решающую задачи бизнеса
Выбрать технологии, основываясь на опыте команды
Использовать Unit-тесты, они сэкономят время на отладке
Дизайнеры могут помочь, для этого есть все инструменты

117. Нам это удалось, чего и вам желаем!

118.

Спасибо
Емельянов Михаил,
[email protected]
English     Русский Правила