— Ознаки, що проект потребує рефакторингу (крім кількості FAQ, що каже команда, коли дивиться на код). Вплив рефакторингу на бізнес — все стає простіше. Чому б не переписати «з нуля». Рефакторинг під час розробки вкрай дрібними кроками.
— Чотири ознаки, що пора зупинитися.
— Рефакторинг по-бойскаутські: «Залишай місце, з якого пішов, кращим, ніж воно було до тебе. При виконанні будь-якої задачі зменшуй технічний борг».
Як робити рефакторинг в продукті з бурхливою історієюAleksandr Brychuk
— Ознаки, що проект потребує рефакторингу (крім кількості FAQ, що каже команда, коли дивиться на код). Вплив рефакторингу на бізнес — все стає простіше. Чому б не переписати «з нуля». Рефакторинг під час розробки вкрай дрібними кроками.
— Чотири ознаки, що пора зупинитися.
— Рефакторинг по-бойскаутські: «Залишай місце, з якого пішов, кращим, ніж воно було до тебе. При виконанні будь-якої задачі зменшуй технічний борг».
Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого пр...Lviv Startup Club
Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого продукту
UA Online PMDay 2022
Website - https://pmday.org/online
Youtube - https://www.youtube.com/startuplviv
FB - https://www.facebook.com/pmdayconference
Oleksandr Krakovetskyi: Чому створення data strategy для компаній – це першоч...Lviv Startup Club
Oleksandr Krakovetskyi: Чому створення data strategy для компаній – це першочергове завдання?
AI & BigData Online Day 2021
Website - https://aiconf.com.ua/
Youtube - https://www.youtube.com/startuplviv
FB - https://www.facebook.com/aiconf
Як робити рефакторинг в продукті з бурхливою історієюAleksandr Brychuk
— Ознаки, що проект потребує рефакторингу (крім кількості FAQ, що каже команда, коли дивиться на код). Вплив рефакторингу на бізнес — все стає простіше. Чому б не переписати «з нуля». Рефакторинг під час розробки вкрай дрібними кроками.
— Чотири ознаки, що пора зупинитися.
— Рефакторинг по-бойскаутські: «Залишай місце, з якого пішов, кращим, ніж воно було до тебе. При виконанні будь-якої задачі зменшуй технічний борг».
Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого пр...Lviv Startup Club
Dmytro Yarmak: Product Development Flow або як пришвидшити розробку вашого продукту
UA Online PMDay 2022
Website - https://pmday.org/online
Youtube - https://www.youtube.com/startuplviv
FB - https://www.facebook.com/pmdayconference
Oleksandr Krakovetskyi: Чому створення data strategy для компаній – це першоч...Lviv Startup Club
Oleksandr Krakovetskyi: Чому створення data strategy для компаній – це першочергове завдання?
AI & BigData Online Day 2021
Website - https://aiconf.com.ua/
Youtube - https://www.youtube.com/startuplviv
FB - https://www.facebook.com/aiconf
Під час проектування інтерфейсу найчастіше виникає запитання, а наскільки взагалі він ефективний? І що найголовніше — яким чином можна цю ефективність виміряти?
Найбільш дієвим способом перевірити це провести юзабіліті тестування. Інакшими словами, показати певній кількості людей прототип та попросити їх виконати декілька завдань.
Перевірка дизайн-рішень на контрольній групі не потребує багато часу чи великих витрат. Одак, як саме зрозуміти що нова версія інтерфейсу є ефективною? І як перевести дискусію усередині команди із суб’єктивного сприйняття віжуалу до мови цифр?
На цій презентації я розповім які метрики можна застосовувати для юзабіліті тестуваннь. Як працювати із Task Success Rate, Task Time, Task Error Rate та як вимірювати Efficiency та Lerability. А також як обчислювати та презентувати результати тестування команді та замовникам.
● Що таке "цикл зворотнього зв'язку"?
● Цикли зворотнього зв'язку у eXtreme
Programming
● Зміцнення та скорочення циклу
зворотнього зв'язку
● Декларація взаємозалежності
● Запитання та обговорення
Моя доповідь на "Project Management Weekend" у Львові на на тему будування скрам команд.
Чи завджи може спрацювати Скрам в будь-якій команді? Як збирати Скрам команду з нуля? Як це робити - як побудувати цей процес? Відповіді на ці та інші актуальні питання, щодо формування та роботи скрам команд.
Automation as a Way to Do Routine Work Quickly and EffortlesslyGlobalLogic Ukraine
This presentation contains options for devices and software testing, highlighting pros and cons of each option and explaining the advantages of test automation.
This presentation by Yuriy Kozak (PhD in Electrical and Electronics Engineering, System Architect, GlobalLogic) was delivered at QA Automation TechTalk in Lviv on February 10, 2016.
Lean
Six Sigma
PRINCE2
XP (Extreme Programming)
Principles, practices, tools, rules and other topics in each of the methodologies.
How PMO could match with Extreme Programming
How to work with Kanban board and match this process board with WIP Limit, Just In Time practice, SMED and SIPOC analysis
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»QADay
Lviv Direction QADay 2023 (automation)
ОЛЕГ ЗАРЕВИЧ
«Shift left та Shift Right підходи до тестування»
telegram: wwww.t.me/goqameetup
fb: www.fb.com/goqaevent
fb: www.fb.com/qaday.org
linkedin: https://www.linkedin.com/company/goqa/
Сайт: www.qaday.org
Під час проектування інтерфейсу найчастіше виникає запитання, а наскільки взагалі він ефективний? І що найголовніше — яким чином можна цю ефективність виміряти?
Найбільш дієвим способом перевірити це провести юзабіліті тестування. Інакшими словами, показати певній кількості людей прототип та попросити їх виконати декілька завдань.
Перевірка дизайн-рішень на контрольній групі не потребує багато часу чи великих витрат. Одак, як саме зрозуміти що нова версія інтерфейсу є ефективною? І як перевести дискусію усередині команди із суб’єктивного сприйняття віжуалу до мови цифр?
На цій презентації я розповім які метрики можна застосовувати для юзабіліті тестуваннь. Як працювати із Task Success Rate, Task Time, Task Error Rate та як вимірювати Efficiency та Lerability. А також як обчислювати та презентувати результати тестування команді та замовникам.
● Що таке "цикл зворотнього зв'язку"?
● Цикли зворотнього зв'язку у eXtreme
Programming
● Зміцнення та скорочення циклу
зворотнього зв'язку
● Декларація взаємозалежності
● Запитання та обговорення
Моя доповідь на "Project Management Weekend" у Львові на на тему будування скрам команд.
Чи завджи може спрацювати Скрам в будь-якій команді? Як збирати Скрам команду з нуля? Як це робити - як побудувати цей процес? Відповіді на ці та інші актуальні питання, щодо формування та роботи скрам команд.
Automation as a Way to Do Routine Work Quickly and EffortlesslyGlobalLogic Ukraine
This presentation contains options for devices and software testing, highlighting pros and cons of each option and explaining the advantages of test automation.
This presentation by Yuriy Kozak (PhD in Electrical and Electronics Engineering, System Architect, GlobalLogic) was delivered at QA Automation TechTalk in Lviv on February 10, 2016.
Lean
Six Sigma
PRINCE2
XP (Extreme Programming)
Principles, practices, tools, rules and other topics in each of the methodologies.
How PMO could match with Extreme Programming
How to work with Kanban board and match this process board with WIP Limit, Just In Time practice, SMED and SIPOC analysis
ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»QADay
Lviv Direction QADay 2023 (automation)
ОЛЕГ ЗАРЕВИЧ
«Shift left та Shift Right підходи до тестування»
telegram: wwww.t.me/goqameetup
fb: www.fb.com/goqaevent
fb: www.fb.com/qaday.org
linkedin: https://www.linkedin.com/company/goqa/
Сайт: www.qaday.org
Павло Юрійчук — Перехід на Angular.js. Howto
1.Що таке Angular.JS на думку Менеджера і Розробника
2. Екосистема для розробки на Angular.JS
3. Причини для переходу і непереходу на Angular.JS
4. Предметна область, поради, книги
5. Ознаки, що Ви на вірному шляху
Цю презентацію значно доповнює схожа, але трохи інша. англомовна презентація Павла: "Pavlo Yuriychuk — Switching to Angular.js. Silk way"
Dmytro Khudenko: Challenges of implementing task managers in the corporate an...Lviv Startup Club
Dmytro Khudenko: Challenges of implementing task managers in the corporate and public sectors (UA)
UA Online PMDay 2024 Spring
Website – www.pmday.org/online
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
Imagine that you've been given an old project, a Food Delivery app, with the backend written in Laravel 8 and PHP 8.0. The web and mobile interfaces communicate with the backend through an API, but it's currently performing poorly with an average response time of 600ms. The product owner has requested you to optimize the performance and wonders if it's possible to reduce it by a factor of 10. What would you do?
Topics to be Covered:
Nginx Cache
Rememberable package
Redis Cache
Queues: Redis/SQS
Horizon
Octane: Swoole / Roadrunner
Upgrading PHP and Laravel
While you may be familiar with most of these points and possibly already using them, the focus will be on ensuring that you're using them correctly and effectively. In a real-world example, I will demonstrate how we managed to reduce average response times by 10 times. We'll explore what's hidden under Laravel's package magic and discuss ways to mitigate the negative impact on project performance.
By the end of this performance optimization session, you will not only have improved your performance but also gained a deeper understanding of how to utilize the Laravel framework more efficiently.
Oleksandr Brychuk "UniSender architecture. Growth from 100kk to 1.5kkk letter...Fwdays
Architecture in 2013 comes from scratch, so is there any hope for the future? Business is primarily about money, but what if the balance between technical improvements and a beautiful look is not maintained.
"Emergency 2015" - the limit after which you need to make drastic changes in the technical component. Carte blanche from business and a rough idea of where to start the transformation.
Why did you choose to go through refactoring? Why did you decide to split the monolith into microservices in 2015, when the hype was just emerging, instead of SOA and monolith? How did you choose where to start? How AWS S3 defeated Ceph and helped save the nerves and funds of DevOps? What nodes of the system have provided us with the opportunity to grow 10-15 times in 5 years without spending much more money on vertical scaling? Stable 1.5 billion letters in 2020.
Similar to Багаті спадкоємці, або як робити рефакторинг у продукті з бурхливою історією. Олександр Бричук (20)
В своей презентации Сергей Бондарь, Team Lead of BI Compute | OWOX, поделился тем как он вместе с командой использует Google Cloud Platform для построения прогнозов.
Как боты помогают Monobank обслуживать более 800 тысяч клиентовHOWWEDOIT
В своей презентации Илья поделился инсайдами как чат-боты помогают Monobank обслуживать более 800к клиентови удерживать позиции самого быстрорастущего необанка в мире!
Difficulties of implementing AI Features to an established product companyHOWWEDOIT
Time Doctor conducted a case study to implement AI features to predict employee turnover for its 100k users tracking over 50 million work hours. The model results were good at predicting who would quit or be fired, but clients were not interested in these predictions as AI alone cannot solve fundamental issues or be easily sold without long-term cooperation and trust.
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Что база транзакций может рассказать о здоровье вашего бизнеса. Павел Левчук HOWWEDOIT
Многие аналитики и продуктовые менеджеры возлагают большие надежды на крутые аналитические системы. Но наблюдать за ростом и понимать и управлять им это две большие разницы. Сегодня мы поговорим о том, что может рассказать вам о вашем бизнесе ваша же база транзакций. Мы обсудим такие вещи как:
— почему рост это боль,
— почему привлечь больше клиентов не означает расти быстрее,
— обсудим можно ли расти вообще без привлечения,
— стоит ли заниматься существующими клиентами.
Еще будем говорить о бесполезности понятия конверсии, ценообразовании и его влиянии на рост и LTV, убедимся в том, что портрет клиента это миф и сформируем объективный график роста вашего бизнеса.
метрики ценообразования как интернет магазины используют цены конкурентов.але...HOWWEDOIT
Многие интернет-магазины «думают» что они знают цены конкурентов, и даже применяют их в ценообразовании, но так ли это?
Мы посмотрим реальные кейсы таких корреляций данных:
— Как измерять вес бренда? Доход от товара проданных по ценам выше рынка.
— Как измерять влияние конкуренции на спрос ?
— Расчет эластичности спроса в группе товаров, бренде, канале, как зависит конверсия от отклонения от цен конкурентов.
Использование нового инструмента Google Data Studio 360 для построения графиков и создания дашбордов из разных систем сбора, хранения и обработки данных.
Багаті спадкоємці, або як робити рефакторинг у продукті з бурхливою історією. Олександр Бричук
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
21. Приклад №1. “Проблема” із
статистикою
21
На початкових етапах становлення продукту була лише 1 БД.
В 2013 році її розмір уже доходив до 2ТБ.
Найбільше місця займають результати доставки листів. Дорогий сервер з особливою конфігурацією:
SSD + багато RAM + Intel Xeon.
В коді повсюду використовується підхід Active Record, без використання репозиторіїв і інтерфейсів.
По кодовій базі це було 97 різних методів доступа до цих даних за допомогою AR.
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
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