WEBVTT 00:00:00.210 --> 00:00:07.530 Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, що формують майбутні роботи. 00:00:07.690 --> 00:00:12.290 Цього січня M365Con повертається, і ми стаємо ще масштабнішими. 00:00:12.450 --> 00:00:18.470 Приєднуйтесь до нас на живі сесії, демонстрації реальних кейсів та практичні знання від MVP та експертів галузі з усього світу. 00:00:18.470 --> 00:00:22.070 Жодних шаблонних слайдів, жодних безкінічних модних слів. 00:00:22.230 --> 00:00:29.210 Ми розглядаємо реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація. 00:00:29.210 --> 00:00:34.970 Незалежно від того, чи ви IT-фахівець, розробник або бізнес-лідер, для вас знайдуться відповідні сесії. 00:00:35.150 --> 00:00:40.750 Протягом 10 повних днів ви зможете дослідити різноманітні технології та поспілкуватися з глобальною спільнотою. 00:00:40.950 --> 00:00:44.730 Дивіться наживо та приносте практичні інсейти у свою організацію. 00:00:44.730 --> 00:00:51.050 Січень 2027 року, 10 днів, одна спільнота Microsoft. Реєстрацію вже відкрито. 00:00:51.410 --> 00:00:56.230 Переходьте на M365Con.net і забронюйте своє місце сьогодні. 00:00:56.470 --> 00:00:59.090 Це M365Con.net. 00:00:59.210 --> 00:01:04.830 Приєднуйтесь на M365Con.net і побачимось у січні. 00:01:04.990 --> 00:01:11.950 Якщо ви коли-небудь відкривали проєкт і одразу відчували себе перевантаженими мережею файлів, посилань та помилок, що чекають на вас, ви не самотні. 00:01:11.950 --> 00:01:15.290 Більшість розробників працюють реактивно, тут підлатають, там налагодять. 00:01:15.430 --> 00:01:20.230 Режим агента GitHub Coopilot має на меті охопити ширший контекст і координувати зміни в багатьох файлах. 00:01:20.370 --> 00:01:25.210 У цьому відео ми продемонструємо, як виглядає такий робочий процес у реальному проєкті на NIT та Azure. 00:01:25.210 --> 00:01:28.670 Ми пройдемося по живому рішенню і покажемо роботу агента до та після змін. 00:01:28.830 --> 00:01:36.310 Ви побачите, як створювати багатофайловий код з меншими витратами, швидше виправляти помилки між файлами та використовувати звичайну мову для створення каркасів функцій. 00:01:36.430 --> 00:01:41.350 Але перш ніж ми перейдемо до цього, давайте почнемо з прихованої вартості циклу налагодження, у якому багато хто з нас живе щодня. 00:01:41.350 --> 00:01:43.610 Прихована вартість клаптикового налагодження. 00:01:43.770 --> 00:01:46.730 Ви сідаєте за роботу, щоб виправити помилку, яка виглядає досить простою. 00:01:46.870 --> 00:01:50.430 Додаток не збирається, а консоль вказує нарядок у вашому головному файлі проєкту. 00:01:50.610 --> 00:01:56.310 Ви підправляєте метод, перекомпілюєте і думаєте, що все вирішили, поки те саме повідомлення не з'являється знову у дещо іншій формі. 00:01:56.430 --> 00:01:59.470 Минає ще пів години, перш ніж ви помічаєте справжню проблему. 00:01:59.670 --> 00:02:02.370 Відсутня залежність, захована в іншій папці проєкту. 00:02:02.370 --> 00:02:07.350 До того моменту, як посилання виправлено і ви робите повторне розгортання, більша частина дня перетворюється на латання дірок. 00:02:07.450 --> 00:02:09.970 Заплановано роботу над новою функцією, відкладено на завтра. 00:02:10.150 --> 00:02:12.350 Цей шаблон настільки поширений, що здається нормальним. 00:02:12.490 --> 00:02:15.970 На поверхні ви ніби просуваєтесь вперед, бо кожна виправлена помилка здається перемогою. 00:02:16.110 --> 00:02:17.670 На практиці ви бігаєте по колу. 00:02:17.810 --> 00:02:21.170 Цикл виглядає так – код, компіляція, помилка, виправлення, повторення. 00:02:21.350 --> 00:02:26.850 Години зникають у гонитві за причинами та наслідками, а кінцевий результат – це реактивний прогрес, а не значущі покращення. 00:02:32.370 --> 00:02:37.170 Цей цикл виснажує тим, що інструменти навколо нас розвиваються, а підхід – ні. 00:02:37.330 --> 00:02:43.850 Редактори отримують нові функції, фреймворки еволюціонують, інтеграції стають глибшими, але налагодження все ще вимагає реактивного підходу. 00:02:43.970 --> 00:02:47.270 Це як намагатися зупинити пожежу, що розгорається одним відром води. 00:02:47.390 --> 00:02:52.630 Кожен спалах гаситься на місці, але умови, що його викликали, залишаються, гарантуючи наступну пожежу. 00:02:52.770 --> 00:02:55.470 Із кожним перемиканням вкладки зростає прихована ціна. 00:02:55.470 --> 00:02:59.990 Ви переходите від класу сервісу до файлу конфігурації, а потім стрибаєте до графа залежностей. 00:03:00.130 --> 00:03:04.470 Кожне перемикання вириває вас із логічного ланцюжка, змушуючи до розумового перезавантаження. 00:03:04.690 --> 00:03:09.790 Справа не лише в секундах, витрачених на перемикання вікон, а в розумовому навантаженні постійного відновлення контексту. 00:03:09.910 --> 00:03:13.050 Протягом дня ці маленькі перезавантаження накопичуються у щось важке. 00:03:13.230 --> 00:03:16.870 Для окремих розробників втома проявляється як розчарування та марнування часу. 00:03:17.050 --> 00:03:20.370 Для команд, що працюють над корпоративними проєктами, вплив множиться. 00:03:20.370 --> 00:03:26.510 Цикли налагодження збивають цілі спринтів, затримують випуски функцій і створюють беклог, який росте швидше, ніж зменшується. 00:03:26.670 --> 00:03:31.090 Збільшення технічного боргу – лише ще один побічний ефект годин, втрачених на гасіння пожеж. 00:03:31.230 --> 00:03:35.650 Багато команд повідомляють, що значна частина їхнього робочого часу витрачається на реактивне налагодження. 00:03:35.830 --> 00:03:37.750 Це не найбільш захоплива частина інженерії. 00:03:37.930 --> 00:03:42.030 Ніхто не планує дорожню карту навколо п'ятиразового виправлення однієї і тієї ж невідповідності залежностей. 00:03:42.030 --> 00:03:44.570 Проте саме туди йдуть ресурси тиждень за тижнем. 00:03:44.730 --> 00:03:51.250 Коли виправлення помилок стає визначенням прогресу, створення нових функцій відходить на другий план, а архітектура тихо страждає на фоні. 00:03:51.390 --> 00:03:55.450 Неприємна правда в тому, що латання дірок при налагодженні не просто сповільнює роботу. 00:03:55.670 --> 00:03:58.590 Воно зміцнює культуру реакції замість культури проєктування. 00:03:58.810 --> 00:04:01.810 Ви витрачаєте час на гасіння вогню, а не на побудову систем. 00:04:01.810 --> 00:04:07.490 Це може підтримувати життя продукту в короткостроковій перспективі, але обмежує масштабування команди та впевненість у релізах. 00:04:07.610 --> 00:04:10.230 Отже, давайте затримаємося на цьому образі гасіння пожеж. 00:04:10.350 --> 00:04:12.670 Кинутися до вогнища, вилити воду, рухатися далі. 00:04:12.790 --> 00:04:15.150 Проблема не в тому, що розробники не вміють цього робити. 00:04:15.350 --> 00:04:15.790 Вміють. 00:04:15.930 --> 00:04:18.490 Проблема в тому, що вогонь ніколи насправді не згасає. 00:04:18.690 --> 00:04:24.930 Він просто переміщується, спалахуючи в нових файлах, проєктах, конфігураціях, тримаючи всіх у режимі реагування, а не творення. 00:04:24.930 --> 00:04:29.130 Це піднімає питання, що буде, якщо цей цикл перестане лежати лише на вас. 00:04:29.290 --> 00:04:36.210 Що, якби повторювані частини цикл відстеження, перемикання та виправлення можна було керувати інакше, поки ви зосереджені на створенні. 00:04:36.350 --> 00:04:41.130 Тому що, хоча напруга від гасіння пожеж очевидна, є ще одна точка тиску, якої ми ще не торкнулися. 00:04:41.290 --> 00:04:44.890 Справжня складність виникає тоді, коли ваш проєкт – це не один файл чи модуль. 00:04:45.030 --> 00:04:48.490 Це стається, коли потрібне виправлення охоплює кілька рівнів одночасно. 00:04:48.490 --> 00:04:54.550 Уявіть, що ви відкриваєте рішення, де логіка розкидана між різними проєктами, сервісами та бібліотеками. 00:04:54.890 --> 00:05:00.250 Потрібна вам частина знаходиться в трьох місцях одночасно, і втримати це в голові окрема боротьба. 00:05:00.950 --> 00:05:03.990 Хаос багатьох файлів проти контекстного контролю ЩІ. 00:05:04.170 --> 00:05:10.890 Коли проєкти охоплюють багато рівнів, головний виклик – не написання коду, а в тому, щоб поєднати всі рухомі частини воєдину. 00:05:11.090 --> 00:05:15.950 Саме тут найбільш чітко проявляється напруга між хаосом багатьох файлів і контекстним контролем з допомогою ЩІ. 00:05:15.950 --> 00:05:19.290 Візьмемо велике NIT-рішення з десятком або більше проєктів. 00:05:19.430 --> 00:05:22.570 Будь-яка нова функція зазвичай зачіпає різні рівні одночасно. 00:05:22.690 --> 00:05:27.490 Контролер в одному місці, сервіс в іншому і набір конфігураційних файлів, що живуть де-інде. 00:05:27.650 --> 00:05:31.950 Перш ніж написати «Бодай рядок», ви витрачаєте час на відстеження посилань і перевірку залежностей, 00:05:32.050 --> 00:05:35.670 сподіваючись, що невелика зміна не спричинить несподіваних збоїв далі по ланцюгу. 00:05:35.810 --> 00:05:37.670 Такий робочий процес не виняток. 00:05:37.670 --> 00:05:42.510 Це норма для корпоративних додатків, особливо коли з'являються сервіси та інтеграції Azure. 00:05:42.710 --> 00:05:44.890 Структура таких систем не є пласкою. 00:05:45.070 --> 00:05:50.150 Інтерфейси, відображення впровадження залежностей DI та міжпроєктні посилання – усе це відіграє роль. 00:05:50.330 --> 00:05:54.430 З Azure деякі залежності виходять за межі папки рішення, функціональні додатки, 00:05:54.590 --> 00:05:58.370 прив'язки сервісної шини, налаштування ресурсів, підключення до сховищ. 00:05:58.570 --> 00:06:03.810 Ви координуєте код у своєму IDE, конфігураційні файли на диску та сервіси, визначені в хмари. 00:06:03.810 --> 00:06:06.390 Їм байдуже, що ви хотіли б робити менше кліків. 00:06:06.550 --> 00:06:10.410 Щоразу, коли ви перемикаєте контекст, ви витрачаєте енергію на відтворення повної картини. 00:06:10.590 --> 00:06:13.370 Більшість із нас намагається втримати цей контекст у робочій пам'яті. 00:06:13.550 --> 00:06:16.530 Спочатку це керовано, але з ростом проєкту з'являються помилки. 00:06:16.690 --> 00:06:19.890 Ви додаєте новий метод у сервіс, але забуваєте про його реєстрацію в DI. 00:06:20.090 --> 00:06:24.950 Ви пишете Azure функцію і лише згодом розумієте, що прив'язку не додали до хоуст, джейсон чи шаблону розгортання. 00:06:24.950 --> 00:06:28.590 Ніщо не попередить вас до часу виконання, коли ви будете зайняті налагодженням замість створення. 00:06:28.750 --> 00:06:30.510 Сам код – це не найскладніша частина. 00:06:30.750 --> 00:06:32.450 Складнощі в координації між файлами. 00:06:32.610 --> 00:06:38.630 Кожен знає це відчуття стрибати між вкладками, від контролера до сервісу, потім до моделі, далі у конфігураційні файли і назад, 00:06:38.850 --> 00:06:41.770 лише щоб врешті забути, навіщо ви взагалі відкрили цей файл. 00:06:41.870 --> 00:06:44.830 Це дрібне відволікання, що повторюється десятки разів на день. 00:06:44.990 --> 00:06:48.750 Ці взаємодії накопичуються, створюючи тертя, яке гальмує реальний прогрес. 00:06:48.750 --> 00:06:54.270 Результат – повільніша доставка не тому, що повільно пишеться код, а тому, що синхронізація всього забирає увагу. 00:06:54.370 --> 00:06:57.010 Ці накладні витрати зростають у хмарних проектах. 00:06:57.170 --> 00:07:03.190 Azure розсіює ключові налаштування по багатьох місцях, локальних конфігураційних файлах змінних середовища, 00:07:03.330 --> 00:07:06.390 шаблонах ARM або BICEP, конвоєрах CI, CD. 00:07:06.570 --> 00:07:10.830 Те, що виглядає як один запит на функцію, часто охоплює чотири рівні абстракції. 00:07:11.030 --> 00:07:12.630 Ця складність є обов'язковою. 00:07:12.830 --> 00:07:15.370 Вона закладена в саму природу роботи цієї екосистеми. 00:07:15.370 --> 00:07:18.090 Ось тут режим агента може стати справжнім проривом. 00:07:18.230 --> 00:07:23.070 Замість того, щоб залишати всю координацію на вас, він розроблений для утримання ширшого контексту в багатьох файлах. 00:07:23.210 --> 00:07:27.090 Це означає, що коли ви просите про зміни на одному рівні, він не ігнорує інші. 00:07:27.210 --> 00:07:32.110 У демонстрації я створю нову функцію Azure і покажу, як агент допомагає, створюючи тіло методу, 00:07:32.250 --> 00:07:37.770 генеруючи конфігурацію прив'язки, оновлюючи хоуст, JSON і навіть пропонуючи правильну реєстрацію DI. 00:07:38.030 --> 00:07:41.190 Зазвичай це багатоетапний процес, розкиданий по різних файлах. 00:07:41.190 --> 00:07:44.070 Агент може оптимізувати його в єдиний робочий процес. 00:07:44.190 --> 00:07:50.510 Йдеться не про заміну вашого судження, а про усунення рутинної роботи, щоб ви могли зосередитися на виборі архітектури. 00:07:50.690 --> 00:07:54.090 Люди можуть тримати в голові загальний план або начерки на дошці. 00:07:54.270 --> 00:07:57.970 Ще може відстежувати деталі файл за файлом, не втрачаючи логічної нитки. 00:07:58.130 --> 00:08:02.050 Те, що для нас є величезним когнітивним навантаженням, для агента – базовий контекст. 00:08:02.050 --> 00:08:07.150 Різниця на практиці полягає в переході від постійного перемикання між вкладками до скоординованих змін, що залишаються синхронізованими. 00:08:07.270 --> 00:08:12.610 Під час демонстрації я також покажу створений агентом запит на злиття Pull Request або різницю DI, щоб ви бачили, які саме правки були внесені. 00:08:12.710 --> 00:08:14.190 Така прозорість має значення. 00:08:14.370 --> 00:08:19.110 Ви отримуєте повний контроль для перегляду та схвалення, тоді як чорнова робота з оновлення багатьох файлів виконується за вас. 00:08:19.110 --> 00:08:26.110 Тож замість того, щоб витрачати вечір на шивання фрагментів коду, ви спрямовуєте зміни, підтверджуєте згенеровані оновлення і переходите до проєктування вищого рівня. 00:08:26.230 --> 00:08:34.230 Полегшення полягає не лише у збережених кліках чи натисканнях клавіш, а в можливості зосередитися на вирішенні реальних проблем, а не на згадуванні того, як пов'язані між собою десятки файлів. 00:08:34.230 --> 00:08:42.210 Ця перевага найчіткіше проявляється, коли все ламається, адже навіть з кращою обробкою контексту системи дають збої, конфігурації зміщуються, а невідповідні посилання знову з'являються. 00:08:42.370 --> 00:08:47.190 І ось тут починається наступне випробування, як помилки знаходяться та усуваються після їх виникнення. 00:08:47.370 --> 00:08:49.470 Від пошуку помилок до автономних виправлень. 00:08:49.610 --> 00:08:53.750 Подумайте, як часто ви стикалися з повідомленням про помилку, що прямо вказує на один файл. 00:08:53.770 --> 00:08:58.510 Ви слідуєте трасуванням стека до названого методу, вносите невелике коригування і натискаєте «перебудувати». 00:08:58.510 --> 00:09:03.270 Це здається очевидним рішенням, поки та сама помилка не з'являється знову, але вже в дещо іншій формі. 00:09:03.410 --> 00:09:06.370 Саме тоді ви розумієте, що трасування стека показувало лише симптом. 00:09:06.550 --> 00:09:11.810 Справжня проблема ховається зовсім в іншому місці, можливо, у допоміжному класі або всередині конфігураційного файлу, який ви не відкривали цілий тиждень. 00:09:11.950 --> 00:09:14.110 Кожен розробник стикався з таким введенням в оману. 00:09:14.190 --> 00:09:17.050 Те, що виглядає як проблема, насправді не завжди є місцем, де потрібне виправлення. 00:09:17.050 --> 00:09:20.650 Це швидко з'їдає час. Ви вносите зміни, перезбираєте, чекаєте. 00:09:20.790 --> 00:09:25.170 Потім з'являється нова помилка, яка веде до іншого файлу, ще одного налаштування та чергової перезбірки. 00:09:25.330 --> 00:09:32.050 Цей цикл виглядає продуктивним, бо ви рухаєтеся, пишете код, компілюєте, але по суті це більше спроби і помилки, ніж реальне рішення. 00:09:32.230 --> 00:09:38.530 Такий цикл може поглинути години, залишивши вас із дрібними виправленнями, але без реального прогресу у функціоналі, з якого ви починали. 00:09:38.710 --> 00:09:40.870 Справжня ціна тут – це втрачені можливості. 00:09:40.870 --> 00:09:47.630 Поки ви застрягли в ритмі перезбірка, спроба, ви не вирішуєте бізнес-завдання і не випускаєте функціонал, на який чекають користувачі. 00:09:47.770 --> 00:09:50.430 Енергія витрачається на здогадки замість проєктування. 00:09:50.590 --> 00:09:56.150 У моменті це відчувається як активна робота, але ці години не дають нічого, крім підтримки системи в робочому стані. 00:09:56.290 --> 00:10:01.770 У команді цей поверхневий рух уповільнює все і створює накопичення функцій, які постійно відкладаються. 00:10:01.930 --> 00:10:04.830 Ось тут робочий процес агента починає виглядати інакше. 00:10:04.830 --> 00:10:08.450 Ідея не в тому, щоб зупинитися на одному рядку, який виділяє трасування стека. 00:10:08.650 --> 00:10:14.030 Натомість він спроєктований так, щоб утримувати контекст на рівні системи, запитуючи не лише, що має робити цей файл, 00:10:14.110 --> 00:10:18.050 а й яка послідовність змін потрібна для всіх пов'язаних частин, щоб відновити цілісність. 00:10:18.190 --> 00:10:22.390 На практиці це означає, що він може пропонувати редагування, які охоплюють декілька файлів. 00:10:22.530 --> 00:10:26.750 Наприклад, у демо ви побачите, коли метод потребує змін, агент може запропонувати відповідні редагування 00:10:26.750 --> 00:10:30.890 у пов'язаних конфігураціях або шаблонах розгортання, замість того, щоб ви шукали їх самостійно. 00:10:31.010 --> 00:10:33.710 Це перехід від автодоповнення до чогось значно ширшого. 00:10:34.010 --> 00:10:38.690 Автодоповнення завершує рядки, а агент координує роботу між файлами, і ця координація найважливіша, 00:10:38.750 --> 00:10:40.650 коли помилки не зосереджені в одному місці. 00:10:40.830 --> 00:10:42.470 Візьмемо типовий сценарій Azure. 00:10:42.630 --> 00:10:48.250 Ви створили новий додаток функцію, але після розгортання тригер черги дає збій, оскільки прив'язка не відповідає сигнаторі методу. 00:10:48.250 --> 00:10:53.650 Зазвичай ви переглядаєте логи, з'ясовуєте, яка прив'язка помилкова, вручно коригуєте JSON функції 00:10:53.650 --> 00:10:57.570 і, можливо, навіть змінюєте шаблон інфраструктури, якщо там також є невідповідність. 00:10:57.690 --> 00:11:01.610 Кожен крок – це окрема гонитва, і кожне виправлення запускає черговий тест. 00:11:01.730 --> 00:11:03.910 У режимі агента робочий процес інший. 00:11:04.090 --> 00:11:07.610 Він може запропонувати зміну коду, згенерувати правильну прив'язку JSON для функції 00:11:07.610 --> 00:11:10.390 та вивести редагування для скриптів розгортання, якщо вони не узгоджені. 00:11:10.390 --> 00:11:14.410 Ви перевіряєте, підтверджуєте і рухаєтеся далі, не витрачаючи години на те, щоб зібрати кожен рівень докупи. 00:11:14.510 --> 00:11:15.990 І довіра тут є ключовим фактором. 00:11:16.110 --> 00:11:18.850 Ніхто не повинен відчувати, що у фоновому режимі відбуваються невидимі редагування. 00:11:18.990 --> 00:11:20.510 Ось чому важливий процес перегляду. 00:11:20.650 --> 00:11:22.710 У цій демонстрації ми пройдемо через це разом. 00:11:22.870 --> 00:11:24.770 Агент пропонує скоординовані зміни. 00:11:24.910 --> 00:11:29.270 Ми відкриємо DIV, щоб побачити, що саме було згенеровано, запустимо наші модульні тести, 00:11:29.270 --> 00:11:33.030 перевіримо збірку локально і лише тоді вирішимо, прийняти чи відхилити зміни. 00:11:33.170 --> 00:11:37.230 Цей цикл перевірки залишає за вами повний контроль, позбавляючи відрутинної роботи. 00:11:37.390 --> 00:11:42.110 Варто підкреслити, агенти допомагають рухатися швидше, але вони не замінюють належні інженерні практики. 00:11:42.290 --> 00:11:45.730 Вам все одно слід вважати перевірку коду та CI обов'язковими бар'єрами. 00:11:45.910 --> 00:11:51.250 Дозвольте ще скоротити час на пошук помилок, але залиште автоматичні перевірки та людський контроль як запобіжний засіб. 00:11:51.250 --> 00:11:55.750 Цей баланс вирішує проблему довіри та гарантує, що приріст швидкості не зашкодить стабільності. 00:11:55.910 --> 00:11:58.030 Різниця у швидкості не є теоретичною. 00:11:58.170 --> 00:12:03.350 Там, де виправлення помилок вручну може забрати півдня, узгоджені пропозиції скорочують цей час до хвилин. 00:12:03.470 --> 00:12:07.410 Ізекономлений час спрямовується на роботу, на яку ви дійсно хочете витрачати енергію. 00:12:07.530 --> 00:12:11.570 На функції, які помічають користувачі, та архітектурні рішення, що покращують вашу кодову базу. 00:12:11.570 --> 00:12:15.550 Замість гасіння пожеж під час виконання програми, ви можете впевнено проєктувати все заздалегідь. 00:12:15.630 --> 00:12:18.350 Тож цикл налагодження більше не повинен визначати ваш день. 00:12:18.510 --> 00:12:23.790 З агентом, що пропонує оновлення між файлами, ви переходите від хаотичного пошуку до ритму перегляду та схвалення. 00:12:23.970 --> 00:12:30.270 Ви перестаєте блокати колами помилок і починаєте розглядати налагодження як структурований, майже автоматизований крок у робочому процесі. 00:12:30.430 --> 00:12:34.670 Цей соф звільняє ментальний простір і час для створення функцій, а не лише виправлення недоліків. 00:12:34.670 --> 00:12:39.450 І коли виправлення помилок перестає бути лише боротьбою із симптомами, це відкриває двері до чогось більшого. 00:12:39.610 --> 00:12:42.930 Як ви могли б розпочинати цілі функції у такий самий структурований спосіб? 00:12:43.110 --> 00:12:50.590 Уявіть, якби той самий робочий процес, що пропонує узгоджені виправлення, міг також взяти специфікацію простою мовою і сформувати навколо неї робочу структуру. 00:12:50.790 --> 00:12:53.170 Саме тут починається наступний етап розробки. 00:12:53.330 --> 00:12:55.890 Розробка на основі специфікації без зайвих зусиль. 00:12:55.890 --> 00:13:02.630 Одна з найцікавіших змін відбувається тоді, коли ви перестаєте думати лише категоріями файлів і методів, а починаєте формулювати роботу простою мовою. 00:13:02.830 --> 00:13:06.050 Саме тут на допомогу приходить розробка на основі специфікацій без зайвих зусиль. 00:13:06.190 --> 00:13:08.650 Уявіть, що ви пишете простий запит на нову функцію. 00:13:08.830 --> 00:13:14.290 Додати робочий процес звітності, який генерує щомісячні підсумки, зберігає їх і робить доступними через адмінпанель. 00:13:14.290 --> 00:13:19.990 Замість того, щоб отримувати лише кілька окремих фрагментів, ви отримуєте робочу структуру, вже інтегровану у ваш додаток. 00:13:20.090 --> 00:13:24.770 Контролери створені, моделі підготовлені, сервіси зареєстровані, а конфігурація налаштована. 00:13:24.950 --> 00:13:31.670 Цей перехід від опису намірів до появи конкретного каркаса у вашому проєкті робить цей підхід практичним, а не теоретичним. 00:13:31.850 --> 00:13:35.790 У традиційних налаштуваннях розробка на основі специфікацій має важку репутацію. 00:13:35.790 --> 00:13:42.150 У великих організаціях це зазвичай означає довгі документи з вимогами, багатосторінкові дизайн-макети та жорсткі діаграми, що всіх сповільнюють. 00:13:42.290 --> 00:13:47.690 Вони мають сенс у регульованих галузях або в розподілених командах, але для повсякденного програмування більшість розробників їх пропускають. 00:13:47.830 --> 00:13:52.110 Написання та підтримка детальних специфікацій потребують витрат, на які ніхто не має часу чи терпіння. 00:13:52.270 --> 00:13:57.830 Це додаткова робота до реалізації функцій, і коли дедлайни підтискають, ці додаткові зусилля зазвичай приносяться в жертву. 00:13:57.830 --> 00:14:01.470 Іронія очевидна, розробникам насправді подобається мислити ширшими категоріями. 00:14:01.630 --> 00:14:04.090 Розуміння структури заздалегідь додає впевненості. 00:14:04.210 --> 00:14:06.450 Проблема не в намірах, а в підтримці актуальності. 00:14:06.630 --> 00:14:10.630 Як тільки специфікація починає розходитися з реальністю, її підтримка стає тягарем. 00:14:10.770 --> 00:14:17.610 Ось чому в реальній роботі все частіше вдаються до імпровізації, а не повного проєктовання, навіть у компаніях, які офіційно підтримують ретельне планування. 00:14:17.770 --> 00:14:20.170 Агентський робочий процес пропонує альтернативу. 00:14:20.170 --> 00:14:26.330 Замість вимагати готовий документ з дизайном, він може допомогти перетворити специфікацію простою мовою на каркас, який можна доопрацювати. 00:14:26.490 --> 00:14:33.610 Вам не потрібні UML-діаграми чи рукописні карти інтерфейсів, ви можете просто сказати «Створи модуль звітності з новою Ari Endpointом, 00:14:33.690 --> 00:14:40.170 підключи його до сховища та захисти за допомогою рольового доступу, і система згенерує основу у файлах вашого NIT-рішення». 00:14:40.750 --> 00:14:47.810 У демо я прочитаю специфікацію простою мовою, потім покажу створені агентом файли, контролери, моделі та реєстрацію сервісів, 00:14:47.810 --> 00:14:50.870 і вкажу на місця, що потребували ручного доопрацювання. 00:14:51.050 --> 00:14:53.450 Так ви зможете самостійно оцінити якість. 00:14:53.570 --> 00:14:56.610 Це створює золоту середину між двома стилями розробки. 00:14:56.810 --> 00:15:01.150 З одного боку, це вайбі-кодинг – швидко та вільно, але крихко для довгострокових систем. 00:15:01.390 --> 00:15:05.610 З іншого боку, дизайн на основі специфікацій – надійно, але дуже повільно. 00:15:05.790 --> 00:15:10.910 З допомогою агента ви описуєте ідею природною мовою, з'являється каркас, і ви можете працювати майже так само швидко, 00:15:10.910 --> 00:15:14.110 як при вайбі-кодингу, зберігаючи переваги організованої структури. 00:15:14.230 --> 00:15:16.570 Візьмемо знову той самий робочий процес звітності. 00:15:16.710 --> 00:15:20.910 Зазвичай вам довелося б створити модель, побудувати сервіс даних, підключити контролер, 00:15:21.030 --> 00:15:23.370 налаштувати безпеку та з'єднати все це в стартап. 00:15:23.470 --> 00:15:27.190 Це означає перемикання між багатьма файлами з надією на збереження узгодженості. 00:15:27.350 --> 00:15:29.690 З цим підходом каркас вибудовується миттєво. 00:15:29.890 --> 00:15:32.750 Справжня економія полягає не стільки в зменшеній кількості рядків коду, 00:15:32.750 --> 00:15:36.970 скільки в уникненні помилок між файлами, як-от забути зареєструвати новий сервіс після його створення. 00:15:37.130 --> 00:15:39.190 Звісно, завжди виникає питання стилю. 00:15:39.310 --> 00:15:42.090 Чи на в'яжеші шаблонний код або проігнорує конвенції? 00:15:42.330 --> 00:15:45.750 На практиці агенти часто наслідують наявні шаблони проєкту у своїх пропозиціях. 00:15:46.530 --> 00:15:48.410 У демо ви побачите обидві сторони. 00:15:48.550 --> 00:15:51.110 Моменти, де він ідеально влучив у структуру наших контролерів, 00:15:51.170 --> 00:15:53.950 і моменти, де його припущення не зовсім збіглися з очікуваннями. 00:15:54.090 --> 00:15:55.470 Це поєднання є важливим. 00:15:55.470 --> 00:15:58.310 Ви будете знати, чому можна довіряти, а що ще потрібно виправити. 00:15:58.450 --> 00:16:00.630 Кінцевий результат – це не шаблонний код під копірку. 00:16:00.770 --> 00:16:04.150 Це все ще ваш проєкт, просто з меншою кількістю рутинної роботи над каркасом. 00:16:04.310 --> 00:16:08.910 Ви зберігаєте швидкість, спираючись на основу, яку можна вдосконалювати для майбутнього розвитку. 00:16:09.090 --> 00:16:13.150 Замість того, щоб створення специфікацій було справою архітекторів, які мають терпіння до схем, 00:16:13.250 --> 00:16:17.530 воно стає інструментом для будь-якого розробника, що хоче швидко експериментувати без втрати порядку. 00:16:17.530 --> 00:16:20.370 І коли це стає частиною вашого щоденного робочого процесу, 00:16:20.470 --> 00:16:24.910 специфікація перестає сприйматися як формальний корпоративний етап і стає легким способом опису. 00:16:25.070 --> 00:16:29.550 Ви описуєте свій намір, система закладає основу, а ви зосереджуєтесь на опрацюванні деталей. 00:16:29.770 --> 00:16:34.910 Більший вплив має не лише код, який ви створюєте, а те, що економія часу означає для вас тиждень за тижнем. 00:16:35.110 --> 00:16:38.250 Більше годин на функціонал, менше виснажливої роботи з налаштуванням. 00:16:38.370 --> 00:16:42.090 Це підводить нас безпосередньо до питання, яке найбільше хвилює кожного розробника. 00:16:42.090 --> 00:16:45.270 Що ці зміни дають, насправді, з погляду продуктивності? 00:16:45.450 --> 00:16:47.090 Дивіденди від продуктивності. 00:16:47.230 --> 00:16:50.650 Справжнє питання не в тому, чи заощадите ви кілька хвилин тут і там, 00:16:50.770 --> 00:16:54.470 а в тому, як ці дрібні зміни накопичуються в значні години протягом тижня. 00:16:54.630 --> 00:16:56.590 Це і є дивіденди від продуктивності. 00:16:56.710 --> 00:17:00.030 Повернення часу, який зазвичай непомітно витрачається на перемикання контексту, 00:17:00.130 --> 00:17:02.250 повторні цикли збірки та ручне виправлення помилок. 00:17:02.390 --> 00:17:05.710 Більшість розробників сприймають ці дрібні втрати як невід'ємну частину роботи. 00:17:05.710 --> 00:17:07.610 10 хвилин на пошук значення конфігурації, 00:17:07.730 --> 00:17:09.830 ще 15 на перезапуск після пропущеного посилання 00:17:09.830 --> 00:17:11.910 або перестрибування між файлами для перевірки зв'язків. 00:17:12.070 --> 00:17:13.890 Самі по собі вони здаються незначними. 00:17:14.030 --> 00:17:15.730 Але додані разом протягом цілого спринту, 00:17:15.870 --> 00:17:18.450 вони впливають на те, скільки реальної цінності буде доставлено. 00:17:18.550 --> 00:17:19.910 Те, що виглядає як рутенні дії, 00:17:20.050 --> 00:17:22.150 приховує реальне гальмування термінів виконання завдань. 00:17:22.290 --> 00:17:25.170 Прихований тягар полягає не в часі компіляції чи швидкості друку. 00:17:25.170 --> 00:17:27.170 Він у рваному ритмі, що нав'язується вашій концентрації. 00:17:27.870 --> 00:17:29.810 Щоразу, коли ви переходите від одного файлу до іншого, 00:17:29.930 --> 00:17:31.010 ваш мозок перезавантажується. 00:17:31.150 --> 00:17:32.830 Це перезавантаження має свою ціну. 00:17:33.050 --> 00:17:35.970 Перекладання повторюваних виправлень на агента полегшує цей тягар. 00:17:36.090 --> 00:17:38.090 Замість того, щоб постійно відновлювати контекст, 00:17:38.230 --> 00:17:40.010 ви спрямовуєте фокус туди, де це важливо, 00:17:40.130 --> 00:17:41.990 на вирішення складніших архітектурних завдань. 00:17:42.170 --> 00:17:44.090 Багато команд не відстежують ці мікровитрати, 00:17:44.210 --> 00:17:46.630 бо вони не відображаються в ті китах джіра чи історії діт. 00:17:46.630 --> 00:17:48.570 Робота, яка нікуди не веде, не логується, 00:17:48.690 --> 00:17:50.290 але вона все одно споживає енергію. 00:17:50.410 --> 00:17:51.870 І в міру масштабування кодових баз, 00:17:51.970 --> 00:17:53.590 це тертя додається не просто лінійно. 00:17:53.750 --> 00:17:55.390 Більше рівнів означає більше залежностей, 00:17:55.510 --> 00:17:56.530 які треба тримати в пам'яті, 00:17:56.590 --> 00:17:58.850 і більше шансів витратити час просто на узгодження структури 00:17:58.850 --> 00:17:59.890 перед продовженням роботи. 00:17:59.990 --> 00:18:01.850 Робочі процеси з агентами змінюють правила гри, 00:18:01.930 --> 00:18:03.330 безпосередньо усуваючи ці втрати. 00:18:03.530 --> 00:18:05.790 Вони не просто швидше заповнюють заготовки методів. 00:18:05.790 --> 00:18:08.430 Вони скорочують цикли пошуку, виправлення та перезапуску, 00:18:08.550 --> 00:18:09.670 які з'їдають цілі вечори. 00:18:09.770 --> 00:18:11.850 Команди, що використовують агентні робочі процеси, 00:18:11.910 --> 00:18:14.350 у багатьох випадках повідомляють про швидше розблокування роботи. 00:18:14.490 --> 00:18:16.410 У цьому відео ми продемонструємо завдання, 00:18:16.550 --> 00:18:18.450 до та після, щоб ви могли оцінити вплив. 00:18:18.630 --> 00:18:22.190 Я запишу час, необхідний для реалізації тієї ж функції Azure вручну, 00:18:22.290 --> 00:18:24.890 а потім з агентом, щоб ви побачили приріст продуктивності 00:18:24.890 --> 00:18:25.810 в конкретних цифрах. 00:18:25.810 --> 00:18:29.110 З погляду бізнесу цінність проявляється у швидкості проєктів. 00:18:29.250 --> 00:18:31.830 Швидші цикли – це не лише про задоволення розробників. 00:18:32.010 --> 00:18:34.070 Вони вирішують, чи вийдуть функції у цьому релізі, 00:18:34.150 --> 00:18:35.490 чи відкладуться на квартали вперед. 00:18:35.630 --> 00:18:38.110 Вони впливають на технічний борг, оскільки менше хаків 00:18:38.110 --> 00:18:39.630 і регресій потрапляє до беклогу. 00:18:39.750 --> 00:18:42.290 Плавніший робочий процес дозволяє командам рухатися вперед, 00:18:42.390 --> 00:18:44.810 замість того, щоб переробляти зламані з попереднього спринту. 00:18:44.810 --> 00:18:47.250 Така послідовність часом зменшує гасіння пожеж 00:18:47.250 --> 00:18:48.830 і покращує результати доставки. 00:18:49.030 --> 00:18:50.490 Існує також людський фактор. 00:18:50.690 --> 00:18:53.590 День, витрачений на пошук помилок, виснажує будь-якого інженера. 00:18:53.750 --> 00:18:55.930 Коли ви втомлені, якісне проєктування стає важчим, 00:18:56.050 --> 00:18:57.930 деталі вислизають, а помилки накопичуються. 00:18:58.110 --> 00:19:00.270 Перекладаючи механічні виправлення на агента, 00:19:00.430 --> 00:19:02.490 розробники довше залишаються зосередженими. 00:19:02.670 --> 00:19:05.910 Ця додаткова увага підвищує і продуктивність, і якість. 00:19:05.910 --> 00:19:08.090 Коли вас не гальмують постійні перешкоди, 00:19:08.170 --> 00:19:10.890 ви можете мислити ширше і планувати ефективніше. 00:19:10.890 --> 00:19:13.010 Різниця на практиці виглядає так. 00:19:13.150 --> 00:19:16.410 Нова функція Azure з багатьма прив'язками та інтеграціями служб 00:19:16.410 --> 00:19:18.830 може розтягнутися на два повні дні без допомоги. 00:19:18.970 --> 00:19:21.790 Через налаштування, тестування та виправлення помилок 00:19:21.790 --> 00:19:23.810 у посиланнях завдання затягується. 00:19:24.010 --> 00:19:27.330 З допомогою агента ту саму функцію можна створити за півдня. 00:19:27.530 --> 00:19:29.010 Не тому, що ми щось спрощуємо, 00:19:29.010 --> 00:19:32.290 а тому, що налаштування та оркестрація між файлами працюють одразу. 00:19:32.490 --> 00:19:35.870 Терміни скорочуються завдяки усуненню хибних кроків та зайвої роботи. 00:19:35.870 --> 00:19:38.350 Деякі розробники висловлюють слушне занепокоєння. 00:19:38.470 --> 00:19:41.530 Чи не притупляє ваші власні навички покладання наші в питаннях підтримки? 00:19:41.670 --> 00:19:44.470 Такий погляд часто не помічає того, що насправді змінюється. 00:19:44.670 --> 00:19:47.530 Делегування рутинних завдань не послаблює вашу експертизу, 00:19:47.670 --> 00:19:49.890 воно зберігає її для дизайну та архітектури. 00:19:50.030 --> 00:19:52.710 Насправді ви отримуєте простір для вирішення складніших завдань 00:19:52.710 --> 00:19:55.190 замість того, щоб витрачати енергію на дрібні виправлення. 00:19:55.190 --> 00:19:58.990 Якщо спробуєте це, напишіть у коментарях, скільки годин ви зекономіли за спринт. 00:19:59.010 --> 00:20:01.450 Я використаю цікаві відповіді у майбутніх відео. 00:20:01.590 --> 00:20:04.190 Розуміння того, як інші команди сприймають ці зміни, 00:20:04.290 --> 00:20:06.970 дає кращу картину реальної цінності поза межами демо. 00:20:07.090 --> 00:20:10.610 Однак зауважте, автоматизація допомагає, але безпека все одно важлива. 00:20:10.750 --> 00:20:14.530 Завжди запускайте тести та використовуйте перевірку коду для валідації змін від агента. 00:20:14.710 --> 00:20:18.190 Вірте, що рутинної роботи стане менше, але дотримуйтеся тих самих правил безпеки. 00:20:18.190 --> 00:20:21.590 Різниця у швидкості виправдовує себе лише тоді, коли якість залишається стабільною. 00:20:21.730 --> 00:20:26.010 Надійні тести та розумний перегляд піар захищають ваш релізний конвейер від крихкої автоматизації. 00:20:26.210 --> 00:20:28.710 Вигода полягає не стільки у швидкому написанні рядків коду, 00:20:28.850 --> 00:20:31.210 скільки у звільненні ресурсу для створення кращих рішень. 00:20:31.390 --> 00:20:33.130 З меншою втомою та меншою кількістю.