Эта статья является четвертым выпуском нашей серии блогов MSR Interview. После Abram Hindle, Georgios Gousios и Vasiliki Efstathiou на этой неделе будет интервью с Сарой Нади, доцентом University of Alberta. Спасибо Варену Лонгу, Вадиму Марковцеву и Франсеску Кампою за проведение интервью.

Ниже вы можете найти некоторые публикации Сары о репозиториях майнинга:

Не могли бы вы представиться?

Я Сара Нади, в настоящее время я доцент в Университете Альберты. Я защитил докторскую диссертацию. и магистра в Университете Ватерлоо, а затем получил постдокторскую степень в Техническом университете Дармштадта в Германии. Обычно я работаю над поиском или разработкой методов поддержки разработчиков в их сопровождении и повторном использовании программного обеспечения. Например, я работал над тем, чтобы помочь разработчикам правильно использовать API, то есть сообщить им, если они сделали что-то не так, или помочь им выбрать библиотеку для конкретной задачи. Я также работал над областью под названием «Линейки программных продуктов» (SPL), где у вас есть несколько версий вашей системы, и вы хотите управлять ими, объединять их, находить несоответствия в конфигурациях и т. д.

Вы решали эту проблему автоматически? Например, когда вы сообщаете разработчикам, какую версию им следует использовать?

Для API мы создали инструмент обнаружения неправильного использования API. В основном мы копаем много кода, создаем шаблон кода из этого кода, а затем обнаруживаем нарушения шаблона. Это автоматизированный инструмент. Мы также сделали другие вещи по поддержке принятия решений для выбора библиотеки. Прямо сейчас мы извлекаем метрики из репозиториев и информацию о библиотеках, а затем представляем их вам, чтобы вы могли принять решение. Вот сайт, который у нас есть для поддержки выбора библиотеки http://smr.cs.ualberta.ca/comparelibraries/ (но он нуждается в некотором обновлении). Так что я делаю и то, и другое: автоматизированные инструменты и еще немного поддержки принятия решений.

Сколько раз вы уже были в MSR?

Я посещал MSR 5 раз, начиная с 2013 года в Сан-Франциско. В этом году я сопредседательствую как на треках данных, так и на майнинге. У меня также есть один из моих магистров, Мехран Махмуди, который представляет доклад в этом году.

Не могли бы вы рассказать нам немного больше о Mining Challenge?

Каждый год, когда проводится Mining Challenge, есть несколько тщательно отобранных наборов данных, которые должны быть общими в том смысле, что есть много разных исследовательских вопросов, которые вы можете задать по этому поводу. Их выпускают, и людей приглашают провести некоторые исследования вдобавок к этому. В этом году наш набор данных в основном является результатом докторской диссертации Себастьяна Прокша, которым я руководил в Техническом университете Дармштадта, а сейчас он является постдоком в Цюрихском университете. Свен Аманн, которым я также руководил в качестве доктора философии. студент в Дармштадте, также внес большой вклад в создание инструментария для курирования этого набора данных. Набор данных в основном касается взаимодействия разработчика с IDE, особенно в Visual Studio.

Какие самые большие проблемы люди пытаются решить, используя эти данные, и что вам наиболее интересно?

Одна из самых больших проблем при оказании помощи разработчикам заключается в том, что вам необходимо учитывать контекст того, над чем они работают, чтобы избежать ложных срабатываний. Если вы начнете говорить разработчикам, что они делают что-то не так, и окажется, что все это ложные срабатывания, они очень быстро разочаруются. Трудно правильно использовать подходы, основанные на данных, особенно когда многие общедоступные данные, которые мы извлекаем, могут быть изначально неверными. Вам также необходимо учитывать контекст, например, над каким приложением работает разработчик, и имеет ли смысл предупреждение, которое вы собираетесь им дать, в этом контексте или нет. Это трудно сделать.

Есть ли у вас на примете какой-нибудь документ, посвященный этой проблеме, с целью свести к минимуму количество ложных срабатываний среди прогнозов?

