SlideShare uma empresa Scribd logo
1 de 67
Baixar para ler offline
Сложный проект с нуля:
через воду, огонь и
медные трубы
Филипп Дельгядо
Банальности, проверенные опытом
О чем этот доклад
Дельгядо Филипп, ИТИС, 2017
2
До запуска Запуск Развитие
О чем этот доклад
О людях
О процессах
Об инструментах
Дельгядо Филипп, ИТИС, 2017
3
О чем этот доклад
О людях
О процессах
Об инструментах
Но для разработчиков
Дельгядо Филипп, ИТИС, 2017
4
О проекте
Платежная система
1 год до боевых
1.5 года в бою
Много разработки до выхода в свет
Много рисков в процессе выхода
Постоянное развитие
Дельгядо Филипп, ИТИС, 2017
5
Алистер Коуберн
«Каждому проекту –
свою методологию»
Дельгядо Филипп, ИТИС, 2017
6
Уточню
«Каждой стадии проекта –
свою методологию»
Дельгядо Филипп, ИТИС, 2017
7
Вода
Из болота на чистую воду
8
Разработка в вакууме
Нет проверенных постановок
Много исследовательских задач
Не на ком проверить
Все легко изменить
Дельгядо Филипп, ИТИС, 2017
9
Главный риск
Доверять начальным
постановкам
Дельгядо Филипп, ИТИС, 2017
10
Главное
Работа с требованиями
Создание архитектуры
Организация общения
Дельгядо Филипп, ИТИС, 2017
11
Работа с требованиями
Зачем?
Дельгядо Филипп, ИТИС, 2017
12
Работа с требованиями
Зачем?
зачем нужна эта функциональность?
зачем нужно делать именно так?
зачем нужна эта библиотека?
зачем нужен этот отчет?
Дельгядо Филипп, ИТИС, 2017
13
Работа с требованиями
Бережем свой труд
Дельгядо Филипп, ИТИС, 2017
14
Работа с требованиями
Бережем свой труд
Keep
It
Simple,
Stupid!
Дельгядо Филипп, ИТИС, 2017
15
Работа с требованиями
До трех не обобщать
Дельгядо Филипп, ИТИС, 2017
16
Работа с требованиями
Все лгут!
Дельгядо Филипп, ИТИС, 2017
17
Простота изменений
Дешево менять структуру БД
и вообще структуру хранения
Дельгядо Филипп, ИТИС, 2017
18
Простота изменений
Дешево менять структуру БД
и вообще структуру хранения
Легко менять архитектуру
Дельгядо Филипп, ИТИС, 2017
19
Простота изменений
Дешево менять структуру БД
и вообще структуру хранения
Легко менять архитектуру
Не страшно менять UX
еще нет привыкших пользователей
Дельгядо Филипп, ИТИС, 2017
20
Надо помнить
Будет дорого менять внешние API
Будет дорого менять архитектуру
Будет дорого менять структуру БД
Будет дорого менять внутренние API
Будет дорого менять контрагентов
Дельгядо Филипп, ИТИС, 2017
21
Простота отладки
Провоцирует не писать логи
Дельгядо Филипп, ИТИС, 2017
22
Простота отладки
Провоцирует не писать логи
Но потом будет поздно
на боевых не будет ничего, кроме логов
а иногда и логов не будет (PCI DSS)
на боевых не будет доступа к СУБД
Дельгядо Филипп, ИТИС, 2017
23
Простота общения
Провоцирует пренебречь правилами
Дельгядо Филипп, ИТИС, 2017
24
Простота общения
Провоцирует пренебречь правилами
Но потом будет поздно
сформулируйте сode style
опишите принципы разработки
что такое хорошо и что такое плохо
договоритесь о правила сode review
соблюдайте no warnings
настройте static bug analyzing
Дельгядо Филипп, ИТИС, 2017
25
Простота общения
Провоцирует пренебречь документацией
Дельгядо Филипп, ИТИС, 2017
26
Простота общения
Провоцирует пренебречь документацией
Но потом будет поздно
документирование архитектурных решений
документирование развертывания
документирование БД
документирование сущностей
документирование сложных алгоритмов
Дельгядо Филипп, ИТИС, 2017
27
Эксплуатация
Дельгядо Филипп, ИТИС, 2017
28
Эксплуатация
Любите ребят из эксплуатации
Дельгядо Филипп, ИТИС, 2017
29
Эксплуатация
Любите ребят из эксплуатации
объясните им смысл настроек и параметров
укажите внешние зависимости и используемые порты
расскажите, что произойдет при внезапном останове
прикиньте, сколько нужно ресурсов
Дельгядо Филипп, ИТИС, 2017
30
Эксплуатация
Любите ребят из эксплуатации
объясните им смысл настроек и параметров
укажите внешние зависимости и используемые порты
расскажите, что произойдет при внезапном останове
прикиньте, сколько нужно ресурсов
И тренируйтесь
Дельгядо Филипп, ИТИС, 2017
31
Прочие опасности
Дельгядо Филипп, ИТИС, 2017
32
Прочие опасности
Не та методология
Дельгядо Филипп, ИТИС, 2017
33
Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Дельгядо Филипп, ИТИС, 2017
34
Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Дельгядо Филипп, ИТИС, 2017
35
Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Слишком качественное тестирование
Дельгядо Филипп, ИТИС, 2017
36
Прочие опасности
Не та методология
слишком сложный процесс
слишком простой трекер
слишком подробное планирование
Слишком сложная работа с VCS
Слишком качественное тестирование
Потерянный технический долг
Дельгядо Филипп, ИТИС, 2017
37
Огонь
Лихорадка запуска
38
Основное
Много неожиданных требований
Много срочных требований
Постоянные хотфиксы
Объемы задач непредсказуемы
Дельгядо Филипп, ИТИС, 2017
39
Главный риск
Суетиться
Дельгядо Филипп, ИТИС, 2017
40
Главное
Заранее отдохнуть
Дельгядо Филипп, ИТИС, 2017
41
Главное
Заранее отдохнуть
И отдохнуть после
Дельгядо Филипп, ИТИС, 2017
42
(Само) организация
Дельгядо Филипп, ИТИС, 2017
43
(Само) организация
Расписание дежурств
Дельгядо Филипп, ИТИС, 2017
44
(Само) организация
Расписание дежурств
Доступ из дома
ноутбуки, интернет, vpn
Дельгядо Филипп, ИТИС, 2017
45
(Само) организация
Расписание дежурств
Доступ из дома
ноутбуки, интернет, vpn
(Само)мотивация
премии, отгулы и т.п.
Дельгядо Филипп, ИТИС, 2017
46
Инструменты
АРМ разработчика
Дельгядо Филипп, ИТИС, 2017
47
Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Дельгядо Филипп, ИТИС, 2017
48
Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Дельгядо Филипп, ИТИС, 2017
49
Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Чатики
разработки, решения проблем, флудилка
Дельгядо Филипп, ИТИС, 2017
50
Инструменты
АРМ разработчика
у нас розовенький, с Hello Kitty
Трекеры поддержки
учет инцидентов
задачи эксплуатации
Чатики
разработки, решения проблем, флудилка
Мониторинг
Дельгядо Филипп, ИТИС, 2017
51
Люди
Заботьтесь о коллегах
Дельгядо Филипп, ИТИС, 2017
52
Поддержка
Заранее познакомьтесь с поддержкой
кто будет отвечать пользователям
Дельгядо Филипп, ИТИС, 2017
53
Поддержка
Заранее познакомьтесь с поддержкой
кто будет отвечать пользователям
Узнайте их регламенты
как говорят с пользователями
Дельгядо Филипп, ИТИС, 2017
54
Поддержка
Заранее познакомьтесь с поддержкой
кто будет отвечать пользователям
Узнайте их регламенты
как говорят с пользователями
Научитесь им доверять
Дельгядо Филипп, ИТИС, 2017
55
Наш процесс
Классический SCRUM
Коллективное планирование
Доска с задачами
Демо
Выкладка
Ретроспектива
Дельгядо Филипп, ИТИС, 2017
56
Наш процесс
Классический SCRUM
Коллективное планирование
Доска с задачами
Демо
Выкладка
Ретроспектива
Но размер спринта – один день
Дельгядо Филипп, ИТИС, 2017
57
Медные трубы
И вот, хорошо весьма?
58
Особенности
Дельгядо Филипп, ИТИС, 2017
59
Особенности
Вы и сами все про это знаете
Дельгядо Филипп, ИТИС, 2017
60
Особенности
Вы и сами все про это знаете
Но даже в уже запущенном продукте бывают проекты,
проходящие через воду, огонь и медные трубы
Дельгядо Филипп, ИТИС, 2017
61
Практики
Слона едим по частям
Дельгядо Филипп, ИТИС, 2017
62
Практики
IDE Driven Development
Дельгядо Филипп, ИТИС, 2017
63
Практики
No magic
Дельгядо Филипп, ИТИС, 2017
64
Практики
Все тесты должны быть запускаемы у программиста
а не только из CI
Без разрешения QA Lead никаких выкладок
Дельгядо Филипп, ИТИС, 2017
65
Инструменты
YouTrack
TeamCity
Git
Confluence
Telegram
Дельгядо Филипп, ИТИС, 2017
66
Вопросы?
Дельгядо Филипп
dph.main@gmail.com
phd@itasystems.ru
vk.com/dphil

