Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Что делать, когда костыли уже не помогают. Опыт tutu.ru / Роман Грунтович (tutu.ru)

485 views

Published on

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

Можно решать эти проблемы, двигаясь небольшими шагами, внося улучшения постепенно. Альтернативный вариант — все стереть и написать заново. На это тяжело решиться, ведь требуется выделить ресурсы, которых всегда не хватает. Также есть риск навредить уже работающему продукту. Однако, мы решились и в своем докладе я расскажу:

- Что такое реинжиниринг и зачем он был нужен в tutu.ru.
- Как мы подошли к выбору нового технологического стека.
- Как мы выбрали архитектуру новых приложений.
- Почему мы пришли к TypeScript и React.
- Шаблонизатор для компонентов Reactа, серьезно?
- Выкидывать legacy код жестоко, но нужно же с ним что-то делать.
- Как удовлетворить seo без лишних усилий.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Что делать, когда костыли уже не помогают. Опыт tutu.ru / Роман Грунтович (tutu.ru)

  1. 1. Что делать, когда костыли уже не помогают? Грунтович Роман Туту.ру
  2. 2. 230сотрудников 13.5 млнпосетителей в месяц 2003год основания 600 тыспосетителей в день О Туту.ру Авиабилеты Ж/д билеты Туры Гостиницы Электрички 8 млнстрок кода
  3. 3. Предпосылки • Постоянно меняющиеся внешние факторы • Рост количества сотрудников
  4. 4. Проблемы • Дорогая поддержка системы • Снижение темпов развития
  5. 5. Летний поезд Ожидания бизнеса Реальность
  6. 6. Наследие full-stack разработки
  7. 7. Метрика качества кода
  8. 8. Нужно что-то менять!
  9. 9. 1. Переписываем последовательно модуль за модулем 2. … 3. Profit! Первый подход
  10. 10. Проблемы этого подхода • Нужно больше ресурсов, чем предполагалось • Нет фокуса на конечной цели
  11. 11. Второй подход: реинжиниринг 1. Делаем новую систему с нуля 2. … 3. Profit!
  12. 12. Требования к новой системе • Получить платформу для быстрого развития • Выдавать результаты поэтапно • Не навредить работающему продукту • Не навредить позициям в поисковиках • Сохранить прибыльность
  13. 13. Принципы новой платформы • Используется компонентный подход • Бэкенд отделен от фронтенда
  14. 14. ES6, модули, классы Возможные решения: • TypeScript • babel
  15. 15. Архитектура приложений Компонент
  16. 16. Архитектура приложений Модель Компонент
  17. 17. Архитектура приложений Модель АдаптерКомпонент
  18. 18. Архитектура приложений Модель Адаптер Компонент Контроллер
  19. 19. На чем писать компоненты? Варианты решений: • Angular • ReactJS • Vue.js • Ractive.js • Mithril
  20. 20. Критерии выбора • Порог входа • Быстродействие • Поддержка браузеров (IE8+)
  21. 21. У нас есть JSX, зачем шаблонизатор?! • Отделение верстки от логики компонентов • Низкий порог входа для верстальщиков
  22. 22. React-templates
  23. 23. Что делать с legacy? Переписать нельзя оставить
  24. 24. Как не навредить seo • Не делать индексируемых страниц • Научиться рендерить индексируемые на сервере
  25. 25. Варианты для SSR • twig + twigJS • NodeJS • php V8Js
  26. 26. Этапы разработки
  27. 27. Цикл разработки Аналитика
  28. 28. Цикл разработки Аналитика Разработка
  29. 29. Цикл разработки Аналитика РазработкаТестирование
  30. 30. Цикл разработки Аналитика Разработка Тестирование А/Б тестирование
  31. 31. Команда • 1 ПО • 2 бэкендера • 2 фронтендера • 1 тестировщик • 1 ПО • 3 бэкендера • 4 фронтендера • 3 тестировщика
  32. 32. Итоги Получили платформу для быстрого развития Результаты получаем поэтапно Не навредили работающему продукту Не навредили позициям в поисковиках Сохранили прибыльность
  33. 33. Схемы вагонов СталоБыло дизайнер верстальщик разработчик дизайнер Человеко-неделя 4 человеко-часа 25 схем 56 схем
  34. 34. Нам помогли: • Компонентный подход • Итеративность • Прагматичность • Стремление к цели У нас была тактика и мы ее придерживались 
  35. 35. Грунтович Роман gruntovich@tutu.ru

×