Як робити рефакторинг в продукті з бурхливою історією
- 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 З рефакторингом простіше, з ним ви адаптуєтеся до нових умов.
- 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