Mais conteúdo relacionado

Mais procurados

разработка dspotapov.ru
разработка dspotapov.ruразработка dspotapov.ru
разработка dspotapov.ruDmitry Potapov
 
All iso standards available in english and russian (translation) languages, s...
All iso standards available in english and russian (translation) languages, s...All iso standards available in english and russian (translation) languages, s...
All iso standards available in english and russian (translation) languages, s...Suhrob Nadjimov
 
Когда код «убивает», или зачем нам тестировать наши продукты
Когда код «убивает», или зачем  нам тестировать наши продуктыКогда код «убивает», или зачем  нам тестировать наши продукты
Когда код «убивает», или зачем нам тестировать наши продуктыОлег Стрекаловский
 
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникаций
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийАлексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникаций
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
 
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?Krivoy Rog IT Community
 
Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...
Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...
Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...SQALab
 
How to prove programs
How to prove programsHow to prove programs
How to prove programsDenis Efremov
 
Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...
Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...
Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...Dev_Party
 
Тестування міграції: свіжий досвід від першої особи, Катя Шепелева
Тестування міграції: свіжий досвід від першої особи, Катя ШепелеваТестування міграції: свіжий досвід від першої особи, Катя Шепелева
Тестування міграції: свіжий досвід від першої особи, Катя ШепелеваSigma Software
 
Работа с требованиями в Интернет стартапе
Работа с требованиями в Интернет стартапеРабота с требованиями в Интернет стартапе
Работа с требованиями в Интернет стартапеAlexander Baikin
 
Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)
Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)
Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)Ontico
 
#1 Chatbots Academy Meetup
#1 Chatbots Academy Meetup#1 Chatbots Academy Meetup
#1 Chatbots Academy MeetupPavel Doronin
 

Mais procurados (12)

разработка dspotapov.ru
разработка dspotapov.ruразработка dspotapov.ru
разработка dspotapov.ru
 
All iso standards available in english and russian (translation) languages, s...
All iso standards available in english and russian (translation) languages, s...All iso standards available in english and russian (translation) languages, s...
All iso standards available in english and russian (translation) languages, s...
 
Когда код «убивает», или зачем нам тестировать наши продукты
Когда код «убивает», или зачем  нам тестировать наши продуктыКогда код «убивает», или зачем  нам тестировать наши продукты
Когда код «убивает», или зачем нам тестировать наши продукты
 
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникаций
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийАлексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникаций
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникаций
 
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?
kranonit S14E02 Серёжа Пономарёв: kranonit’у уже год. Полёт нормальный?
 
Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...
Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...
Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестиро...
 
How to prove programs
How to prove programsHow to prove programs
How to prove programs
 
Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...
Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...
Александр Чистяков, Git in Sky — Современные тенденции в разработке программн...
 
Тестування міграції: свіжий досвід від першої особи, Катя Шепелева
Тестування міграції: свіжий досвід від першої особи, Катя ШепелеваТестування міграції: свіжий досвід від першої особи, Катя Шепелева
Тестування міграції: свіжий досвід від першої особи, Катя Шепелева
 
Работа с требованиями в Интернет стартапе
Работа с требованиями в Интернет стартапеРабота с требованиями в Интернет стартапе
Работа с требованиями в Интернет стартапе
 
Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)
Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)
Работа с требованиями в Интернет-стартапе / Александр Байкин (UML2.ru)
 
#1 Chatbots Academy Meetup
#1 Chatbots Academy Meetup#1 Chatbots Academy Meetup
#1 Chatbots Academy Meetup
 

Semelhante a Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп Дельгядо

Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...
Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...
Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...Ontico
 
Хипстеры в энтерпрайзе
Хипстеры в энтерпрайзеХипстеры в энтерпрайзе
Хипстеры в энтерпрайзеAleksandr Tarasov
 
Как не подавиться большим старым проектом
Как не подавиться большим старым проектомКак не подавиться большим старым проектом
Как не подавиться большим старым проектомAndrey Karpov
 
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019
Как не подавиться большим старым проектом. Юрий Минаев ➠  CoreHard Autumn 2019Как не подавиться большим старым проектом. Юрий Минаев ➠  CoreHard Autumn 2019
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019corehard_by
 
Контроль за качеством кода
Контроль за качеством кодаКонтроль за качеством кода
Контроль за качеством кодаКирилл Борисов
 
Николай Крапивный
Николай КрапивныйНиколай Крапивный
Николай КрапивныйCodeFest
 
Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)
Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)
Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)Dmytro Zharii
 
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Ontico
 
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
 
Egor Fedorov "Behavior-driven development in Python"
Egor Fedorov "Behavior-driven development in Python"Egor Fedorov "Behavior-driven development in Python"
Egor Fedorov "Behavior-driven development in Python"Fwdays
 
Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...
Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...
Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...TrueConf__
 
Room8: Внедрение практик code review как важная составляющая успеха мобильног...
Room8: Внедрение практик code review как важная составляющая успеха мобильног...Room8: Внедрение практик code review как важная составляющая успеха мобильног...
Room8: Внедрение практик code review как важная составляющая успеха мобильног...DevGAMM Conference
 
Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...
Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...
Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...Mail.ru Group
 
My talk at DevParty 2017
My talk at DevParty 2017My talk at DevParty 2017
My talk at DevParty 2017Alex Chistyakov
 
Метрики в бизнесе или алгебра для гармонии
Метрики в бизнесе или алгебра для гармонииМетрики в бизнесе или алгебра для гармонии
Метрики в бизнесе или алгебра для гармонииNikolay Kochnev
 
Что делать, если все надоело или где можно брать силы для работы.
Что делать, если все надоело или где можно брать силы для работы.Что делать, если все надоело или где можно брать силы для работы.
Что делать, если все надоело или где можно брать силы для работы.Aliaksei Minkevich
 
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
 
5 правил успешной разработки приложений для бренда
5 правил успешной разработки приложений для бренда 5 правил успешной разработки приложений для бренда
5 правил успешной разработки приложений для бренда Heads&Hands
 
TDD: Arrange Act Assert на примере Rhino Mocks
TDD: Arrange Act Assert на примере Rhino MocksTDD: Arrange Act Assert на примере Rhino Mocks
TDD: Arrange Act Assert на примере Rhino MocksSerhiy Kalinets
 

