SlideShare a Scribd company logo
1 of 35
Багаті спадкоємці, або як робити
рефакторинг в продукті з
бурхливою історією
Бричук Олександр
Head of IT Department UniSender
● Розробник сервісу email і sms розсилок.
● На ринку з 2008 року.
● В березні 2017 через нас було успішно
доставлено трішки більше 600млн
листів.
● ... ми не розсилаємо спам.
2
Рефакторинг
• контрольований процес покращення коду, який не має на меті
написання нової функціональності.
• його результатом являється чистий і зрозумілий код.
ще раз - контрольований і ітеративний процес
покращення коду
3
Як зрозуміти, що потрібно щось
міняти?
● кількість помилок в Jira постійно збільшується
● коли повторюється ситуація з картинки
● коли витрачений час більший за оцінений
● коли новий програміст звільняється в перший же день із
фразою: “Ваш код лайно” (правдива історія)
● коли виправлення однієї проблеми породжує нову
● коли програмісти уже не хочуть іти на компроміси із
менеджером
4
З рефакторингом є такі штуки
1. Погано продається
◦ в рамках обмеженого часу і бюджету економіка завжди виграє
◦ код мало кого цікавить. задача програміста вирішувати бізнесові потреби.
◦ як пояснити технічно не підкованій людині, що отут от так собі рішення і його варто
переробити?
2. Бізнесу важко буде перевірити результат в моменті
3. Чому б з самого початку не зробити якісно?
5
З рефакторингом є такі штуки
1. Погано продається
2. Бізнесу важко буде перевірити результат в моменті
◦ він відчутний тільки для програмістів. такі справи…
◦ якісний код легко піддається модифікації
◦ він покритий тестами
◦ нова функціональність додається легко
◦ нова функціональність не ламає стару
◦ його легко підтримувати
◦ легко перевести на інший стек технологій або мову програмування
3. Чому б з самого початку не зробити якісно?
6
З рефакторингом є такі штуки
1. Погано продається
2. Бізнесу важко буде перевірити результат в моменті
3. Чому б з самого початку не зробити якісно?
◦ код як і продукт живий
◦ часто міняються люди
◦ погана комунікація в команді
◦ відсутність стандартів і документації
◦ недостатня кваліфікація кадрів
◦ тиск з боку замовника
◦ нові нові фічі, які додають складність в розуміння продукту
7
Як визначає якість продукту
клієнт
8
Добре
спроектований
програмний продукт
Погано
спроектований
програмний продукт
Під капотом
це все не помітно
Класний дизайн
Зручність у
використанні
Адаптивність
Ефективність Надійність Гнучкість
Навіщо платити більше ?
Поганий “дизайн”
● обмежує продукт в розвитку
● зв’язує руки програмістам
● уповільнює ріст бізнесу
● ресурси інвестуються
не в розвиток
● збільшується плин кадрів
9
Рефакторинг - це інвестиція в
майбутнє
● Не дає миттєвого результату.
● Закладає фундамент для
швидшої розробки.
● В середньо терміновій перспективі
продукт стане простіше розвивати.
● Може бути цікавим програмістам, а
значить меньше навантаження на HR.
Для ІТ - показник здорового інтересу
бізнеса до продукту.
Картинка з https://martinfowler.com/bliki/DesignStaminaHypothesis.html
10
11
Як продав ?
● 64% багів
● 23% критичних
● ріст покриття тестами не зменшував кількості помилок
● відношення заведених багів до виправлених 602/329 (за 2015 рік)
● 2 жорстких падіння сервісу в період black friday і перед новим роком
● після чого від нас почали іти клієнти
● довіра між бізнесом і ІТ. Якщо у вас самих немає бачення, як виправити ситуацію в
конкретних кроках, ви не зможете переконати.
з нуля ?
12
Ви можете написати з нуля якщо
● у вас багато грошей і часу
● ви впевнені в тому, що ви краще спроектуєте систему ніж
попередній архітектор
● ви плануєте регулярно отримувати зворотній зв’язок від
користувачів
● ви впораєтеся з тим, щоб підтримувати 2 системи
одночасно
● ви провели дослідження старої системи і у вас є достатньо
впевненості, що переписати буде простіше і швидше
● ви впевнені в тому, що в процесі не буде втрачено
функціоналу
● ви згодні на те, що нова версія може принести нові
проблеми користувачам
13
Еволюція чи революція
Переписати з нуля це як революція, коли рефакторинг - це еволюція.
Революція - страшна штука. Ніколи не відомо чим усе закінчиться.
14
З рефакторингом простіше, з ним ви адаптуєтеся до нових умов.
Контрольований процес
15
Контрольований процес
● вибирається місце, яке потрібно “вилікувати”
● визначається відповідальний(і) за процес
● визначаємо рівень занурення
● test coverage
● при відсутності/не достатньому
покритті - додати тести
● code-review
● code style
16
Як з’їсти слона
17
Ітеративний процес
Чому маленькими кроками?
Необхідний план
● можна легко зупинитися при потребі
● поступове занурення не шкідливе
● частіше дає ефект досягнутого результату
● легше тримати контекст в голові
● простіше робити код-ревью
● колеги на вас не злі, коли зливають ваші зміни
18
19
Якщо вони змогли
побудувати колайдер
То і ви зможете
проштовхнути
рефакторинг
20
Приклад №1. “Проблема” із
статистикою
21
На початкових етапах становлення продукту була лише 1 БД.
В 2013 році її розмір уже доходив до 2ТБ.
Найбільше місця займають результати доставки листів. Дорогий сервер з особливою конфігурацією:
SSD + багато RAM + Intel Xeon.
В коді повсюду використовується підхід Active Record, без використання репозиторіїв і інтерфейсів.
По кодовій базі це було 97 різних методів доступа до цих даних за допомогою AR.
22
23
Рішення № 1. Тимчасове.
● “А давайте видаляти старі дані!”. Так і жили певний
час.
● написали код міграції даних із 1 БД в іншу
● старі дані інколи потрібні користувачам
● стало краще, але ненадовго
Результат: Прийшло ще більше користувачів,а ми
більше не поміщаємося на 1 сервері.
24
Рішення № 2. Шардінг.
Проблеми:
● це надовго (слайд #21)
● деякі патерни доступа до даних вимагають до себе пристальної уваги
Не страшно:
1. Проаналізували всі місця в коді де є доступ до цих даних і зафіксували в документі
2. Визначили типи доступа до даних. Щоб простіше було, дали всім 97 місцям назви, так як ніби це були
методи якогось класу.
3. В процесі частина коду була позначена, як кандидат на видалення - уже не актуальна
функціональність.
4. Пріоритезували функціональність із п.2 і поставили оцінку по важкості реалізації.
5. Згрупували схожі методи доступа до даних - їх вийшло 21.
6. Зробили інтерфейс api.
7. Почали з самого простого. Всього вийшло 7 високорівневих Jira-тікетів.
Весь процес зайняв майже рік часу. Відкатів не було, але в релізні дні інколи доводилося сидіти і правити по
живому.
25
Що було в процесі ?
1. 7 етапів виявилося замало, код встигав
швидше мінятися ніж його встигали
рефакторити. Кращим був би підхід, як
рекомендують дієтологи: “Краще менше, але
частіше”
2. Через великий об’єм внесених змін важкі код-
ревью
3. Через це регулярні проблеми при мерджах
4. Нещасливий відділ тестування
26
Приклад №2. Рефакторинг на мікросервіси
27
Як відправити розсилку на
3млн адресатів за
адекватний час?
Можна отак:
Можна але не довго
● складний код. багато різних нюансів.
● smtp часто відвалюються, чи їх тимчасово блокують.
● усе це погано масштабується.
● працює добре тільки на малих навантаженнях.
● туди страшно заглядати.
Давайте ізолюємо роботу із SMTP в окремому середовищі, а дамо
назовні API.
28
Ура! перший мікросервіс
29
Стало простіше і трохи швидше
● з’явилося API
● компіляція листів переїхала із “повільного” PHP в “швидку” Java
● взаємодія із SMTP ізольована в мікросервсі, PHP команда вздихає з полегшенням
● можна масштабувати швидкість відправки новими SMTP і Java залізяками
● тепер PHP не може нагрузити
● основна БД все ще точка відмови. ми лише скоротили процес
● максимальна швидкість відправки 70-90тис листів в секунду
30
31
Рішення мікросервіс відправки (Sender
Service)
● не залежить від моноліта і основної БД.
● написаний на PHP 7.
● має здатність до маштабування.
● має API.
● швидкий.
На даний момент пік це 500тис листів за хвилину.
Розсилку в 3млн можна відправити за 6хв.
32
Деякі загальні
побажання
● Не рафакторингом єдиним.
● У нас тільки частина людей цим займається.
● Користувач продукту не пробачить того, що не виходять нові
релізи.
● Кожній компанії потрібно знайти свій баланс між фічами і
внутрішніми покращеннями.
● Оптимальний розмір команди 2-3 розробника, 1 QA.
● YAGNI, SOLID, KISS, CQRS і т.д. роблять “світ” кращим.
● керуйтеся принципом бойскаутів
● пишіть так, як ніби підтримку вашого коду мав би робити
психопат, який знає вашу адресу
33
Старайтеся не накопичувати
технічний борг
● закладайте час при розробці нової функціональності, вам
будуть вдячні, ті хто після вас туди заглядатиме
● коли виправляєте помилки
● під час код-ревью, це буде дешевше ніж на пізніших етапах
● коли вже не вперше доводиться робити, якусь подібну штуку
● коли маєте справу із успадкованим кодом
● кожне “тимчасове” рішення фіксуйте тікетами (коментарів
TODO не достатньо)
34
Почитати
35
...все одно не видно
краще пишіть та інтегруйтеся:
Бричук Олександр
obrychuk@unisender.com
https://techbeacon.com/17-opinions-resources-rewrites-vs-refactoring
https://refactoring.guru/ru/refactoring/catalog
https://meekrosoft.wordpress.com/2010/10/31/internal-and-external-software-quality/
https://medium.com/@joaomilho/festina-lente-e29070811b84
https://www.entropywins.wtf/blog/2016/11/24/implementing-the-clean-architecture/
https://habrahabr.ru/post/150027/
https://habrahabr.ru/post/169139/
http://www.ozon.ru/context/detail/id/1308678/
http://www.yakaboo.ua/sovershennyj-kod-master-klass.html

More Related Content

What's hot

Основні метрики юзабіліті тестування
Основні метрики юзабіліті тестуванняОсновні метрики юзабіліті тестування
Основні метрики юзабіліті тестування
Yuri Ternytsky
 
Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
  Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”  Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
Lviv Startup Club
 

What's hot (13)

Основні метрики юзабіліті тестування
Основні метрики юзабіліті тестуванняОсновні метрики юзабіліті тестування
Основні метрики юзабіліті тестування
 
СВІТЛАНА ПРИШЛЯК «Тестування управління процесами на різних рівнях в компанія...
СВІТЛАНА ПРИШЛЯК «Тестування управління процесами на різних рівнях в компанія...СВІТЛАНА ПРИШЛЯК «Тестування управління процесами на різних рівнях в компанія...
СВІТЛАНА ПРИШЛЯК «Тестування управління процесами на різних рівнях в компанія...
 
Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
  Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”  Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
Ілона Кулинич “Маленький Скрам проти Великого Вотерфолу: історія одного ПМа”
 
Vinnytsky
VinnytskyVinnytsky
Vinnytsky
 
Планування та менеджмент проектів в М1
Планування та менеджмент проектів в М1Планування та менеджмент проектів в М1
Планування та менеджмент проектів в М1
 
Sergey potapov
Sergey potapov Sergey potapov
Sergey potapov
 
How to get MAXIMUM from estimates (UKR)
How to get MAXIMUM from estimates (UKR)How to get MAXIMUM from estimates (UKR)
How to get MAXIMUM from estimates (UKR)
 
Agile Feedback Loops (ukr)
Agile Feedback Loops (ukr)Agile Feedback Loops (ukr)
Agile Feedback Loops (ukr)
 
DaKiRY_BAQ2016_QADay_Світлана Мережко "Що від вас очікують? Чек-ліст відповід...
DaKiRY_BAQ2016_QADay_Світлана Мережко "Що від вас очікують? Чек-ліст відповід...DaKiRY_BAQ2016_QADay_Світлана Мережко "Що від вас очікують? Чек-ліст відповід...
DaKiRY_BAQ2016_QADay_Світлана Мережко "Що від вас очікують? Чек-ліст відповід...
 
Посада Project manager в it компанії
 Посада Project manager в it компанії Посада Project manager в it компанії
Посада Project manager в it компанії
 
Як найняти 
cкрам команду
Як найняти 
cкрам командуЯк найняти 
cкрам команду
Як найняти 
cкрам команду
 
Головні Принципи Автоматизації
Головні Принципи АвтоматизаціїГоловні Принципи Автоматизації
Головні Принципи Автоматизації
 
Планування та менеджмент проектів в MagneticOne
Планування та менеджмент проектів в MagneticOneПланування та менеджмент проектів в MagneticOne
Планування та менеджмент проектів в MagneticOne
 

Similar to Багаті спадкоємці, або як робити рефакторинг у продукті з бурхливою історією. Олександр Бричук

Similar to Багаті спадкоємці, або як робити рефакторинг у продукті з бурхливою історією. Олександр Бричук (20)

Документація великих проектів
Документація великих проектівДокументація великих проектів
Документація великих проектів
 
Automation as a Way to Do Routine Work Quickly and Effortlessly
Automation as a Way to Do Routine Work Quickly and EffortlesslyAutomation as a Way to Do Routine Work Quickly and Effortlessly
Automation as a Way to Do Routine Work Quickly and Effortlessly
 
Nikita Zahurdaiev: Найдієвіші методології для PMO (UA)
Nikita Zahurdaiev: Найдієвіші методології для PMO (UA)Nikita Zahurdaiev: Найдієвіші методології для PMO (UA)
Nikita Zahurdaiev: Найдієвіші методології для PMO (UA)
 
Нікіта Загурдаєв - Найдієвіші методології для PMO
Нікіта Загурдаєв - Найдієвіші методології для PMOНікіта Загурдаєв - Найдієвіші методології для PMO
Нікіта Загурдаєв - Найдієвіші методології для PMO
 
How to Leverage your Skill Set for Product by Matic PM
How to Leverage your Skill Set for Product by Matic PMHow to Leverage your Skill Set for Product by Matic PM
How to Leverage your Skill Set for Product by Matic PM
 
cpp-2013 #3 OOP Basics
cpp-2013 #3 OOP Basicscpp-2013 #3 OOP Basics
cpp-2013 #3 OOP Basics
 
Корнілов Андрій
Корнілов АндрійКорнілов Андрій
Корнілов Андрій
 
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»
 
Marafon_part1 (1).pptx
Marafon_part1  (1).pptxMarafon_part1  (1).pptx
Marafon_part1 (1).pptx
 
Alexey Siniavtsesv "Exploratory testing: discover critical issues before they...
Alexey Siniavtsesv "Exploratory testing: discover critical issues before they...Alexey Siniavtsesv "Exploratory testing: discover critical issues before they...
Alexey Siniavtsesv "Exploratory testing: discover critical issues before they...
 
Global logic tech talk switching to Angular.js
Global logic tech talk switching to Angular.jsGlobal logic tech talk switching to Angular.js
Global logic tech talk switching to Angular.js
 
Павло Юрійчук — Перехід на Angular.js. Howto
Павло Юрійчук — Перехід на Angular.js. HowtoПавло Юрійчук — Перехід на Angular.js. Howto
Павло Юрійчук — Перехід на Angular.js. Howto
 
Роман Сахаров "Зміна Scope спринту посередині розробки: хто винен і що робити?"
Роман Сахаров "Зміна Scope спринту посередині розробки: хто винен і що робити?"Роман Сахаров "Зміна Scope спринту посередині розробки: хто винен і що робити?"
Роман Сахаров "Зміна Scope спринту посередині розробки: хто винен і що робити?"
 
Віталій Подоба. “Складний Кейс: Віддалений, Між-Часовий, Part-Time менеджмент”
Віталій Подоба. “Складний Кейс: Віддалений, Між-Часовий, Part-Time менеджмент”Віталій Подоба. “Складний Кейс: Віддалений, Між-Часовий, Part-Time менеджмент”
Віталій Подоба. “Складний Кейс: Віддалений, Між-Часовий, Part-Time менеджмент”
 
Dmytro Khudenko: Challenges of implementing task managers in the corporate an...
Dmytro Khudenko: Challenges of implementing task managers in the corporate an...Dmytro Khudenko: Challenges of implementing task managers in the corporate an...
Dmytro Khudenko: Challenges of implementing task managers in the corporate an...
 
Презентація професії "Оператор комп'ютерного набору"
Презентація професії "Оператор комп'ютерного набору"Презентація професії "Оператор комп'ютерного набору"
Презентація професії "Оператор комп'ютерного набору"
 
"Laravel Tips & Tricks - 7 Steps to Dramatically Improve Performance", Yehor ...
"Laravel Tips & Tricks - 7 Steps to Dramatically Improve Performance", Yehor ..."Laravel Tips & Tricks - 7 Steps to Dramatically Improve Performance", Yehor ...
"Laravel Tips & Tricks - 7 Steps to Dramatically Improve Performance", Yehor ...
 
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
КАТЕРИНА ЖУПАН «Mobile Testing based on “ISTQB Mobile Application – Syllabus»
 
DaKiRy_PMWeekend2016_Роман Сахаров "Як відсутність бачення продукту псує прое...
DaKiRy_PMWeekend2016_Роман Сахаров "Як відсутність бачення продукту псує прое...DaKiRy_PMWeekend2016_Роман Сахаров "Як відсутність бачення продукту псує прое...
DaKiRy_PMWeekend2016_Роман Сахаров "Як відсутність бачення продукту псує прое...
 
Oleksandr Brychuk "UniSender architecture. Growth from 100kk to 1.5kkk letter...
Oleksandr Brychuk "UniSender architecture. Growth from 100kk to 1.5kkk letter...Oleksandr Brychuk "UniSender architecture. Growth from 100kk to 1.5kkk letter...
Oleksandr Brychuk "UniSender architecture. Growth from 100kk to 1.5kkk letter...
 

More from HOWWEDOIT

Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук
Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук
Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук
HOWWEDOIT
 
Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....
Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....
Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....
HOWWEDOIT
 

More from HOWWEDOIT (15)

Прогнозирование на SQL с помощью GBQ ML
Прогнозирование на SQL с помощью GBQ MLПрогнозирование на SQL с помощью GBQ ML
Прогнозирование на SQL с помощью GBQ ML
 
GCP для работы с большими данными
GCP для работы с большими даннымиGCP для работы с большими данными
GCP для работы с большими данными
 
Как боты помогают Monobank обслуживать более 800 тысяч клиентов
Как боты помогают Monobank обслуживать более 800 тысяч клиентовКак боты помогают Monobank обслуживать более 800 тысяч клиентов
Как боты помогают Monobank обслуживать более 800 тысяч клиентов
 
Difficulties of implementing AI Features to an established product company
Difficulties of implementing AI Features to an established product companyDifficulties of implementing AI Features to an established product company
Difficulties of implementing AI Features to an established product company
 
"Оптимальные цены", или как повысить розничные продажи с помощью машинного об...
"Оптимальные цены", или как повысить розничные продажи с помощью машинного об..."Оптимальные цены", или как повысить розничные продажи с помощью машинного об...
"Оптимальные цены", или как повысить розничные продажи с помощью машинного об...
 
Построение ROPO отчетов. Или как оценить вклад он-лайн рекламы в офф-лайн про...
Построение ROPO отчетов. Или как оценить вклад он-лайн рекламы в офф-лайн про...Построение ROPO отчетов. Или как оценить вклад он-лайн рекламы в офф-лайн про...
Построение ROPO отчетов. Или как оценить вклад он-лайн рекламы в офф-лайн про...
 
Лайфхаки построения мощной продуктовой sales-команды. Катерина Мартынова, Pre...
Лайфхаки построения мощной продуктовой sales-команды. Катерина Мартынова, Pre...Лайфхаки построения мощной продуктовой sales-команды. Катерина Мартынова, Pre...
Лайфхаки построения мощной продуктовой sales-команды. Катерина Мартынова, Pre...
 
Кастомные решения, best practices для управления и увеличения продаж. Олег Бе...
Кастомные решения, best practices для управления и увеличения продаж. Олег Бе...Кастомные решения, best practices для управления и увеличения продаж. Олег Бе...
Кастомные решения, best practices для управления и увеличения продаж. Олег Бе...
 
Продвинутые методики продуктовых отделов продаж с практическими примерами. Ан...
Продвинутые методики продуктовых отделов продаж с практическими примерами. Ан...Продвинутые методики продуктовых отделов продаж с практическими примерами. Ан...
Продвинутые методики продуктовых отделов продаж с практическими примерами. Ан...
 
ClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
ClickHouse как решение для бизнес аналитики. Дмитрий КузьминClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
ClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
 
Подход и инструменты измерения эффективности процесса разработки или как держ...
Подход и инструменты измерения эффективности процесса разработки или как держ...Подход и инструменты измерения эффективности процесса разработки или как держ...
Подход и инструменты измерения эффективности процесса разработки или как держ...
 
Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук
Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук
Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук
 
Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....
Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....
Построение и переход на новую аналитическую платформу. Цели, вызовы, решения....
 
метрики ценообразования как интернет магазины используют цены конкурентов.але...
метрики ценообразования как интернет магазины используют цены конкурентов.але...метрики ценообразования как интернет магазины используют цены конкурентов.але...
метрики ценообразования как интернет магазины используют цены конкурентов.але...
 
Визуализируй меня полностью. Павел Лоба.
Визуализируй меня полностью. Павел Лоба.Визуализируй меня полностью. Павел Лоба.
Визуализируй меня полностью. Павел Лоба.
 

Багаті спадкоємці, або як робити рефакторинг у продукті з бурхливою історією. Олександр Бричук

  • 1. Багаті спадкоємці, або як робити рефакторинг в продукті з бурхливою історією Бричук Олександр Head of IT Department UniSender
  • 2. ● Розробник сервісу email і sms розсилок. ● На ринку з 2008 року. ● В березні 2017 через нас було успішно доставлено трішки більше 600млн листів. ● ... ми не розсилаємо спам. 2
  • 3. Рефакторинг • контрольований процес покращення коду, який не має на меті написання нової функціональності. • його результатом являється чистий і зрозумілий код. ще раз - контрольований і ітеративний процес покращення коду 3
  • 4. Як зрозуміти, що потрібно щось міняти? ● кількість помилок в Jira постійно збільшується ● коли повторюється ситуація з картинки ● коли витрачений час більший за оцінений ● коли новий програміст звільняється в перший же день із фразою: “Ваш код лайно” (правдива історія) ● коли виправлення однієї проблеми породжує нову ● коли програмісти уже не хочуть іти на компроміси із менеджером 4
  • 5. З рефакторингом є такі штуки 1. Погано продається ◦ в рамках обмеженого часу і бюджету економіка завжди виграє ◦ код мало кого цікавить. задача програміста вирішувати бізнесові потреби. ◦ як пояснити технічно не підкованій людині, що отут от так собі рішення і його варто переробити? 2. Бізнесу важко буде перевірити результат в моменті 3. Чому б з самого початку не зробити якісно? 5
  • 6. З рефакторингом є такі штуки 1. Погано продається 2. Бізнесу важко буде перевірити результат в моменті ◦ він відчутний тільки для програмістів. такі справи… ◦ якісний код легко піддається модифікації ◦ він покритий тестами ◦ нова функціональність додається легко ◦ нова функціональність не ламає стару ◦ його легко підтримувати ◦ легко перевести на інший стек технологій або мову програмування 3. Чому б з самого початку не зробити якісно? 6
  • 7. З рефакторингом є такі штуки 1. Погано продається 2. Бізнесу важко буде перевірити результат в моменті 3. Чому б з самого початку не зробити якісно? ◦ код як і продукт живий ◦ часто міняються люди ◦ погана комунікація в команді ◦ відсутність стандартів і документації ◦ недостатня кваліфікація кадрів ◦ тиск з боку замовника ◦ нові нові фічі, які додають складність в розуміння продукту 7
  • 8. Як визначає якість продукту клієнт 8 Добре спроектований програмний продукт Погано спроектований програмний продукт Під капотом це все не помітно Класний дизайн Зручність у використанні Адаптивність Ефективність Надійність Гнучкість
  • 9. Навіщо платити більше ? Поганий “дизайн” ● обмежує продукт в розвитку ● зв’язує руки програмістам ● уповільнює ріст бізнесу ● ресурси інвестуються не в розвиток ● збільшується плин кадрів 9
  • 10. Рефакторинг - це інвестиція в майбутнє ● Не дає миттєвого результату. ● Закладає фундамент для швидшої розробки. ● В середньо терміновій перспективі продукт стане простіше розвивати. ● Може бути цікавим програмістам, а значить меньше навантаження на HR. Для ІТ - показник здорового інтересу бізнеса до продукту. Картинка з https://martinfowler.com/bliki/DesignStaminaHypothesis.html 10
  • 11. 11 Як продав ? ● 64% багів ● 23% критичних ● ріст покриття тестами не зменшував кількості помилок ● відношення заведених багів до виправлених 602/329 (за 2015 рік) ● 2 жорстких падіння сервісу в період black friday і перед новим роком ● після чого від нас почали іти клієнти ● довіра між бізнесом і ІТ. Якщо у вас самих немає бачення, як виправити ситуацію в конкретних кроках, ви не зможете переконати.
  • 13. Ви можете написати з нуля якщо ● у вас багато грошей і часу ● ви впевнені в тому, що ви краще спроектуєте систему ніж попередній архітектор ● ви плануєте регулярно отримувати зворотній зв’язок від користувачів ● ви впораєтеся з тим, щоб підтримувати 2 системи одночасно ● ви провели дослідження старої системи і у вас є достатньо впевненості, що переписати буде простіше і швидше ● ви впевнені в тому, що в процесі не буде втрачено функціоналу ● ви згодні на те, що нова версія може принести нові проблеми користувачам 13
  • 14. Еволюція чи революція Переписати з нуля це як революція, коли рефакторинг - це еволюція. Революція - страшна штука. Ніколи не відомо чим усе закінчиться. 14 З рефакторингом простіше, з ним ви адаптуєтеся до нових умов.
  • 16. Контрольований процес ● вибирається місце, яке потрібно “вилікувати” ● визначається відповідальний(і) за процес ● визначаємо рівень занурення ● test coverage ● при відсутності/не достатньому покритті - додати тести ● code-review ● code style 16
  • 18. Ітеративний процес Чому маленькими кроками? Необхідний план ● можна легко зупинитися при потребі ● поступове занурення не шкідливе ● частіше дає ефект досягнутого результату ● легше тримати контекст в голові ● простіше робити код-ревью ● колеги на вас не злі, коли зливають ваші зміни 18
  • 19. 19
  • 20. Якщо вони змогли побудувати колайдер То і ви зможете проштовхнути рефакторинг 20
  • 21. Приклад №1. “Проблема” із статистикою 21 На початкових етапах становлення продукту була лише 1 БД. В 2013 році її розмір уже доходив до 2ТБ. Найбільше місця займають результати доставки листів. Дорогий сервер з особливою конфігурацією: SSD + багато RAM + Intel Xeon. В коді повсюду використовується підхід Active Record, без використання репозиторіїв і інтерфейсів. По кодовій базі це було 97 різних методів доступа до цих даних за допомогою AR.
  • 22. 22
  • 23. 23
  • 24. Рішення № 1. Тимчасове. ● “А давайте видаляти старі дані!”. Так і жили певний час. ● написали код міграції даних із 1 БД в іншу ● старі дані інколи потрібні користувачам ● стало краще, але ненадовго Результат: Прийшло ще більше користувачів,а ми більше не поміщаємося на 1 сервері. 24
  • 25. Рішення № 2. Шардінг. Проблеми: ● це надовго (слайд #21) ● деякі патерни доступа до даних вимагають до себе пристальної уваги Не страшно: 1. Проаналізували всі місця в коді де є доступ до цих даних і зафіксували в документі 2. Визначили типи доступа до даних. Щоб простіше було, дали всім 97 місцям назви, так як ніби це були методи якогось класу. 3. В процесі частина коду була позначена, як кандидат на видалення - уже не актуальна функціональність. 4. Пріоритезували функціональність із п.2 і поставили оцінку по важкості реалізації. 5. Згрупували схожі методи доступа до даних - їх вийшло 21. 6. Зробили інтерфейс api. 7. Почали з самого простого. Всього вийшло 7 високорівневих Jira-тікетів. Весь процес зайняв майже рік часу. Відкатів не було, але в релізні дні інколи доводилося сидіти і правити по живому. 25
  • 26. Що було в процесі ? 1. 7 етапів виявилося замало, код встигав швидше мінятися ніж його встигали рефакторити. Кращим був би підхід, як рекомендують дієтологи: “Краще менше, але частіше” 2. Через великий об’єм внесених змін важкі код- ревью 3. Через це регулярні проблеми при мерджах 4. Нещасливий відділ тестування 26
  • 27. Приклад №2. Рефакторинг на мікросервіси 27 Як відправити розсилку на 3млн адресатів за адекватний час? Можна отак:
  • 28. Можна але не довго ● складний код. багато різних нюансів. ● smtp часто відвалюються, чи їх тимчасово блокують. ● усе це погано масштабується. ● працює добре тільки на малих навантаженнях. ● туди страшно заглядати. Давайте ізолюємо роботу із SMTP в окремому середовищі, а дамо назовні API. 28
  • 30. Стало простіше і трохи швидше ● з’явилося API ● компіляція листів переїхала із “повільного” PHP в “швидку” Java ● взаємодія із SMTP ізольована в мікросервсі, PHP команда вздихає з полегшенням ● можна масштабувати швидкість відправки новими SMTP і Java залізяками ● тепер PHP не може нагрузити ● основна БД все ще точка відмови. ми лише скоротили процес ● максимальна швидкість відправки 70-90тис листів в секунду 30
  • 31. 31
  • 32. Рішення мікросервіс відправки (Sender Service) ● не залежить від моноліта і основної БД. ● написаний на PHP 7. ● має здатність до маштабування. ● має API. ● швидкий. На даний момент пік це 500тис листів за хвилину. Розсилку в 3млн можна відправити за 6хв. 32
  • 33. Деякі загальні побажання ● Не рафакторингом єдиним. ● У нас тільки частина людей цим займається. ● Користувач продукту не пробачить того, що не виходять нові релізи. ● Кожній компанії потрібно знайти свій баланс між фічами і внутрішніми покращеннями. ● Оптимальний розмір команди 2-3 розробника, 1 QA. ● YAGNI, SOLID, KISS, CQRS і т.д. роблять “світ” кращим. ● керуйтеся принципом бойскаутів ● пишіть так, як ніби підтримку вашого коду мав би робити психопат, який знає вашу адресу 33
  • 34. Старайтеся не накопичувати технічний борг ● закладайте час при розробці нової функціональності, вам будуть вдячні, ті хто після вас туди заглядатиме ● коли виправляєте помилки ● під час код-ревью, це буде дешевше ніж на пізніших етапах ● коли вже не вперше доводиться робити, якусь подібну штуку ● коли маєте справу із успадкованим кодом ● кожне “тимчасове” рішення фіксуйте тікетами (коментарів TODO не достатньо) 34
  • 35. Почитати 35 ...все одно не видно краще пишіть та інтегруйтеся: Бричук Олександр obrychuk@unisender.com https://techbeacon.com/17-opinions-resources-rewrites-vs-refactoring https://refactoring.guru/ru/refactoring/catalog https://meekrosoft.wordpress.com/2010/10/31/internal-and-external-software-quality/ https://medium.com/@joaomilho/festina-lente-e29070811b84 https://www.entropywins.wtf/blog/2016/11/24/implementing-the-clean-architecture/ https://habrahabr.ru/post/150027/ https://habrahabr.ru/post/169139/ http://www.ozon.ru/context/detail/id/1308678/ http://www.yakaboo.ua/sovershennyj-kod-master-klass.html