Лівий стіл Абстракт і I. Введення II. Підхід А. Архітектурний дизайн Б. Доказ реалізації концепції III. Прогнозовані сценарії використання IV. Експериментальний дизайн та демографія A. Учасники Б. Цільова система та завдання В. Процедура V. Результати та обговорення VI. Зв'язана робота VII. Висновки та майбутня робота, визнання та посилання III. Плановані сценарії використання Крім використання передових (веб) технологій, наш підхід можна відрізнити від пов'язаної роботи за допомогою використання динамічного аналізу та функцій співпраці SV. Тому ми зараз вводимо передбачені сценарії використання, які можуть випливати з нашого підходу та пов'язаних майбутніх робіт. Сценарій 1 (SC1): полегшити процес введення в експлуатацію У професійному розробці програмного забезпечення компанії використовують різні методики для процесу набору нових розробників. Підтримка співбесіди, огляд продукту та прості завдання сприймаються в цьому контексті як корисні [22], при цьому знаходячи документацію та технічні проблеми, наприклад, встановлення середовища розробки, перешкоджають процесу набору, особливо для віддаленої роботи [23]. Крім того, ми передбачаємо сценарій, де все більші порції вихідного коду (наприклад, залежно від досвіду) безпосередньо пов'язані з суб'єктами SV. Це дозволяє розробникам зрозуміти, яка частина вибору вихідного коду діє в яких випадках використання. Підхід потім може бути використаний для обміну текстовими завданнями на дошці, де розробники також стикаються з невеликими завданнями, включаючи такі завдання Сценарій 2 (SC2): висвітлення змін під час перегляду коду Однак рецензенти, як правило, дають вакуумні відгуки та повідомляють про обмеження інструментів рецензування при використанні у складних сценаріях [26]. У цьому контексті ми бачимо інший потенційний сценарій використання для нашого підходу, який ми описуємо нижче. Член команди повинен переглядати зміни коду коду колеги. Для цього він або вона може натиснути на посилання всередині запиту на вилучення, яке відкриває підготовлений редактор коду на основі хмари з вбудованим SV поведінки нової програми (через зміну коду джерела). Зміни коду коду коду кольорово кодуються в IDE. Щоб зрозуміти поведінку програми, можна перемикатися між старою і новою поведінкою програми в SV, натиснувши кнопку. Ко Сценарій 3 (SC3): Інтеграція інформації про час виконання в діяльність з розробки Ми бачимо редакторів коду, які інформують вибраних розробників про проблеми з продуктивністю встановленої програмної системи (наприклад, в зоні стадіону). Розробник може натиснути на це повідомлення, щоб відкрити вбудований SV. Візуалізація відображає поведінку завантаження, яка включає проблему з продуктивністю. Вона також виділяє суб'єкт, який вводить проблему, наприклад, методний виклик, який зайняв занадто довго, щоб закінчити. IV. Експериментальний дизайн та демографіка У цьому контексті, Merino et al. [27] представляють систематичний літературний огляд оцінки SV. Їх робота досліджує літературний корпус повних статей, які були опубліковані на конференціях SOFTVIS / VISSOFT, що призводить до вивчення 181 статей. Автори зосереджуються на оцінках, які підтверджують ефективність їхнього представленого підходу. Згадується, що багатооцінки випускають інші змінні, які можуть сприяти або загалом впливати на ефективність [28], такі як спогади та емоції. Ми поділяємо цю думку і стверджуємо, що ми повинні спочатку оцінити властивості, такі як сприйнята корисність, сприйнята корисність, або запити функцій, щоб потенційно переробити новий, дослідницький підхід • : Як суб'єкти використовують вбудований SV та редактор коду під час вирішення завдань? РК1 • Чи вважається редактор коду більш корисним, ніж вбудований SV? РК2 • : Чи визнають суб'єкти корисність функцій співпраці SV для конкретних завдань? РК3 • : Яке загальне сприйняття корисності та придатності підходу? РК4 • Чи сприймається підхід як корисний у передбачених сценаріях використання? РК5 Ми знову підкреслюємо, що висновки цього внеску слід розглядати як перші уявлення та показники для удосконалення, а не статистично обґрунтовані результати. • Подальше розуміння сприйнятої корисності програмних міст для розуміння поведінки Runtime. • Перші кількісні та якісні результати щодо сприйнятої корисності, сприйнятої придатності та часу використання для співпрацюючих, кодо-проксимальних програмних міст. • Додатковий пакет, що містить грубі результати оцінки, екранні записи всіх учасників, детальні інструкції, а також програмні пакети для відтворення [30]. Нижче ми представляємо демографію учасників та процедуру нашого експерименту. 
 
 
 
 Автори : Alexander Krause-Glau, Software Engineering Group, Кільський університет, Німеччина (akr@informatik.uni-kiel.de); (2) Wilhelm Hasselbring, Software Engineering Group, Кільський університет, Німеччина (wha@informatik.uni-kiel.de). Authors: Alexander Krause-Glau, Software Engineering Group, Кільський університет, Німеччина (akr@informatik.uni-kiel.de); (2) Wilhelm Hasselbring, Software Engineering Group, Кільський університет, Німеччина (wha@informatik.uni-kiel.de). 
 
 Цей документ доступний під ліцензією CC BY 4.0 DEED. Цей документ є Ліцензія CC BY 4.0 DEED. Доступно в архіві Доступно в архіві

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Pair Programming AI Agent 

undefined's blog

Це аудіо створено мовою оригіналу історії!

Чому інтерактивні візуали - це наступна велика річ у співпраці з програмним забезпеченням

About Author

КОМЕНТАРІ

ПОВІСИТИ БИРКИ

ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps