Как пара программирования в городах кодовых городов разблокировано скрытыми программными знаниями

Таблица ссылок

Аннотация и I. Введение

II Подход

А. Архитектурный дизайн

B. Доказательство реализации концепции

Iii. Представленные сценарии использования

IV Дизайн эксперимента и демография

А. Участники

B. Целевая система и задача

C. Процедура

V. Результаты и обсуждение

VI Связанная работа

VII. Выводы и будущая работа, признание и ссылки

V. Результаты и обсуждение

Наши средние вопросы и пост-квионатор содержали заявления, для которых участники должны были указать свой уровень (DIS) соглашения по 5-балльной шкале Лайкерта. Анкетные также включали бесплатные поля ответов, чтобы оставить комментарий по любым вопросам, связанным с экспериментом. Кроме того, преподаватель сделал примечание наблюдений, таких как рациональные использование конкретных особенностей, а также заметные эмоции [27] и упоминания участников. Далее мы представляем и используем результаты нашего проведенного пользователя, чтобы пересмотреть наши поставленные исследования. Кроме того, мы обсуждаем угрозы достоверности нашей оценки. Хотя мы используем термин SV в этой статье, мы не хотим, чтобы его понимали как обобщение наших результатов. Мы снова подчеркиваем, что результаты и их интерпретация ограничены нашим конкретным прототипом с использованием совместных городов кода и нашего эксперимента. Следовательно, результаты должны рассматриваться как первые идеи и показатели для уточнения, а не статистически обоснованные результаты.

Оценка задачи

Мы измерили общую правильность задачи 90 %. Связанное время, потраченное на решение задач, изображено на рисунке 5. Среднее время, потраченное на T1, является как для среднего, так и для средних 19 минут. Участник голода правильно решил T1 за семь минут. Этот человек уже был знаком с Explorviz. Для T2 мы видим 29 минут для среднего и 24 минуты для медианы. Обе задачи были без ограничения по времени, отсюда и группа выбросов для T2. На рисунке 5 также изображена сложность воспринимаемой задачи участников. Было обнаружено, что T1 и T2 были затруднены четырьмя участниками, при этом один человек также был очень трудным. Из -за общего распределения мы заключаем, что задачи не были ни слишком легкими, ни слишком сложными.

RQ1*: Как субъекты используют встроенный редактор SV и кода во время решения задач?*

Насколько нам известно, эта работа представляет новый подход, который объединяет редакторы кодов с методами дистанционного парного программирования и встроенными городами -кодами. Поэтому мы сначала намерены понять, как участники нашего исследования используют этот подход со свободным выбором инструмента, то есть встроенного SV и редактора кода, а также с задачами, на которые ссылаются SC1. В этом контексте на рисунке 6 показано время, проведенное, используя каждый инструмент для выполнения задачи. Для измерения, событие кода VS использовалось для захвата времени, в которое участники нажимали на редактор кода или расширение Explorviz, поэтому переключили свой сфокусированный контекст. Мы хотели бы упомянуть, что это было технически (из -за ограничений VS кода для расширений) только возможно, чтобы измерить время, проведенное между переключателями контекста. Таким образом, если участник не изменил контекст, но, например, использовал только SV, то наши измерения указывают время, потраченное на одну минуту для SV. Это относится к самым быстрым участнику T1, упомянутому выше, который активно взаимодействовал только с SV во время этой задачи (как подтверждено видеозапись). Среднее время, проведенное с использованием SV для T1, составляет семь минут и девять минут для кода VS (как среднее, так и медиана). Во время этой задачи участники впервые поняли исходный код и, вероятно, потратили больше времени на чтение его. Поэтому удивительно, что разница во времени для первой задачи уже довольно мала. Причина этого заключается в том, что города -кодовые города могут облегчить понимание структур и поэтому подходят для задачи получения обзора [34], [35]. Это также было явно упомянуто тремя участниками свободных текстовых полей. Для T2 среднее время, проведенное с использованием SV, составляет пятнадцать минут и восемь минут для VS -кода. (Почти) двойное количество времени, проведенного с использованием SV, является результатом двух выбросов. Однако для этой задачи медиана для времени, проведенного с использованием SV, составляет тринадцать минут и восемь минут для VS -кода. Мы предполагаем, что это происходит из общих городов программного обеспечения и возможности выделять рассматриваемые объекты. В примечаниях инструктора упоминается частое использование общих всплывающих окон в двух группах. Видеозаписи подтверждают, что эти группы часто используют всплывающие окна в качестве основы для обсуждения. Кроме того, участники часто используют функцию Ping нашего инструмента, чтобы выделить определенные детали для своего сотрудничества. Поэтому они провели больше времени

Используя SV. Однако сотрудничество - не единственная причина для этого. T2 явно требует понимания и расширения программного потока. SV предоставляет визуальный обзор структуры программной системы, а также в нашем случае снимка поведения времени выполнения (см. Раздел IV-B). В результате гораздо проще и очевидно использовать эту доступную визуализацию и, например, следы воображаемого метода вызовы с курсором мыши (особенно в сочетании с совместными функциями).