Теперь не в моей голове. Была проведена работа, которая смотрит на то, что вы делаете внутри IDE, и создает для вас профили Гейла Мерфи (использование контекста задачи для повышения производительности программиста). Я считаю, что вариант этого может быть одним из вариантов уменьшения ложных срабатываний на основе профилей разработчиков.

Вы читали документ под названием Уроки создания инструментов статического анализа в Google?

Есть много статей, в которых качественно исследуется использование инструментов статического анализа (например, работа Джонсона ICSE ’13), и в них сообщается, что ложные срабатывания являются большой проблемой. Что конкретно вы можете с этим сделать? Были разные подходы, которые либо добавляли контекст, либо повышали точность, чтобы сделать инструменты лучше, но это очень сложно: то, что верно для одного инструмента, не обязательно верно для другого инструмента.

Как, по вашему мнению, данные могут помочь разработчикам писать более качественный код?

Я думаю, что можно многое выиграть, просматривая данные, находя тенденции, о которых мы можем рассказать разработчикам. Например, если я знаю, что этот способ кодирования или этот процесс вызывают больше дефектов, я могу вас предупредить. Я могу сказать вам, что это запах кода, и помочь вам улучшить его, и это то, что вы можете получить из данных. Что мы сделали с обнаружением неправильного использования, так это то, что мы нашли шаблоны, просматривая данные. Очевидно, здесь тоже есть риск, потому что с подходами, основанными на данных, действует правило большинства, которое часто оказывается неверным. Например, в API-интерфейсах безопасности мы поняли, что большинство ошибались, а это означает, что использование подходов, основанных на данных, для обеспечения безопасности становится намного сложнее. Итак, есть компромиссы; вы можете учиться чему-то, но вы также можете изучать вещи, которые неверны. Если то, что вы изучаете, новое, и все делают это неправильно, то вы также изучаете что-то неправильное, и это одна из вещей, с которой мы на самом деле боремся. Одним из вариантов может быть триангуляция многих источников. Например, если вы выполняете анализ шаблонов для кода, возможно, сопоставьте его с тем, что люди говорят в Stack Overflow или технических блогах, и посмотрите, совпадает ли он или нет. Выполняя триангуляцию из многих источников, вы уменьшаете ошибку большинства, делающую это правильно или неправильно. Очевидно, что это все еще не точно, но, по крайней мере, вы уменьшаете потенциальные ошибки.

Что вы думаете о концепции машинного обучения поверх исходного кода?

Идея применения машинного обучения к исходному коду набирает обороты и имеет большой потенциал. Однако существует также много рисков в том смысле, что код имеет много контекста и семантики, и, просто создавая код вслепую как текст, мы можем потерять большую часть этой семантики. Теперь это зависит от того, какое приложение. Для чего-то вроде предсказания следующего токена (например, работа Абрама Хиндла) это работает, но если я собираюсь выучить точный фрагмент кода, чтобы порекомендовать вам, учитывая код, который вы уже написали, или помочь вам исправить части кода, то необходимо учитывать больше семантики, поскольку существуют также альтернативные шаблоны кодирования.

Есть ли у вас какое-либо простое применение машинного обучения в коде?

Я бы сказал, что большинство незамысловатых идей уже реализовано. Связывание событий, шаблоны коммитов, такие вещи, как шаблоны эволюции: анализ таких тенденций и последовательностей уже сделан. Как обычно с ML, это зависит от того, какие функции вы извлекаете; они должны иметь смысл для контекста кода, который вы изучаете. В настоящее время у нас также есть дополнительные данные, такие как разговоры в запросах на вытягивание, которые затем можно связать с кодом в коммитах. Все это ценная информация. Мы снова возвращаемся к этой идее триангуляции различных типов информации и ее рассмотрения.

Какую самую интересную идею вы уже видели в MSR?

Учитывая, что я участвовал в отслеживании данных, одна вещь, которая привлекла мое внимание в этом году на MSR, — это набор данных об уязвимостях безопасности Vulinoss: набор данных об уязвимостях безопасности в системах с открытым исходным кодом. Я думаю, что безопасность очень важна и привлекает к себе все больше внимания, поэтому в этом контексте этот набор данных выглядит многообещающе.

Узнайте больше о MSR 2019 и MLonCode: