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.
Багаті спадкоємці, або як робити
рефакторинг в продукті з
бурхливою історією
Бричук Олександр
Head of IT Department UniSen...
● Розробник сервісу email і sms розсилок.
● На ринку з 2008 року.
● В березні 2017 через нас було успішно
доставлено трішк...
Рефакторинг
• контрольований процес покращення коду, який не має на меті
написання нової функціональності.
• його результа...
Як зрозуміти, що потрібно щось
міняти?
● кількість помилок в Jira постійно збільшується
● коли повторюється ситуація з кар...
З рефакторингом є такі штуки
1. Погано продається
◦ в рамках обмеженого часу і бюджету економіка завжди виграє
◦ код мало ...
З рефакторингом є такі штуки
1. Погано продається
2. Бізнесу важко буде перевірити результат в моменті
◦ він відчутний тіл...
З рефакторингом є такі штуки
1. Погано продається
2. Бізнесу важко буде перевірити результат в моменті
3. Чому б з самого ...
Як визначає якість продукту
клієнт
8
Добре
спроектований
програмний продукт
Погано
спроектований
програмний продукт
Під ка...
Навіщо платити більше ?
Поганий “дизайн”
● обмежує продукт в розвитку
● зв’язує руки програмістам
● уповільнює ріст бізнес...
Рефакторинг - це інвестиція в
майбутнє
● Не дає миттєвого результату.
● Закладає фундамент для
швидшої розробки.
● В серед...
11
Як продав ?
● 64% багів
● 23% критичних
● ріст покриття тестами не зменшував кількості помилок
● відношення заведених б...
з нуля ?
12
Ви можете написати з нуля якщо
● у вас багато грошей і часу
● ви впевнені в тому, що ви краще спроектуєте систему ніж
попе...
Еволюція чи революція
Переписати з нуля це як революція, коли рефакторинг - це еволюція.
Революція - страшна штука. Ніколи...
Контрольований процес
15
Контрольований процес
● вибирається місце, яке потрібно “вилікувати”
● визначається відповідальний(і) за процес
● визначає...
Як з’їсти слона
17
Ітеративний процес
Чому маленькими кроками?
Необхідний план
● можна легко зупинитися при потребі
● поступове занурення не ...
19
Якщо вони змогли
побудувати колайдер
То і ви зможете
проштовхнути
рефакторинг
20
Приклад №1. “Проблема” із
статистикою
21
На початкових етапах становлення продукту була лише 1 БД.
В 2013 році її розмір у...
22
23
Рішення № 1. Тимчасове.
● “А давайте видаляти старі дані!”. Так і жили певний
час.
● написали код міграції даних із 1 БД в...
Рішення № 2. Шардінг.
Проблеми:
● це надовго (слайд #21)
● деякі патерни доступа до даних вимагають до себе пристальної ув...
Що було в процесі ?
1. 7 етапів виявилося замало, код встигав
швидше мінятися ніж його встигали
рефакторити. Кращим був би...
Приклад №2. Рефакторинг на мікросервіси
27
Як відправити розсилку на
3млн адресатів за
адекватний час?
Можна отак:
Можна але не довго
● складний код. багато різних нюансів.
● smtp часто відвалюються, чи їх тимчасово блокують.
● усе це по...
Ура! перший мікросервіс
29
Стало простіше і трохи швидше
● з’явилося API
● компіляція листів переїхала із “повільного” PHP в “швидку” Java
● взаємоді...
31
Рішення мікросервіс відправки (Sender
Service)
● не залежить від моноліта і основної БД.
● написаний на PHP 7.
● має здатн...
Деякі загальні
побажання
● Не рафакторингом єдиним.
● У нас тільки частина людей цим займається.
● Користувач продукту не ...
Старайтеся не накопичувати
технічний борг
● закладайте час при розробці нової функціональності, вам
будуть вдячні, ті хто ...
Почитати
35
...все одно не видно
краще пишіть та інтегруйтеся:
Бричук Олександр
obrychuk@unisender.com
https://techbeacon....
Upcoming SlideShare
Loading in …5
×

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

187 views

Published on

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

Published in: Technology
  • Login to see the comments

  • Be the first to like this

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

  1. 1. Багаті спадкоємці, або як робити рефакторинг в продукті з бурхливою історією Бричук Олександр Head of IT Department UniSender
  2. 2. ● Розробник сервісу email і sms розсилок. ● На ринку з 2008 року. ● В березні 2017 через нас було успішно доставлено трішки більше 600млн листів. ● ... ми не розсилаємо спам. 2
  3. 3. Рефакторинг • контрольований процес покращення коду, який не має на меті написання нової функціональності. • його результатом являється чистий і зрозумілий код. ще раз - контрольований і ітеративний процес покращення коду 3
  4. 4. Як зрозуміти, що потрібно щось міняти? ● кількість помилок в Jira постійно збільшується ● коли повторюється ситуація з картинки ● коли витрачений час більший за оцінений ● коли новий програміст звільняється в перший же день із фразою: “Ваш код лайно” (правдива історія) ● коли виправлення однієї проблеми породжує нову ● коли програмісти уже не хочуть іти на компроміси із менеджером 4
  5. 5. З рефакторингом є такі штуки 1. Погано продається ◦ в рамках обмеженого часу і бюджету економіка завжди виграє ◦ код мало кого цікавить. задача програміста вирішувати бізнесові потреби. ◦ як пояснити технічно не підкованій людині, що отут от так собі рішення і його варто переробити? 2. Бізнесу важко буде перевірити результат в моменті 3. Чому б з самого початку не зробити якісно? 5
  6. 6. З рефакторингом є такі штуки 1. Погано продається 2. Бізнесу важко буде перевірити результат в моменті ◦ він відчутний тільки для програмістів. такі справи… ◦ якісний код легко піддається модифікації ◦ він покритий тестами ◦ нова функціональність додається легко ◦ нова функціональність не ламає стару ◦ його легко підтримувати ◦ легко перевести на інший стек технологій або мову програмування 3. Чому б з самого початку не зробити якісно? 6
  7. 7. З рефакторингом є такі штуки 1. Погано продається 2. Бізнесу важко буде перевірити результат в моменті 3. Чому б з самого початку не зробити якісно? ◦ код як і продукт живий ◦ часто міняються люди ◦ погана комунікація в команді ◦ відсутність стандартів і документації ◦ недостатня кваліфікація кадрів ◦ тиск з боку замовника ◦ нові нові фічі, які додають складність в розуміння продукту 7
  8. 8. Як визначає якість продукту клієнт 8 Добре спроектований програмний продукт Погано спроектований програмний продукт Під капотом це все не помітно Класний дизайн Зручність у використанні Адаптивність Ефективність Надійність Гнучкість
  9. 9. Навіщо платити більше ? Поганий “дизайн” ● обмежує продукт в розвитку ● зв’язує руки програмістам ● уповільнює ріст бізнесу ● ресурси інвестуються не в розвиток ● збільшується плин кадрів 9
  10. 10. Рефакторинг - це інвестиція в майбутнє ● Не дає миттєвого результату. ● Закладає фундамент для швидшої розробки. ● В середньо терміновій перспективі продукт стане простіше розвивати. ● Може бути цікавим програмістам, а значить меньше навантаження на HR. Для ІТ - показник здорового інтересу бізнеса до продукту. Картинка з https://martinfowler.com/bliki/DesignStaminaHypothesis.html 10
  11. 11. 11 Як продав ? ● 64% багів ● 23% критичних ● ріст покриття тестами не зменшував кількості помилок ● відношення заведених багів до виправлених 602/329 (за 2015 рік) ● 2 жорстких падіння сервісу в період black friday і перед новим роком ● після чого від нас почали іти клієнти ● довіра між бізнесом і ІТ. Якщо у вас самих немає бачення, як виправити ситуацію в конкретних кроках, ви не зможете переконати.
  12. 12. з нуля ? 12
  13. 13. Ви можете написати з нуля якщо ● у вас багато грошей і часу ● ви впевнені в тому, що ви краще спроектуєте систему ніж попередній архітектор ● ви плануєте регулярно отримувати зворотній зв’язок від користувачів ● ви впораєтеся з тим, щоб підтримувати 2 системи одночасно ● ви провели дослідження старої системи і у вас є достатньо впевненості, що переписати буде простіше і швидше ● ви впевнені в тому, що в процесі не буде втрачено функціоналу ● ви згодні на те, що нова версія може принести нові проблеми користувачам 13
  14. 14. Еволюція чи революція Переписати з нуля це як революція, коли рефакторинг - це еволюція. Революція - страшна штука. Ніколи не відомо чим усе закінчиться. 14 З рефакторингом простіше, з ним ви адаптуєтеся до нових умов.
  15. 15. Контрольований процес 15
  16. 16. Контрольований процес ● вибирається місце, яке потрібно “вилікувати” ● визначається відповідальний(і) за процес ● визначаємо рівень занурення ● test coverage ● при відсутності/не достатньому покритті - додати тести ● code-review ● code style 16
  17. 17. Як з’їсти слона 17
  18. 18. Ітеративний процес Чому маленькими кроками? Необхідний план ● можна легко зупинитися при потребі ● поступове занурення не шкідливе ● частіше дає ефект досягнутого результату ● легше тримати контекст в голові ● простіше робити код-ревью ● колеги на вас не злі, коли зливають ваші зміни 18
  19. 19. 19
  20. 20. Якщо вони змогли побудувати колайдер То і ви зможете проштовхнути рефакторинг 20
  21. 21. Приклад №1. “Проблема” із статистикою 21 На початкових етапах становлення продукту була лише 1 БД. В 2013 році її розмір уже доходив до 2ТБ. Найбільше місця займають результати доставки листів. Дорогий сервер з особливою конфігурацією: SSD + багато RAM + Intel Xeon. В коді повсюду використовується підхід Active Record, без використання репозиторіїв і інтерфейсів. По кодовій базі це було 97 різних методів доступа до цих даних за допомогою AR.
  22. 22. 22
  23. 23. 23
  24. 24. Рішення № 1. Тимчасове. ● “А давайте видаляти старі дані!”. Так і жили певний час. ● написали код міграції даних із 1 БД в іншу ● старі дані інколи потрібні користувачам ● стало краще, але ненадовго Результат: Прийшло ще більше користувачів,а ми більше не поміщаємося на 1 сервері. 24
  25. 25. Рішення № 2. Шардінг. Проблеми: ● це надовго (слайд #21) ● деякі патерни доступа до даних вимагають до себе пристальної уваги Не страшно: 1. Проаналізували всі місця в коді де є доступ до цих даних і зафіксували в документі 2. Визначили типи доступа до даних. Щоб простіше було, дали всім 97 місцям назви, так як ніби це були методи якогось класу. 3. В процесі частина коду була позначена, як кандидат на видалення - уже не актуальна функціональність. 4. Пріоритезували функціональність із п.2 і поставили оцінку по важкості реалізації. 5. Згрупували схожі методи доступа до даних - їх вийшло 21. 6. Зробили інтерфейс api. 7. Почали з самого простого. Всього вийшло 7 високорівневих Jira-тікетів. Весь процес зайняв майже рік часу. Відкатів не було, але в релізні дні інколи доводилося сидіти і правити по живому. 25
  26. 26. Що було в процесі ? 1. 7 етапів виявилося замало, код встигав швидше мінятися ніж його встигали рефакторити. Кращим був би підхід, як рекомендують дієтологи: “Краще менше, але частіше” 2. Через великий об’єм внесених змін важкі код- ревью 3. Через це регулярні проблеми при мерджах 4. Нещасливий відділ тестування 26
  27. 27. Приклад №2. Рефакторинг на мікросервіси 27 Як відправити розсилку на 3млн адресатів за адекватний час? Можна отак:
  28. 28. Можна але не довго ● складний код. багато різних нюансів. ● smtp часто відвалюються, чи їх тимчасово блокують. ● усе це погано масштабується. ● працює добре тільки на малих навантаженнях. ● туди страшно заглядати. Давайте ізолюємо роботу із SMTP в окремому середовищі, а дамо назовні API. 28
  29. 29. Ура! перший мікросервіс 29
  30. 30. Стало простіше і трохи швидше ● з’явилося API ● компіляція листів переїхала із “повільного” PHP в “швидку” Java ● взаємодія із SMTP ізольована в мікросервсі, PHP команда вздихає з полегшенням ● можна масштабувати швидкість відправки новими SMTP і Java залізяками ● тепер PHP не може нагрузити ● основна БД все ще точка відмови. ми лише скоротили процес ● максимальна швидкість відправки 70-90тис листів в секунду 30
  31. 31. 31
  32. 32. Рішення мікросервіс відправки (Sender Service) ● не залежить від моноліта і основної БД. ● написаний на PHP 7. ● має здатність до маштабування. ● має API. ● швидкий. На даний момент пік це 500тис листів за хвилину. Розсилку в 3млн можна відправити за 6хв. 32
  33. 33. Деякі загальні побажання ● Не рафакторингом єдиним. ● У нас тільки частина людей цим займається. ● Користувач продукту не пробачить того, що не виходять нові релізи. ● Кожній компанії потрібно знайти свій баланс між фічами і внутрішніми покращеннями. ● Оптимальний розмір команди 2-3 розробника, 1 QA. ● YAGNI, SOLID, KISS, CQRS і т.д. роблять “світ” кращим. ● керуйтеся принципом бойскаутів ● пишіть так, як ніби підтримку вашого коду мав би робити психопат, який знає вашу адресу 33
  34. 34. Старайтеся не накопичувати технічний борг ● закладайте час при розробці нової функціональності, вам будуть вдячні, ті хто після вас туди заглядатиме ● коли виправляєте помилки ● під час код-ревью, це буде дешевше ніж на пізніших етапах ● коли вже не вперше доводиться робити, якусь подібну штуку ● коли маєте справу із успадкованим кодом ● кожне “тимчасове” рішення фіксуйте тікетами (коментарів TODO не достатньо) 34
  35. 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

×