Вдосконалюємо навички через міграцію проектів: способи і приклади

Не секрет, що великий відсоток українського ІТ працює над legacy-проектами. Що це означає для розробника? По-перше, це чужий код, у якого мізерна документації або її зовсім немає. Якщо ви щасливчик і весь проект повністю описаний, то, швидше за все, документація морально застаріла ще кілька років тому. По-друге, необхідно підтримувати цей код без впровадження великого обсягу нової функціональності. Плюс, у проекті багато речей сприймаються як даність. Працює — і добре, краще не потикатися без необхідності. І найважливіше — на таких проектах старі технології.

У підсумку програміст рано чи пізно стикається з необхідністю розширення своїх знань, щоб не застаріти самому, разом з проектом.

Способи одержання знань і навичок

Які ж існують шляхи підтримки актуальності своїх навичок і знань?

Прочитати мануали або книгу по конкретній технології. Дає загальне розуміння про можливості, але без практики такі знання погано відкладаються.
Походити по співбесідах. Без коментарів, і так все ясно.
Можна пройти курси з конкретної технології або навіть здати сертифікацію. Дає більш поглиблене розуміння технології, так як включає в себе практику.
Використовувати нову технологію в своєму pet-project. Напевно, найкращий варіант, якщо у вас є час та власне pet-project, так як, окрім практики, необхідно вирішувати не синтетичні/тестові завдання, а прикладні.

Як показує досвід, є більш складний, але і більш ефективний варіант — спробувати мігрувати частина legacy-додатки на нову версію технології або навіть замінити більш нової.

Що може дати міграція

По-перше, ви ще краще розберетеся з тим монстром, з яким працюєте. Так як при міграції можуть виникати проблеми, які ніколи не спливуть при повсякденній роботі. Якщо, звичайно, це не критичні баги в production-системі, але там у вас не буде часу, щоб сильно перейнятися — потрібно буде просто подофигеть від причин, швидко пофіксити і перехреститися на всяк випадок, навіть якщо не віруючий. А то фікс може вибухнути в іншому місці, і вже доведеться занурюватися ще глибше.

По-друге, ви розберетеся як з новою технологією, так і зі старою, тому, що при міграції завжди виникає необхідність переписати несумісні частини.

Що потрібно знати до міграції

По-перше, міграція заради міграції — це не є добре, і треба чітко розуміти, що вона повинна вирішувати якусь проблему і не привносити нові.

По-друге, треба розуміти, дасть на міграцію ласкаво замовник. А для цього має бути чітка аргументація з плюсами і мінусами переходу. Не зустрічав замовників, які кажуть ні, коли проект просто благає про апгрейд, але, думаю, вони є.

По-третє, це опір команди. У будь-якому випадку будуть люди, які проти. Якщо вдасться їх переконати, то всі плюси і мінуси у вас вже будуть зібрані, значить розмову з замовником пройде легше.

По-четверте, потрібно вміти зупинитися і зрозуміти, що міграція неможлива. Відсутність результату — це теж результат.

По-п'яте, це часткова міграція. Категорично проти такого, так як плодити зоопарк технологій, які роблять одну і ту ж роботу паралельно в різних класах/частинах системи — це зло. Таке положення часто приводить до проблем, які складно відловити, і необхідністю супроводжувати два або більше варіантів вирішення завдань. Бачив проект, в якому половина доменної області витягується за допомогою дідівського JDBC, а друга — Hibernate c купою eager-зв'язків, що вело до щоденних падінь програми з out of memory з-за невірного використання технології.

Приклади з практики

Необхідно звертати увагу на вузькі місця проекту і не можна обмежуватися тільки програмним кодом.

Continuous integration tools. Якщо проект використовує «no name» CI родом з кінця 90-х з не user-friendly інтерфейсом і просідає перформансом, то можна перевести його на Jenkins, TeamCity або GitLab CI. Це дозволить поглянути на проект з більш високого ракурсу і зрозуміти його модульність, знайти вузькі місця і оптимізувати, якщо можливо. Попутно можна почати зберігати артефакти в Nexus, якщо цього ще не сталося до 2018 року. Можливо, самий легкий пункт, так як результати найлегше протестувати. Та й навряд чи знайдуться люди, які будуть проти такої міграції.

SCM tools. Якщо у вас є SVN, то можна мігрувати на Git або Mercurial. Теж нескладний варіант, так як в більшій мірі може бути виконаний спеціалізованими засобами. Головна складність — це зміна підходів до розробки, а значить може виникнути опір з боку команди. Зате є безсумнівні плюси у зменшенні розміру сховища, а також можливість коммитить локально.

Build tools. Якщо у вас є Ant, то можна мігрувати на додаток Maven або Gradle. Дозволить позбутися від необхідності зберігати бібліотеки в проекті, плюс розібратися в тонкощах складання. При такій міграції особливих проблем виникнути не повинно, так як на всі випадки життя вже написані плагіни. А якщо ваш випадок унікальний — можна написати свій.

Зберігання даних. Дані краще зберігати у природній формі, що спрощує їх запис і подальшу роботу з ними. Не всі дані добре лягають на реляційну модель, тому можна розглянути варіант використання NoSQL баз даних. В одному з проектів була необхідність реалізувати аналіз логів пошукових запитів з великою кількістю опціональних параметрів. Писати їх далі в лог файли було нерозумно, тому що аналізувати це не просто. Оскільки до того часу популярність набрала MongoDB, то кращого варіанту її застосувати не знайшлося, як для зберігання документів з перемінним кількістю атрибутів і аналізу за допомогою MapReduce. Зараз би таке рішення не прийняв, а вибрав би ELK stack. Та й світ, як на мене, збайдужів до NoSQL. Зробив такий висновок, тому що недавно продавав півтора десятка книг по програмуванню і тільки «MongoDB в дії» не пішла. Пишіть в лічку, кому треба :) Але все ж знання NoSQL — це однозначно плюс. Така міграція — одна з найскладніших з точки зору опору команди. Тому що впровадження принципово нових сховищ даних і їх підтримка досить складні, а також змушують мислити даних про по-новому.

Пошук даних. Як не крути, але час виконання пошуку — критичний параметр для користувача. Якщо раптом у додатку використовується реляційна база даних і ніякі індекси не допомагають, то логічно поглянути на ElasticSearch, Solr або їм подібні рішення. Міграція додасть головного болю з індексацією, але із завданням пошуку може впоратися набагато краще RDBMS, плюс є можливість масштабування. І хоча в душі окремі члени команди і замовник можуть бути не в захваті, але проти незадоволеного користувача не попреш.

Spring/Spring Boot. Якщо у вас є Spring, то можна мігрувати на Spring Boot. Це спростить налаштування проекту за допомогою заміни самопісного коду на автоконфігурації, в результаті навіть коду стане менше. Також за роки розробки можуть виникнути складні рішення з контекстами програми і конфігурації фільтрів, з якими можна буде легше розібратися в процесі міграції. Міграція не особливо складна, але рутинна.

Java version. Кожна нова версія Java має ряд нововведень, які можуть значно спростити життя, а по невмінню — ускладнити. Якщо брати до уваги позитивний варіант, то використання Streaming api може серйозно полегшити роботу з даними, якщо над ними виконується багато варіантів фільтрації і трансформації при різних станах системи. Новий Date/Time api дозволить спростити роботу з датами, тимчасовими зонами і часом. Якщо ваш проект хоча б частково покритий тестами, то такий перехід буде не дуже складним.

Використання хмарних сервісів замість виділених серверів. Не брав участі в таких міграціях, так як останні роки працював з проектами, які деплоятся в хмарні платформи. Але є відчуття, що виділені сервера для 99% рішень — це минуле, і немає необхідності їх використовувати. Тому що ручне налаштування і моніторинг можуть займати багато часу, плюс всі хмарні платформи надають величезну кількість додаткових сервісів у вигляді баз даних, кешей, файлових сховищ і т. д. Процес міграції бачиться досить складним і може бути великий опір як з боку команди, так і з боку замовника. Але гра коштує свічок.

Список далеко не повний, але основна ідея полягає в тому, що скрізь можна знайти місце для поліпшення. А поліпшення в проекті, зроблені власними руками, — це також розширення та поглиблення власних знань. Всі залишаються в профіті! Також хотілося б дізнатися приклади міграцій, які здійснювали читачі DOU.

P. S. Навмисне пропустив тему frontend-а, тому що в реаліях 2018 року можна мігрувати на нову технологію і в кінці міграції виявити, що вона морально застаріла.

P. P. S. Є ще один варіант підтримки актуальності знань, який згадував у статті «Як вижити у вирі сучасного IT, або Навіщо вивчати основи» , але не всім він підійде.

Опубліковано: 24/07/18 @ 10:00
Розділ Різне

SEO Блог