Як обирати технології? Коли ми переходимо на JavaScript?

Вибір правильних технологій є необхідною умовою для того, щоб стати старшим розробником. Ці рішення часто бувають непростими, адже потрібно враховувати поточний технічний стан додатку, куди ви рухаєтесь у розвитку, які знання має ваша команда, які знання поширені на ринку праці, яка вартість кожної технології, які ризики вона несе для вашої діяльності, наскільки безпечна і стабільна технологія, і, нарешті, що не менш важливо, що буде цікавити розробників, скажімо, через 5 років, коли 80% вашої команди буде замінено.

Я пройшов через 6 великих компаній, які розробляють на PHP. Лише 2 з них намагаються перейти на іншу технологію в довгостроковій перспективі, інші залишаються. Це має багато проблем. Наприклад, зараз я намагаюся знайти старшого PHP-розробника для корпоративного проекту, який я розробляю для O2, з вимогою їздити до офісу в Празі, і я бачу, як ринок PHP-розробників очистився за останні 5 років. PHP просто більше не є крутим, і мало хто хоче ним займатися. У ньому не вистачає юніорів.

З інтерв'ю з молодими людьми я зрозуміла, що React і взагалі "тонкі" технології зараз дуже популярні. З точки зору архітектури додатків, це має сенс, якщо ви відкриєте для себе цей напрямок на ранній стадії і встигнете адаптуватися. Замість складного вибивання веб-макетів і форм в Latte, для якого вам потрібен практично посередній розробник для вже трохи більш складного завдання, в React вам просто потрібен джуніор, який почав працювати місяць тому, і все ще не робить занадто багато помилок в майбутньому рішенні.

React дозволяє викинути великий шматок бекенду, який був написаний лише для того, щоб фронтенд міг існувати в першу чергу. Коротше кажучи, це здешевлює розробку, а в якості бонусу ви отримуєте швидшу доставку нових функцій, оскільки розробникам не потрібно знову і знову стикатися зі складними проблемами, які виникають через мову проектування PHP.

Більшості веб-додатків більше не потрібен бекенд або лише мінімальний бекенд. Коли ви відкриваєте кінцеві точки API в Node.js (також технологія, побудована на JavaScript), раптом розробник, який раніше працював тільки з React, може писати частини бекенду, тому що це та ж сама мова.

При більш глибокому аналізі проектів, які я розробив за останні 5 років, в Node.js не вистачає лише кількох речей, які все ще змушують мене використовувати PHP для деяких операцій.

А саме:

• Доктрина (і загалом доступ до реляційних баз даних на основі об'єктних сутностей)
• Надсилання та керування електронною поштою
• SOAP API (на жаль, він все ще іноді зустрічається)
• Sessions (потрібно замінити на токен JWT, наприклад)
• Складна застаріла логіка, яка була написана на PHP, і я не можу легко її рефакторити
• Швидка обробка складних структур даних, де дані потребують мутації
• Існуючі люди в команді, яких потрібно перенавчити робити щось нове

Але потім з'являється Node.js, який робить решту речей краще. Наприклад:

• Можливість вивантажити додаток прямо в хмару
• Набагато (можливо, навіть удвічі) дешевша розробка тієї ж функціональності
• Однакова логіка на BE і FE без необхідності писати код двічі
• Кінцеві точки REST API
• Паралельні виклики декількох кодів одночасно
• Можливість відправити HTTP-відповідь, але код продовжує працювати
• Приятель.
• Бібліотеки для роботи з хмарними сервісами
• Значно кращий час відгуку, оскільки вам не потрібно завантажувати величезний додаток
• Повністю функціональна парадигма (ви позбавляєтеся від DI, які вам не потрібні, наприклад, в JS)
• Робота з формами та даними
• Легкі оновлення та активна спільнота розробників

Коментар до доктрини: Я знаю, що JS має багато бібліотек для роботи з базами даних. Або навіть нові парадигми, такі як Mongo. Мені подобається, куди рухається напрямок обробки даних. З іншого боку, я вважаю, що табличні реляційні бази даних ніколи не зникнуть. Коли ви працюєте над великим проектом, де ви керуєте десятками мільйонів записів, вам просто потрібна традиційна технологія, з якою ви добре знайомі і знаєте, чого очікувати. Наприклад, думка про те, що я хочу додати стовпець (властивість), а це означатиме перемапування всіх сутностей за допомогою скрипта міграції, мене лякає.

Jan Barášek   Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu:

Kontakt