На рисунке 6 также представлено количество переключателей контекста для каждой задачи. Мы наблюдаем, что для T1 количество переключателей между SV и редактором кода гораздо больше распределено среди участников, чем для T2. Опять же, причина этого, по -видимому, заключается в сотрудничестве в T2. В большинстве случаев участники работают вместе и поэтому меняют свой инструмент, когда инициируется другим сотрудником. Как для T1, так и для T2, медиана контекстных переключателей составляет сорок, что указывает на то, что количество переключателей контекста не зависит от наших задач и сотрудничества.

Поскольку наш подход включает в себя поведение времени выполнения целевой системы, мы также намеревались узнать, как участники воспринимали полезность двух инструментов для понимания поставленного программного потока T1. В этом контексте рисунок 7 показывает, что SV воспринимался как более полезный, чем редактор кода. Один участник упомянул, что линии связи являются одним из наиболее полезных свойств SV. В Explorviz линии связи включают информацию во время выполнения, такую ​​как частота вызова метода в визуализированном снимке. Эта информация важна для понимания поведения времени выполнения. Кроме того, SV уже отображает информацию во время выполнения, которую пользователи в противном случае должны были бы найти и понять самостоятельно.

RQ2*: Воспринимается ли редактор кода более полезным, чем встроенный SV?*

Традиционно понимание поведения программной системы в первую очередь достигается путем понимания исходного кода [1]. Для этого эксперимента результаты, связанные с RQ1, показывают, что наш подход, например, использовался участниками для получения обзора целевой системы. Это обычный и подходящий вариант использования для SV, как показано в прошлом [34]. Тем не менее, профессиональные разработчики ставят под сомнение необходимость в SV [15], [36]. По нашему мнению, одной из причин этого является отсутствие свойств, таких как близость кода [5], [6] и настройка инструмента SV [4]. В этом контексте мы теперь рассмотрим, как участники оценивают полезность нашего подхода.

На рисунке 7 показаны результаты средних квиандеров, касающихся воспринимаемой полезности инструментов для задачи. Для T1 в целом 71 % согласны с поставленным заявлением «SV помог с задачей». Полезность редактора кода была немного (разница в одном человеке) более согласованной. Однако для SV число участников, которые не согласны, ни не согласны выше, и те, кто не согласен, ниже. Что касается T2, мы видим, что в целом 86 % согласны с поставленным заявлением «SV помог с задачей». Для сравнения, полезность редактора кода была немного (разница в одном человеке) меньше согласована.

RQ3*: Узнают ли субъекты полезность совместных функций SV для конкретных задач?*

С RQ3 мы расширяем результаты нашей предыдущей работы [16] в отношении воспринимаемой полезности городов совместного кодекса. В этом контексте мы попросили всех участников указать свой уровень соглашения с двумя позициями.

На рисунке 8 представлены связанные результаты. Мы видим, что 43 % участников согласны или полностью согласны с утверждением «Совместные функции SV, которые помогли с задачей» соответственно. Один человек, который не согласен с утверждением, упомянул, что совместные функции SV не помогли в его случае, поскольку у другого участника практически не было никаких вкладов. Тем не менее, он соглашается с тем, что общение станет большой помощью в парных программировании, поддерживаемой развитием в реальном мире. Предположительно, из -за низкого вклада своего сотрудничества, тот же человек также не согласен со вторым заявлением, которое касается голосовой связи. Из -за низкого вклада своего сотрудничества тот же человек также не согласен со вторым утверждением, которое относится к воспринимаемой полезности голосовой связи. Тем не менее, все оставшиеся тринадцать участников полностью согласны с тем, что голосовое общение было полезно в этой задаче. Это согласуется с нашими предыдущими выводами, указывающими на то, что голосовая связь является одним из наиболее полезных инструментов для совместной работы в SV [16].

RQ4*: Каково общее восприятие полезности и удобства использования подхода?*

Пост-критерий был разработан, чтобы запечатлеть общее представление участников о полезности и удобстве использования подхода. Отвечая на RQ1, мы видели, что участники действительно используют SV в качестве дополнения во время задачи понимания. Для RQ2 мы пришли к выводу, что участники воспринимали редактор кода и SV, как одинаково полезные в контексте реальной задачи. Наконец, на рисунке 9 показано:

Сотрудничество, очевидно, зависит от многих факторов, например, взаимного восприятия сотрудников или мотивации. В нашем контексте мы видели это для RQ3 или в ранее опубликованных результатах [16]. Участники оценивают совместные функции SV, немного отличающиеся, когда их оценить независимо от задачи. На рисунке 9 показан сдвиг в распределении рейтингов одобрения. Один человек, который ранее не согласен с полезностью совместных функций, теперь не согласен и не соглашается. Это соответствует его предыдущим упоминаниям. По сравнению с воспринимаемой полезностью для T2, общая воспринимаемая полезность совместных особенностей SV показывает менее сильное согласие. На самом деле, мы не смогли найти причину, по которой два участника понизили уровень своего согласия, чтобы «согласиться». Однако общий уровень одобрения остается прежним.

