Розробка – це ітеративне створення чогось нового та корисного.
Коли ми думаємо про розробку, часто на думку спадає розробка нових продуктів. Це відрізняється від виробництва, яке виготовляє окремі продукти; натомість, воно передбачає створення проектних специфікацій або форм для продуктів.
Таким чином, креслення або форми, створені в процесі розробки нового продукту, багаторазово використовуються на заводах для виробництва численних ідентичних продуктів.
Існують також такі застосування, як розвиток індивідуальних здібностей або розвиток суспільства та націй. Це означає не просто збільшення того, чим володіє людина, а здатність багаторазово використовувати та отримувати вигоду від розвинених можливостей.
Хоча економічна потужність окремих людей та суспільств може коливатися через економічні умови, розвинені можливості є, по суті, постійними.
Навіть якщо вони зменшуються, це вважається занепадом, а не коливаннями економічного процвітання.
Окрім цього, існує також розвиток технологій та знань. На відміну від можливостей окремих осіб або конкретних суспільств, вони мають характеристику легкої доступності для обміну.
Серед продуктів, можливостей, знань та технологій, що є результатом цих розробок, деякі можуть сприяти подальшому розвитку.
Шляхом розробки таких корисних результатів розширюється сфера розробки, а також покращується ефективність та якість.
Розробка програмного забезпечення на основі ШІ
Зазвичай, розробка вимагала значних витрат часу та зусиль. Особливо в міру розвитку суспільства та ускладнення різних речей, створення нового стає ще важчим.
Однак, з появою генеративного ШІ ця ситуація змінюється. Наразі розробка програмного забезпечення переживає драматичні зміни завдяки високим можливостям генеративного ШІ у програмуванні.
У цьому контексті майбутнє, де автономні агенти на основі генеративного ШІ стануть центральними фігурами в розробці програмного забезпечення як інженери-програмісти, вже стає реальністю.
Наразі ми перебуваємо в перехідній фазі. Хоча ми не можемо повністю довірити розробку генеративному ШІ, вправне використання генеративного ШІ може потужно прискорити розробку програмного забезпечення.
Це називається розробкою програмного забезпечення на основі ШІ.
Розробка, що розвивається
Коли генеративний ШІ підвищує ефективність розробки програмного забезпечення, він може оптимізувати не лише розробку кінцевого цільового програмного забезпечення, а й розробку програмного забезпечення, що допомагає в самому процесі розробки.
Як зазначалося раніше, результати, що полегшують розробку, розширюють її масштаби та допомагають покращити ефективність та якість. Більше того, якщо їх ефективно створити, їх можна повторно використовувати в інших проектах розробки.
Таким чином, розробляючи програмне забезпечення, яке допомагає в розробці під час процесу розробки програмного забезпечення, можна підвищити загальну ефективність, а ці активи можна використовувати для майбутніх розробок.
Традиційно, розробка такого допоміжного програмного забезпечення була поширеною практикою, але вона вимагала власного часу та зусиль, що вимагало ретельного розгляду та цілеспрямованого виконання.
Використовуючи генеративний ШІ, можна швидко створити просте програмне забезпечення для автоматизації невеликих завдань, які приходять на думку. Якщо завдання передбачає чітку обробку, генеративний ШІ може точно генерувати програму майже без помилок.
Отже, розробка програмного забезпечення для допомоги в розробці під час процесу розробки програмного забезпечення стала простішою, ніж раніше.
І, глибоко розмірковуючи над цим, виникає стиль розробки, де корисні інструменти для розробки постійно створюються в процесі, тим самим трансформуючи саму методологію розробки.
Ми назвемо це "розробкою, що розвивається".
Щоб практикувати розробку, що розвивається, потрібна звичка об'єктивно спостерігати за власною розробкою програмного забезпечення, обмірковуючи, які частини можуть бути оброблені програмним забезпеченням, а які лише людьми, а також навички розробки такого допоміжного програмного забезпечення.
Крім того, генеративний ШІ може бути інтегрований у ці програмні інструменти. Вбудовуючи його в програмне забезпечення, на відміну від агентів генеративного ШІ, обсяг обробки можна певною мірою звузити, а шляхи визначити.
Хоча агенти ШІ можуть досягати подібних результатів за допомогою підказок, програмне забезпечення з вбудованим генеративним ШІ може легше підвищити точність, поєднуючи як програми, так і підказки.
Якщо така розробка, що розвивається, може бути практикована, другий проект покаже покращення як якості, так і вартості порівняно з першим. Більше того, з кожним наступним проектом – третім, четвертим і так далі – покращення будуть продовжувати накопичуватися.
Це абсолютно відрізняється від простого використання генеративного ШІ для розробки програмного забезпечення. З часом між командами, які просто освоюють інструменти генеративного ШІ, і командами, які практикують розробку, що розвивається, виникне значний розрив.
Тестування на основі рефакторингу
Існує концепція під назвою Тест-орієнтована розробка (TDD), де спочатку розробляються тести на основі специфікацій, а потім створюється програмне забезпечення, щоб пройти ці тести.
Спочатку я також думав, що використовуючи генеративний ШІ, було б легко розробляти тестові програми для автоматизованого тестування, що робило б TDD здійсненним.
Однак, коли я почав практикувати розвиткову розробку, я дійшов висновку, що мислення про тести перед їх впровадженням не завжди є найвідповіднішим підходом.
Особливо для програмного забезпечення, такого як веб-додатки, що включають суб'єктивні аспекти, такі як зручність використання та візуальний дизайн, з якими користувач безпосередньо взаємодіє, я зрозумів, що фактичний запуск та взаємодія з програмним забезпеченням має пріоритет над детальними тестами.
Це пояснюється тим, що якщо після взаємодії з ним виникає значне незадоволення на рівні інтерфейсу/досвіду користувача, існує ймовірність бажання змінити фундаментальні частини, такі як фреймворк, базову архітектуру, модель даних або варіанти використання.
У моєму поточному особистому проекті розробки програмного забезпечення я помітив проблеми з гнучкістю функціоналу та продуктивністю, і в підсумку замінив два фреймворки на інші.
Мені також довелося повністю переглянути обробку в деяких областях через неефективне використання пам'яті.
Саме в ці моменти рефакторингу тестування вперше стає усвідомленою метою.
Якщо це на ранній стадії розробки, або якщо функції та специфікації все одно значно зміняться, тести можуть бути непотрібними.
Однак, якщо розробка вже досить просунута і є багато елементів для перевірки, тести будуть необхідні для підтвердження того, що рефакторинг не вніс функціональних дефектів або упущень.
Тому підхід створення тестових програм, коли розробка досягла певного рівня і стає необхідним рефакторинг, не є поганою ідеєю.
На цьому етапі ключовим є не створення тестів для всього коду, а зосередження на тестуванні зрілих частин, які навряд чи значно зміняться в майбутньому, залишаючи гнучкі частини без автоматизованих тестів.
Це можна назвати Тестуванням, керованим рефакторингом.
Висновок
Генеративний ШІ кардинально змінює розробку програмного забезпечення.
У попередній статті я писав про важливість прагнення стати «Всебічним інженером», здатним розробляти системи, що поєднують різні домени, інфраструктури та середовища виконання, виходячи за рамки традиційного повного стеку інженера.
Я також написав статтю, припускаючи, що ми вступаємо в еру «розробки, орієнтованої на досвід і поведінку», де основна увага приділяється не узгодженню специфікацій з реалізацією, а покращенню користувацького досвіду через поведінку програмного забезпечення.
Розвивальна розробка та тестування, кероване рефакторингом, – це саме те, що веде до цих нових горизонтів у розробці програмного забезпечення.