Semelhante a Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп Дельгядо (20)

Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...
Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...
Архитектура платежной системы: почти enterprise / Филипп Дельгядо (Информацио...
 
Хипстеры в энтерпрайзе
Хипстеры в энтерпрайзеХипстеры в энтерпрайзе
Хипстеры в энтерпрайзе
 
Как не подавиться большим старым проектом
Как не подавиться большим старым проектомКак не подавиться большим старым проектом
Как не подавиться большим старым проектом
 
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019
Как не подавиться большим старым проектом. Юрий Минаев ➠  CoreHard Autumn 2019Как не подавиться большим старым проектом. Юрий Минаев ➠  CoreHard Autumn 2019
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019
 
Контроль за качеством кода
Контроль за качеством кодаКонтроль за качеством кода
Контроль за качеством кода
 
Николай Крапивный
Николай КрапивныйНиколай Крапивный
Николай Крапивный
 
Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)
Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)
Тесты в стиле BDD на C# (Подходы и инструменты; SpecFlow, BDDfy)
 
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)
 
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...
 
Egor Fedorov "Behavior-driven development in Python"
Egor Fedorov "Behavior-driven development in Python"Egor Fedorov "Behavior-driven development in Python"
Egor Fedorov "Behavior-driven development in Python"
 
Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...
Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...
Развитие ВКС в компании-ритейлере. На примере ООО "Леруа мерлен восток", Алек...
 
Room8: Внедрение практик code review как важная составляющая успеха мобильног...
Room8: Внедрение практик code review как важная составляющая успеха мобильног...Room8: Внедрение практик code review как важная составляющая успеха мобильног...
Room8: Внедрение практик code review как важная составляющая успеха мобильног...
 
Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...
Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...
Что отличает джуниора от сениора или как питонисту не иметь проблем с поиском...
 
My talk at DevParty 2017
My talk at DevParty 2017My talk at DevParty 2017
My talk at DevParty 2017
 
Метрики в бизнесе или алгебра для гармонии
Метрики в бизнесе или алгебра для гармонииМетрики в бизнесе или алгебра для гармонии
Метрики в бизнесе или алгебра для гармонии
 
Что делать, если все надоело или где можно брать силы для работы.
Что делать, если все надоело или где можно брать силы для работы.Что делать, если все надоело или где можно брать силы для работы.
Что делать, если все надоело или где можно брать силы для работы.
 
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...
 
5 правил успешной разработки приложений для бренда
5 правил успешной разработки приложений для бренда 5 правил успешной разработки приложений для бренда
5 правил успешной разработки приложений для бренда
 
TDD: Arrange Act Assert на примере Rhino Mocks
TDD: Arrange Act Assert на примере Rhino MocksTDD: Arrange Act Assert на примере Rhino Mocks
TDD: Arrange Act Assert на примере Rhino Mocks
 
Usability don't make me think
Usability don't make me thinkUsability don't make me think
Usability don't make me think
 

Mais de Ontico

One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
 
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
 
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
 
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
 
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
 
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
 
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
 
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
 
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
 
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
 
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
 
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
 
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
 
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
 
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
 
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
 
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
 
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
 
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
 
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Ontico
 

Mais de Ontico (20)

One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
 
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
 
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
 
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
 
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
 
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
 
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
 
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
 
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
 
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
 
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
 
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
 
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
 
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
 
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
 
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
 
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
 
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
 
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
 
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
 

Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп Дельгядо

