Як працювати на Legacy проекті та не зійти із розуму

Transcript

1. ПРИВІТ
2. Денис Курець Ruby developer у MatchOffice 6-ть років в IT @denys281
3. Як працювати на Legacy проекті та не зійти із розуму
4. Disclaimer
5. Дякую за натхнення @amar47shah https://www.youtube.com/watch?v=JC4mS7sYQlU&t
7. Що таке Legacy? Два значення: • + Щось стабільне, щось варте наслідування, те що будуть використовувати нащадки * • - Поганий код, який ніхто не може викинути та переписати через ряд причин * https://www.youtube.com/watch?v=YruzQgWdv48
8. Rails та стартапи 1903 2005
9. Мій проект Z (колишній :)) • Ruby 1.8.7 (поточна версія 2.4.1) • Ruby on Rails 2.3.5 (поточна версія 5.1)
10. Код “так собі”
11. 0.7%
12. Ще проблеми • Duplicates • Low performance • Outdated infrastructure • A lot of problems • Nobody wants to introduce brand new problems
 

13. –@Petro Koriakin “And the largest problem is that I am afraid to change things.”
14. Programmers at work maintaining a Ruby on Rails application
15. Що ж робити?
16. Тікати?
17. Переписати!
18. Чому не хочуть переписувати • Нема грошей • Все працювало 6 років, навіщо переписувати? • Нема розуміння, що корабель тоне • Ваш варіант…
19. Ризик
20. Чому люди ідуть туди?
21. Ви джуніор
22. It's a challenge! Не вірте цим словам!
23. Money
24. Legacy може стати вашим останнім проектом на поточному місці праці
25. Але це може тривати рік, два, вічно… :)
26. Exit strategy
27. На проекті Слід залишити мужніх людей, які не вноситимуть смуту
28. Починайте розумно рефакторити та робити імпрувменти любою ціною зразу, навіть якщо клієнт чи PM цього не хочуть:)
29. Без покращення коду, це даремно витрачений час та гроші клієнта на проект
30. Корабель може тонути дуже довго, але він буде тонути
32. Єдність dev-команди, щодо розумного рефакторингу та імпрувментів
33. Дати клієнтові детальну стратегію по покращенню проекту (це може не спрацювати)
34. Вільні робочі дні для команди в компенсацію за жесть
35. Баланс • Які вимоги до роботи команди є надмірними, а які справедливими ? • Дотримуватись “золотої середини” • Завжди памятати про стан проекту та те що він тоне і ставитись до цього по філософськи https://dou.ua/lenta/articles/when-you-are-done/
36. QA на проекті, які розуміють бізнес та готові пояснити все у скороченій формі
37. КОМАНДА
38. Єдність та атмосфера в команді важливіша за будь-які негаразди на проекті, креші, факапи і т.п
39. Чати
40. Типовий workflow • Досліджуєш баг • Знаходиш причину • WTF?!!! Що за п…..с зробив це?!!! • git blame • От…!!!!!
41. Припиніть це робити
42. Чому це погано • Ви робите сумними себе • Ви робите сумними свою команду • Одного дня це може бути ваш колега :) • Різні обставини, різний рівень людей на той час, які писали код
43. –Jan Dudulski “When you dive in to edit code, you are not fixing someone else's mess, you are fixing a mess.” https://monterail.com/blog/2014/fixing-legacy-code
44. Для підтримання тонусу робіть “сайд” проект
45. Перваги • Проект із реальними користувачами, які регулярно користуються сервісом та приносять йому гроші • Відносно спокійний темп роботи (хоча час від часу є бурі) • Дослідження чужого “поганого” коду позитивно впливає на майбутній кодінг
46. Недоліки • Старі технології • Занепад власних тех. скілів • Іноді важкий психологічний стан • В більшості випадків марнування часу
47. Чи є happy end?
48. Проект Z happy end?
50. happy end завжди наступає :)
51. Дякую за увагу! denys281@gmail.com