— Ознаки, що проект потребує рефакторингу (крім кількості FAQ, що каже команда, коли дивиться на код). Вплив рефакторингу на бізнес — все стає простіше. Чому б не переписати «з нуля». Рефакторинг під час розробки вкрай дрібними кроками. — Чотири ознаки, що пора зупинитися. — Рефакторинг по-бойскаутські: «Залишай місце, з якого пішов, кращим, ніж воно було до тебе. При виконанні будь-якої задачі зменшуй технічний борг».

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 і перед новим роком
● після чого від нас почали іти клієнти
● довіра між бізнесом і ІТ. Якщо у вас самих немає бачення, як виправити ситуацію в
конкретних кроках, ви не зможете переконати.

12. з нуля ?
12

13. Ви можете написати з нуля якщо
● у вас багато грошей і часу
● ви впевнені в тому, що ви краще спроектуєте систему ніж
попередній архітектор
● ви плануєте регулярно отримувати зворотній зв’язок від
користувачів
● ви впораєтеся з тим, щоб підтримувати 2 системи
одночасно
● ви провели дослідження старої системи і у вас є достатньо
впевненості, що переписати буде простіше і швидше
● ви впевнені в тому, що в процесі не буде втрачено
функціоналу
● ви згодні на те, що нова версія може принести нові
проблеми користувачам
13

14. Еволюція чи революція
Переписати з нуля це як революція, коли рефакторинг - це еволюція.
Революція - страшна штука. Ніколи не відомо чим усе закінчиться.
14
З рефакторингом простіше, з ним ви адаптуєтеся до нових умов.

15. Контрольований процес
15

16. Контрольований процес
● вибирається місце, яке потрібно “вилікувати”
● визначається відповідальний(і) за процес
● визначаємо рівень занурення
● test coverage
● при відсутності/не достатньому
покритті - додати тести
● code-review
● code style
16

17. Як з’їсти слона
17

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

29. Ура! перший мікросервіс
29

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