Notas do Editor

  1. Руководитель разработки в компании ИТИС, специализируюсь на создании продуктов с нуля и еще долго потом. java, базы данных, сложная логика, нагрузки, надежность и вот это все. В этом докладе я буду рассказывать о особенностях разных стадий продукта.
  2. А, но зачем мне это на BackendConf, тут вам не WhaleRider Я буду говорить о тех вещах, что нужны именно разработчикам.
  3. Сейчас все больше команда принимает организационные и управленческие решения, так что коммуникация, процессы, планирование становятся важным не только для менеджеров, но и для разработчиков. Увы, никогда нельзя надеяться на достаточную компетентность менеджеров и руководителей, часто нужно помочь вашему Scrum master или product manager, а многие вещи в проекте могут сделать и сами разработчики, не надеясь на начальство.
  4. Последние три года я делал платежную систему и заметная часть примеров взята из нашей истории, хот и не все. Ну и перед собственно началом рассказа напомню,
  5. Почти 20 лет назад
  6. Продукт решили делать и вот, вы приступаете к разработке
  7. И да, зачастую - сферического коня. Постановки - обычно высасываются из пальца или, в крайнем случае, подсматриваются у конкурентов Нет точных знаний, как и что делать - и поэтому многие задачи вида "а как бы это могло быть" Нет реальных пользователей Раз нет реальных пользователей, есть ощущение, что все можно просто поменть И вообще - многие вещи кажутся (да и являются) простыми.
  8. Во время разработки даже пилотной версии заметная часть постановок полностью изменится. Проект, задуманный как мировой сервис внезапно станет коробочным решением, в первоначальном списке задач забудут про безопасность, зато будет много про пиковую нагрузку, хотя в реальности важнее окажется безопасность, а нагрузка к старту проекта окажется не столь важной и т.д. Я уж и не говорю про сценарии взаимодействия с пользователем, тонкости бизнес-модели или списка контрагентов для интеграции. Как следствие, самым важным делом на этом этапе оказвается
  9. Ну, кроме собственно разработки. Это те вещи, которые лучше сразу делать хорошо. Расскажем попродробнее о практиках для всех этих действий Работа с требованиями - это отнюдь не задачи аналитика или тимлида. В конце концов, пока вы пишете еще сферический проект в вакууме, вам постоянно приходится принимать решения, которые потом окажутся архитектурными для вашего проекта
  10. Умение задавать вопрос "зачем" - главный инструмент работы с входящими требованиями. Когда вы начнете его практиковать, то на вас будут обижаться, ругаться, негодовать, писать докладные записки, но после десятого раза, когда данный вопрос таки заставил вовремя пересмотреть огромную постановку с съэкономил кучу ресурсов - ругаться начнут спокойнее и скорее "для виду". Благодарности, впрочем, все равно не ждите.
  11. самое частое - это попытка понять, зачем нужна та или иная функциональность, какие задачи пользователя она решает. Как ни странно, даже у знающих scrum менеджеров, описывающих все через пользовательские сценарии зачастую нет ответа, а зачем вообще данный сценарий нужен. Тут могут быть и варианты "а зачем это пользователю", "а точно ли он без этого не обойдется первые пару лет". Вопрос вида "а зачем вообще мы делаем продукт" все-таки считаются неприличными, их лучше не задавать. Этот вопрос и позволяет уменьшить scope разработки и сделает понятным возможные доработки, а зачастую позволяте решать проблемы задолго до его исчезновения. Очень часто после понимания "зачем" становится понятно, что задачу можно решить гораздо проще. Например, вместо попытки придумать, как показать на экране табличку на 100 000 записей, как попросил заказчик, получится показать десяток строк с частичными суммами. Так как все, что ему было надо - это скопировать табличку в эксель и там сделать суммирование по месяцам, например. Точно так же надо не забывать задавать этот вопрос и самому себе - при добавлении в проект новой модной технологии, еще одной библиотеки или инструмента сборки. И помнить, что ответ "я хочу в проекте эту модную библиотеку, потому что с ней проще устроится на новую работу" хотя и правдив, но непрофессионален.
  12. Не надо выписывать завитки на гриве сферического коня в вакууме. Очень часто на этом этапе постановки избыточно точны и универсальны, но при этом не понятно, а нужна ли будет конкретная функциональность кому-бы то ни было. Да, вам хорошо понятно, зачем пользователю подробная история всех его платежей за последние три года в разрезе по годам. Но нет нужды думать, как делать эту задачу, пока у вас вообще нет клиентов с платежами и вы еще далеко от продакшена, первое время достаточно простых решений. И разработчик вполне себе вправе и должен уточнить у постановщика, а зачем делать сложный инструмент с поиском, фильтрацией и рассчитанный на длинную историю еще до выхода на боевые. Очень близок к этому и замечательный принцип
  13. Хотя он уже относится не столько к работе с постановками, сколько к собственно кодированию.
  14. Как бы вам (или постановщику) не хотелось сразу придумать универсальное решение, помните, что прямую можно провести по двум точкам. Я придерживаюсь эмпирического правила - делать общее решение после того, как сделано три частных, иначе все равно придется переделывать, так как реальность всегда богаче наших ожиданий. Ну, например, не надо делать универсального шлюза к платежной системе, пока вы не реализовали хотя бы три разных шлюза с разными требованиями. Так как выяснится, что даже похожие карточные шлюзы внутри предполагают совершенно разные алгоритмы работы, разные протоколы и разную ответственность. После того, как я написал первый вариант "надежной очереди", я честно думал, что он удобен для всех. После третьего сценария ее использования я посмотрел на костыли и переписал все с нуля, зато теперь разработчики гораздо довольнее. Но первых двух из сценариев мне было бы мало.
  15. Это, конечно, универсальный принцип работы, важный не только при работе с требованиями. Лгут не только постановщики, контрагенты, но и вендоры, производители железа, консультанты. Ну и главное - очень часто врете вы сами - себе. Обычно врут не специально. Специалист-бухгалтер будет вам говорить, что проводки после закрытия дня не меняются и только потом вы узнаете, что он хотел сказать "почти никогда не меняются". Контрагент вам скажет, что "платежи проходят в течении рабочего дня" и признает, что бывает и неделя только после того, как вы ему покажете конкретный пример. И так - всегда. Поговорим про архитектуру. "Разработка в вакууме" делает многие вещи достаточно простыми и этим нужно пользоваться
  16. У вас нет уже имеющихся данных, которые нужно мигрировать. Просто изменили таблицы и все.
  17. Пока еще можно двигать ответственность между компонентами или вообще заменить SQL-базу на распределенный кэш, не нужно думать о том, как эти изменения применять на продакшене, цена ошибки пока еще нулевая. И этим нужно пользоваться.
  18. Так что вы можете уговорить дизайнера и продакта поменять UX под более простой или более удобный в текущей архитектуре или успеть поменять идеологию под выбранный UX. Но этой простотой будут пользоваться и постановщики, так что надо быть готовым к изменениям. И этой простотой нужно пользоваться, так как потом, на Вообще, на этапе "работы до продакшена" надо помнить,
  19. Поэтому все эксперементы стоит сделать заранее, пока еще не поздно. Для внешних API дописать хотя бы одну тестовую реализацию и посмотреть, насколько это удобно и понятно Эксперементы с архитектурой провести до выхода в продакшн и понимать, а как она будет меняться Нужно заранее подумать, а как будете менять БД в будущем, что для этого нужно. Это, впрочем, тема отдельного разговора. Аналогично, а как будете поддерживать версии вашего API, можно ли его расширять. Это те вопросы, которые стоит задавать сразу. Именно поэтому на водяной стадии нужно смело менять все вышесказанное, когда это потребуется. Потом уже у вас не будет таких возможностей, так что эксперименты лучше ставить сразу. В водной стадии многое просто - и эта простота таит в себе кучу опасностей
  20. Ну зачем логи, если я могу запустить отладчик в IDE, вон он какой крутой.
  21. Лучше сразу привыкать искать проблемы через логирование.
  22. Да, вы все умные и вас еще мало, вы в проекте с самого начала и вы прекрасно договорились друг с другом, как писать код, что такое хорошо и что такое плохо, зачем вам какие-то документы по этому поводу.
  23. Но потом резко возрастет стоимость коммуникации, а то, о чем не договорились с самого начала - уже не добавить. Да, Code style - это стандартно, но лучше сразу договориться, что "магия" - это плохо, а пятистраничные SQL-запросы - это хорошо. Или наоборот, но единообразно. Если сразу не предусмотрели, то в живой проект добавить статический анализ кода или поддержать "никаких предупреждений компилятора" будет сложно и дорого, это надо делать сразу.
  24. Ну, все же все понимают в системе, если что - быстренько расскажем
  25. Полную документацию писать не всегда нужно, но некотрые базовые вещи лучше описывать сразу. Ну, как минимум для security audit пригодится. Да и при запуске быстрее будет посмотреть на картинку, нежели думать, к чему приведет такой-то сбой. Нужно ловить момент фиксации конкретной компоненеты/сервиса/интерфейса и в этот момент его описать Ну и конечно по максимуму использовать документирование в коде.
  26. Собственно, больше всего документация будет нужна даже не разработчикам, а тем, кто будет эксплуатировать продукт - системным администраторам, dev-ops, третьей линии поддержки и так далее. Хотя проект еще не запущен, уже стоит подумать над тем, как его будут эксплуатировать. И эту задачу нужно держать в голове каждому разработчику
  27. Неплохо бы с ними познакомиться, узнать что их уже беспокоит и что им будет нужно. При создании кода, при проектировании отдельных сервисов нужно думать о администраторах и стараться уменьшить количество проблем. Чем чаще отдельные программисты будут спрашивать и инженеров и системных администраторов "а как для вас проще сделать такую-то настройку" и "а есть ли дырка в firewall между этими двумя сервисами", тем надежнее будет система и тем быстрее будут они отвечать на ваши просьбы. Мы даже название компонент и настроек стараемся согласовывать с эксплуатацией. Нам не сложно, а им приятно.
  28. А если вы еще и картинки нарисуете - они будут счастливы
  29. Даже если все прекрасно работает на тестовом стенде, то на рабочем датаценте будет плохо. Это всем всегда очевидно, но времени на решение проблем обычно никто не выделяет Собственно, при тренировке вам станет понятно, а что нужно написать про все ваши сервисы, что бы было понятно что и как делать.
  30. Есть еще несколько очень хороших практик, которые не так уж и подходят на данном этапе разработки.
  31. На этой стадии процесс разработки довольно прост, хотя и не очень укладывается во многие популярные методологии - задачи в основном длинные, постановки нечеткие и неподробные, показывать зачастую нечего. Это приводит к нескольким рискам
  32. Вы используете процесс, который не соответствуем вашим задачам. на этом этапе даже канбан иногда кажется слишком громоздким и искусственным, зачастую достаточно доски и текущих крупных задач для разработчиков, а иногда и это лишнее. Но если у вас очень простой процесс, возникает соблазн использовать простой трекер типа трелло или ютрека. когда у вас внезапно резко вырастет потребность в инструменте (а это будет как раз незадолго до запуска), переходить на более удобный инструмент уже не будет времени. Лучше возьмите продукт на вырост сразу. Все равно точных и подробных постановок не будет, много исследовательских задач, нет статистики производительности, так что даже процесс декомпозиции не будет иметь особого смысла. Мы обходились понедельным планом по разработчикам на квартал вперед, пересматривали его раз в пару недель и этого вполне хватало для всех задач. При этом средний размер задачи на разработчика составлял 2-4 недели.
  33. Пока не нужны feature-бранчи, показ демо можно делать со сборки по конкретному тегу. Бранчи нужны только если две задачи начинают сильно мешать друг другу
  34. Да, это ужасно, но пока у вас функциональность меняется пять раз на дню, делать полное покрытие тестов слишком дорого. Unit-тестами надо покрывать совсем уж базовые или важные вещи, в остальном обходится интеграционными тестами на основные сценарии. Авторизацию и работу с деньгами надо тестировать максимально качественно сразу, тут вариантов нет. Да и многие сложные вещи вообще не протестировать - у многих платежных систем вообще нет тестового входа, а документация сильно расходится с реальностью, так что даже написанный сложный mock будет полностью бесполезен. Впрочем, тут многое зависит от конкретного выбранного языка ) Да, сейчас у нас есть тестовые имитаторы для некоторых наших контрагентов, но данные для этих тестов собирались дорогой ценой - и в любой момент могут устареть.
  35. А вот то, что делать обязательно - хранить появившийся технический долг. Разработка в вакууме часто приводит к неточным решениям, когда нельзя выбрать оптимальный путь из-за нехватки информации или когда проще было сделать "примерно" из-за "зачем" и "Бережем свой труд". Но все подобные места нужно документировать, что-бы при уточнении постановок не забыать выплачивать технический долг. И этот долг нужно фиксировать в месте, доступном для заказчиков/постановщиков/product owner. Итак, вы закончили с предварительной разработкой и наконец начали запуск
  36. Никакой план не выдерживает столкновения с реальностью, все будет не совсем так, как вы думали. Контрагенты подведут, железо сломается, клиенты повалят валом в самые неподходящие моменты, самый важный человек заболеет, а все инвесторы проявят талант тестеров от бога.
  37. Слишком много суетиться. Будет много разных задач, все будут казаться очень важными. Любой программист будет испытывать огромное давление, все "надо быстро, вчера, почему еще не". В тяжелых случаях вас даже не сможет спасти ваш начальник и над вами будет нависать кто-то из топов. Тут очень важно спокойно работать дальше, по приоритетам.
  38. Обычно перед запуском проходит лихорадка последних доработок и кажется, что ну вот запустимся и отдохнем. Это не так, после запуска первое время будет только сложнее. Так что нужно попробовать отдохнуть - договорится о дополнительном отгуле с начальством (скорее всего вас поймут) или просто не планировать "доработать" на выходных за день перед выпуском на продакшене. Мы запускались почти сразу после Нового Года, так что все успели отдохнуть. Но не всегда так получается.
  39. За время запуска вы понаделаете кучу костылей и нужно время и силы для их упорядочивания. Да, нужны новые фичи, но если не перевести дух и не вернуть часть долга, то проект не выйдет из вечного пике. Нужно заранее об этом помнить, не брать на себя лишних обязательств, а хорошо бы и заранее договориться об отпуске или паузе в задачах.
  40. Самое важное, на мой взгляд, в процессе запуска - это организация процесса. Да, по идее это ответственность менеджмента, тим-лидов, но многое могут программисты сделать сами - что бы им самим было легче жить.
  41. Например, составить график дежурств. Во время запуска часто что-то ломается или нужно сделать выкладку поздно вечером. Желательно заранее договориться, кто и когда может задержаться на работе. Тогда не выяснится, что одному ведущему программисту именно сегодня нужно забирать ребенка со школы, а у другого годовщина свадьбы. Просто на доске напишите, кто когда может на этой неделе задержаться. В особо запущенных проектах можно не сообщать эти информацию менджменту, так как возможность задержаться совсем не то же, что и желание это сделать. Мы вот такое не сделали, что привело пару раз к большому огорчению пары человек, которым пришлось менять планы
  42. Гораздо проще внезапные проблемы в субботу вечером исправлять из дома, а не из офиса. Так что стоит заранее обеспечить себя возможностью доступа из дома. Договорится с службой безопасности, поднять удаленные рабочие столы и VPN, проверить работоспособность системы. Заодно, раз уж и так из дома работать можно, сможете в будущем этим пользоваться - ну, когда вызвали сантехника. Почему то об организации доступа из дома постоянно забывают до самого последнего момента
  43. У вас будут довольно сложные дни и неплохо бы для себя решить, а зачем вам вообще надо спасать проект по вечерам. Может, вы рассчитываете на премию? Или хотите накопить пару выходных к отпуску? Или вам важно уважение коллег. Очень полезно довести это до вашего тим-лида или проджекта, просто что бы он заранее запланировал для вас фонд на премии или подумал, как красиво презентовать ваш героизм для высокого начальства. Да и вам будет проще работать по субботам, если вы понимаете, зачем вы это делаете. Организация процесса затронет и используемые инструменты
  44. Разработке надо уметь видеть, что происходит. Мониторинга недостаточно, логи часто малодоступны и медлительны, к БД или сервисам прямого доступа нет (и правильно). Нужен свой арм, который может показать важные для разработки "кишки" системы. Лучше бы его начать делать заранее, но точно понятно, что нужно - обычно в тот момент, когда потребуется. Поэтому АРМ должен быть простой для доработок, без изысков и без лишних выкрутасов. И постоянно дорабатываться. Наш, например, розовенький и с hello kitty, что бы было приятнее им пользоваться
  45. В нем, например, можно посмотреть параметры операций as-is, в точности как они хранятся в СУБД, состояние очередей и многое другое. И нас не пугает вывод данных прямо в json, чем меньше преобразований - тем лучше. И в нем ничего нельзя сделать, только read only.
  46. Если раньше вы смотрели только на задачи для разработки и трекер использовался в основном для багов, то сейчас появятся (или вы сами сделаете) отдельные трекеры для инцидентов и для эксплуатации. И вам очень нужно заранее получить доступ к этим трекерам, что бы не узнавать о происходящем из слухов.
  47. Вам нужно будет оперативно обсуждать происходящее, причем зачастую из метро, на ходу и т.д. Впрочем, зачем нужен Slack или Telegram особенно объяснять не нужно. Но вот сделать чатик отдельно для обсуждения проблем без участия менеджеров - полезно, уменьшает суету и спасает от нетехнических вопросов. Ну и добавьте в свои контакт-листы всех, кто вам будет нужен заранее - поддержку, девопсов, сетевиков - всех, кто может понадобиться.
  48. Знать, что на самом деле он меряет и как. Очень часто это не совсем очевидно. Например, мы долго не могли понять, что у нас происходит с числом платежей, пока не вспомнили, что Prometheus усредняет и интерполирует значения и вместо прямой может быть гребенка И как именно считается в вашем мониторинге доступная память или успешность операции. Но главный инструмент (не только на этой стадии, но тут - особенно) это люди
  49. Так что надо по мере сил заботится и беречь. Запуск - именно то время, когда CTO бегает за кофе и пиццой для разработчиков, пока они чинят проблемы на продакшене (и, кстати, да, у нас и СТO и начальник разработки ходили в магазин за едой для программистов). Но кроме этого помните и о всех, с кем общаетесь - о эксплуатации, поддержке, пользователях. Запуск - очень нервное время, когда легко сорваться и поругаться. Лучше до этого не доводить. В крайнем случае - попросите купить грушу или хотя бы дартс. И почаще ходите вместе выпить пиво. Еще забытые герои процесса запуска - поддержка Те люди, что отвечают реальным пользователям и помогают с их проблемами
  50. Узнайте, кто и как там работает, кто что умеет, у кого какие знания Поддержка - это и важнейший инструмент понимания "зачем" и лучший индикатор проблем и источник самых неприятных сообщениий о багах и инцидентах. Заодно расскажите им о известных вам кусочках системы, что и как и почему работает. Очень часто ваши рассказы откроют им глаза на многие проблемы.
  51. Вроде бы вам это не важно, и скрипты общения с пользователями - не дело разработки, но лучше попробовать с ними разобраться. Хотя бы вы будете уверены, что у пользователя спросят версию браузера или модель смартфона и вам не придется через неделю поисков выяснить, что проблема была под старой оперой-мини на мобильной джаве на телефоне 10-летней давности.
  52. Не всегда будет время подробно разобраться, зачем нужно то или иное изменение, так что нужно достаточно им поверить, что бы (иногда) просто быстро делать то, что просят. И чем больше вы им рассказываете и с ними общаетесь, тем проще будет верить их данным по поведению пользователя или замеченной проблеме. О процессе. Процесс при процессе внедрения стоит подбирать под конкретную вашу специфику. Обычно тут короткое планирование, четкие задачи.
  53. У нас фактически был SCRUM, со всеми его атрибутами.
  54. Но с размером спринта в один день. Утром распределяли задачи, в середине дня делали демо, вечером выкладывали фикс и делали ретроспективу И так несколько недель. Разумеется, кто-то продолжал работать надо долгосрочными задачами, но в отдельных бранчах И вот мы наконец запустились
  55. Про эту стадию рядом целая конференция и куча книжек
  56. И все, что я уже успел рассказать – вам опять пригодится Но расскажу еще о нескольких практиках, которые мы у себя активно применяем
  57. Почему-то, хотя все знают про этот принцип, его все время забывают и я много раз видел, как после долгого выпиливания отдельного проекта выясняется, что он уже мало совместим с общей кодовой базой и его надо полностью переделывать. Особенно проблематично, когда большую задачу делают аутсорсеры. Большие задачи делаем и выкладываем кусочками, в единицы человекодней. Не всегда выходит, но минимальные риски для выживания системы. Вот сейчас внедрение асинхронной шины на кафке начниаем с дальнего угла системы
  58. Код должно быть удобно читать и ревьюить. Для этого должна работать навигация по коду из IDE. Это довольно сильно ограничивает в использовании библиотек, как ни странно. И заставляет писать внутри довольно сложные вещи. Но часто спасает. Язык со статической типизацией вообще много что позволяет сделать до запуска кода )
  59. Мы не доверяем технологиям, про которые непонятно, как они работают, никакой магии. В крайнем случае наймем внешних профи (например, для присмотра за СУБД). Кстати, именно поэтому мы не используем, например, ORM.
  60. Все тестируется у программиста А это значит, что система должна быть разворачиваема у программиста. Но не уверен, что эта практика переживет еще год Тот, кто отвечает за качество продукта только и может говорить, что и когда можно выкладывать.
  61. YouTrack - это как раз слишком простой инструмент, выбранный в начале проекта. Думаем о миграции на Jira, но процесс медленный Git - грустно, но куда деваться Confluence - наконец догнал по возможностям версию 3.5, хотя языка разметки не хватает. Но все еще лучшая wiki TeamCity - пока устраивает как система сборки Telegram - очень не хватает нормальной адресной книги