Хотя эта оценка в целом больше обеспокоена воспринимаемой полезностью встроенного SV, выявленные проблемы с юзабилити могут помочь выявить желательные усовершенствования. В этом контексте рисунок 9 также представляет воспринимаемую удобство использования участника нашего подхода. Результаты показывают, что 86 % участников находят использованную комбинацию встроенного SV и редактора кода. Есть некоторые желательные улучшения, которые упоминаются с помощью текстового ответа, например, лучшей производительности. Тем не менее, самой большой проблемой удобства использования была непреднамеренная минимизация встроенного SV. Причиной этого является то, что VS -код открывает файлы, которые были нажаты на проводник пакета в группе сфокусированной редакции в настоящее время. Такое поведение может быть отключено, блокируя группу редакторов. Тем не менее, в настоящее время написания механизм блокировки не может быть запускается из расширения кода VS. На рисунке 9 также показано, что еще 86 % будут использовать этот подход для частных целей, таких как понимание программы совместной работы с сокурсниками.

RQ5*: Подход воспринимается как полезный в предполагаемых сценариях использования?*

Наше пилотное исследование показало, что один эксперимент займет около часа. Чтобы не препятствовать потенциальным участникам из -за времени, которое нужно потратить, мы решили игнорировать другие сценарии использования и использовать только задачи в эксперименте на основе SC1. Тем не менее, пост-критерий также использовался для захвата предполагаемой полезности участников при применении подхода в оставшихся, предполагаемых сценариях. В этом случае они были описаны в тексте, и субъектам было предложено указать их соглашение по 5-балльной шкале Лайкерта. На рисунке 10 показаны связанные результаты. Полные описания сценариев доступны в дополнительном пакете этой статьи [30], но, по сути, суммируют предполагаемые сценарии использования в разделе III. Участники оценили SC1 с самым высоким общим соглашением и сильным соглашением, соответственно. Задачи эксперимента и их введение происходят из SC1. SC2 имеет наибольшее количество нейтралитета и разногласий. Один человек, который ответил ни без соглашения, ни разногласия, упомянул, что изменения кода обычно рассматриваются перед их развертыванием. Поскольку наш подход показывает только поведение времени выполнения, он не уверен, как будут визуализированы изменения для обзора кода. Эта деталь была фактически опущена в текстовом описании SC2. Мы считаем, что эта неопределенность является причиной самого высокого количества нейтралитета и разногласий для SC2. Тем не менее, большинство консенсус было положительным для всех сценариев.

А. Угрозы достоверности

Решение для программирования удаленной пары:Как упоминалось в разделе II-B, мы решили реализовать наш собственный подход к программированию удаленного пар, чтобы воспроизводимость нашей оценки не зависела от доступности внешних услуг. Тем не менее, этой пользовательской реализации не хватает полезных функций по сравнению с полноценными решениями для программирования удаленных пар. Например, один участник упомянул, что он не смог привлечь внимание сотрудники к конкретной кодовой части. Хотя наше исследование не было направлено на оценку того, лучше ли один инструмент, чем другой, эта пользовательская реализация могла повлиять на воспринимаемую полезность или удобство использования SV или редактора кода. Напротив, на рисунке 7 показано, что участники считают, что SV является более подходящим для понимания динамических потоков программы. С учетом вышесказанного мы заключаем, что в этом контексте требуется более эмпирическое исследование.

Продолжительность эксперимента:Среднее время, потраченное на изучение пользователя, составило около одного часа, как медиана, так и среднее. Отсюда следует, что на расстояние внимания участников и, следовательно, на результаты могли повлиять. Чтобы смягчить это, мы сказали участникам во время введения, что разрывы можно взять в любое время, и участие может быть прервано. Более того, T2 был решен совместно и, следовательно, предположительно освободил экспериментальную ситуацию.

Целевая система:Подготовленная целевая система содержит 26 файлов Java, связанных с логикой приложений, которые распространяются среди четырех подпроектов Maven. В результате небольшой размер проекта мог повлиять на воспринимаемое удобство использования SV, что также упомянуто одним участником. Мы согласны, но также подчеркиваем, что мы не намеревались оценивать удобство использования на основе масштабируемости визуализации, а на общей концепции. В целом, эта оценка больше обеспокоена воспринимаемой полезностью SV, включающей распределенную трассировку для процесса адаптации. Кроме того, мы утверждаем, что реальное применение сценария адаптации с SV должно направлять новых разработчиков через поведение программной системы со все более крупными частями базы кода.

Участники: Использование студентов в экспериментах является достоверным упрощением, которое часто говорят, что может поставить под угрозу внешнюю достоверность [31]. В нашем случае опыт участников мог повлиять на их восприятие относительно полезности SV, а также их времени, потраченного на использование SV. В этом контексте профессиональные разработчики могут извлечь выгоду из своего опыта, например, с пружинной структурой и может быстрее понимать исходный код. В результате мы повторим эксперимент с профессиональными разработчиками.