Розробники програмного забезпечення повинні бути в захваті від потенціалу цього року. Запровадження сучасних інструментів, інновацій та фреймворків забезпечить більше можливостей для більшої ефективності та набагато більше задоволення від роботи програмістом у 2023 році.
Йоав Абрахамі, головний архітектор і керівник Velo в Wix Code, розповів чому він бачить такі райдужні перспективи на 2023 рік.
«Я бачу найкращий рік, але не можу гарантувати, що в майбутньому не буде ще кращих років», — сказав він. «Я думаю, що багато надзвичайно захоплюючих речей змінюють спосіб створення коду у світі».
З цією метою Абрахамі вважає, що деякі речі відбуваються одночасно. Одна з них – це тривалий тренд переходу на основні платформи, який триває на повну силу. Інший – це більше інновацій, які виникають завдяки залученню дизайнерів до команди розробників. Подолання розриву між дизайнером і розробником є важливим, зазначив він.
6 прогнозів розробників на 2023 рік
Дивлячись у майбутнє очима розробника програмного забезпечення, Абрахамі бачить фантастичний рік для розробника. Ось його шість прогнозів щодо того, чого очікувати:
- Розробники зможуть вирішувати більш складні проекти в масштабі.
- Співпраця розробників і дизайнерів буде більш ефективною та надихаючою.
- Хмарні платформи та інструменти з низьким кодом консолідуються, пропонуючи низку нових продуктів, включаючи веб-сайти, веб-програми та мобільні програми.
- Тенденція переходу до більш керованих середовищ триватиме, пропонуючи нові та краще керовані послуги.
- AI очистить код і звільнить розробників для більш творчої роботи.
- Талант розробників буде більш децентралізованим, ніж будь-коли раніше, що означає більше різноманітності та ширшого охоплення кінцевих продуктів.
Якщо прогнози вимагають від вас переконливих причин і як , читайте далі, щоб отримати глибші пояснення Абрахамі свого бачення для спільноти розробників.
DevOps скоротив розрив
Ця історія спільноти розробників відзначена постійними суперечками між «людьми системи» та розробниками програмного забезпечення. Часто розробники постачали програмне забезпечення, яке не відповідало очікуванням, і тоді роботою системних людей було змусити його працювати, що викликало більше тертя.
«Ми вирішили це протиріччя, представивши ідею DevOps. Він переклав відповідальність за збої, спричинені системними змінами, назад на розробників, щоб стати однією командою», — зазначив Абрахамі.
Інший підхід, який допомагає розширити можливості для розробників, — це мати обидва елементи в одному робочому середовищі, запропонував він. Його компанія використовує цей метод формування команди для розробки програмного забезпечення.
Рішення Wix: Дозвольте дизайнеру взяти на себе відповідальність за дизайн і створіть одну команду, яка включає як дизайнера, так і розробника. Усі учасники отримують однакові інструменти.
«У тому самому середовищі дизайнер розробляє UI, а розробники пишуть код для роботи з UI. Реальність така, що 99,9% команд оберуть більш сучасні інструменти, як це сталося з DevOps — і ця революція станеться для розробників. Це відбувається зараз, і ми бачимо це просто тому, що проекти постачаються зі швидкістю, яку ми навіть не уявляли. Це так дивно бачити це», – вигукнув він.
Заглиблення в середовище розробника
Моя розмова з Йоавом Абрахамі продовжилася цими запитаннями та відповідями
Що дає змогу розробникам вирішувати більш складні проекти в масштабі?
Йоав Абрахамі: Ніхто, кого приєднали до команди, не проти спільної роботи розробників і дизайнерів. Це означає, що ви можете працювати набагато швидше та бути набагато продуктивнішим. Але крім того, ми продовжуватимемо переходити до більш керованих середовищ. Це означає, що ви будете набагато ефективнішими з точки зору всього свого програмного забезпечення.
Що змінюється в спільноті розробників?
Абрахамі: Ви повинні пам’ятати, що насправді таке кероване програмне забезпечення. Це завжди торгівля. Ви торгуєте своєю свободою вибору, наприклад, яка послуга працює.
Багато років тому ви працювали на власних машинах і вибирали свою ОС. Сьогодні ви навіть цього не робите. Багато років тому ви створювали сервери та намагалися визначити, яку структуру використовувати. Сьогодні ви можете використовувати кілька списків, і вам не дуже важливо, що відбувається під ними.
Дивлячись на те, що ми маємо сьогодні, ми навіть робимо ще один крок вперед. Ви навіть не обираєте свій зовнішній фреймворк. Ми надаємо вам готове рішення, у якому ваш ідентифікатор, середовище розробки, база даних, бек-енд і інтерфейс працюють разом.
Наскільки поширене це нововведення? Чи є Wix у меншості з такими підходами?
Абрахамі: Ми не єдині, хто це робимо. Це відбувається по всій галузі. Ви можете бачити все більше і більше рішень із середовищами онлайн-розробки без конфігурації необхідних платформ.
Щоб зрозуміти, про що я говорю, подумайте, скільки часу знадобиться для створення кол-центру, де тисячі волонтерів зможуть зареєструватися, пройти процес перевірки, хто вони, а потім мати змогу дзвонити людям і запитувати, чи їм потрібна допомога з ліками, їжею або будь-яким іншим під час Covid. Ймовірно, на нормальне будівництво знадобляться місяці, навіть два роки.
Ми побудували один за два тижні. За місяць цією системою користувалися 700 волонтерів. Він використовував Twilio для телефонії, готове рішення, доступне для інтерфейсу користувача для двох різних програм. Ось куди ми рухаємося, щоб бути набагато швидшими.
Я б сказав, що якщо сьогодні ви намагаєтеся створювати продукти місяцями, ви робите щось не так.
Наскільки впливають використання хмарних платформ і інструментів з низьким кодом/без коду?
Абрахамі: Ідея низького коду полягає в тому, щоб зробити вас набагато швидшими з точки зору того, що ви створюєте. Вам не потрібно писати весь код і отримувати його на основній платформі. Ви просто додаєте трохи, кілька рядків коду тут і там — і ми маємо рішення.
Але потім низький код також може стати невдачею, коли ви хочете щось зробити, наприклад порівняти 600 кроків кодування, і ви хочете щось змінити. Як ви це перевіряєте? Як перевірити цю зміну? Як ви знаєте вплив? Як ви взагалі бачите зміну між однією версією та іншою?
Як штучний інтелект впливає на те, що зараз відбувається в спільноті розробників?
Абрахамі: Чесно кажучи, ніхто не знає. Але ми знаємо, що це все зруйнує. Це реальність.
Припустімо, ви просите найкращого штучного інтелекту написати для вас код, і цей код є частиною програмного забезпечення для запуску вашого поїзда. Кого ви звинувачуєте, коли той поїзд розбився через жучок? Це вина штучного інтелекту? Це вина виробника ШІ? Чи винна людина, яка написала код із помилкою, на якій навчався ШІ?
Усі ці запитання зводяться до однієї великої проблеми: як це працюватиме? Ми не знаємо! Але ми розуміємо, що кодування ШІ має потенціал.
Чи сподіваєтесь ви на ШІ як на доброзичливий інструмент для розробників?
Абрахамі: Я бачу величезний потенціал у ШІ. Ми дивимося на якість, і в якості є дві речі, які ми не знаємо, як виміряти. Ми не знаємо, як виміряти юзабіліті, і ми не вміємо виміряти правильність. Тепер штучний інтелект може дати нам відповіді, і я, можливо, зможу створити штучний інтелект, який дасть мені це.
Куди ви бачите весь цей потенціал?
Абрахамі: Подумайте про зручність використання інтерфейсу прикладного програмування (API). Це набагато легше зробити, ніж виміряти, чи можна спробувати написати код, який вирішить вашу наступну велику проблему. Тепер це лише один приклад. Інший приклад, який ви можете подумати, стосується ШІ.
Коли мені слід збільшити чи зменшити масштаб? Коли я повинен виконати відновлення після відмови? Коли мені слід зупинити одну службу, оскільки вона спричиняє проблеми з іншими службами? І так далі.
Можливо, усі ці речі можна автоматизувати за допомогою ШІ. Автоматизація може запобігти надсиланню несправного програмного забезпечення через раннє виявлення помилок. Отже, існує багато потенціалів. Сьогодні ми можемо зробити багато речей за допомогою штучного інтелекту, щоб змінити те, як ми, як розробники, працюємо. Речі, яким ми довіряємо щодо штучного інтелекту, як-от інструменти, які допоможуть вам у тому, що ви робите.
Іншим прикладом є семантичний пошук. Часто ви входите в категорію, особливо у великих організаціях. Ви майже впевнені, що хтось у компанії зробив те, що ви шукаєте, але ви не знаєте, як це шукати, оскільки вам бракує точного синтаксису.