Проект интеллектуального анализа данных GitHub
Введение
Здравствуйте, дорогие читатели, меня зовут Даниэль Шмидер, и в настоящее время я получаю степень магистра в HSR Hochschule für Technik Rapperswil, Швейцария. В рамках этого я решил провести исследовательский проект, касающийся использования объектно-ориентированного программирования (ООП) в Javascript. Ранее мое внимание привлекла эта публикация в блоге, в которой утверждалось, что ООП перепродан и причиняет большой вред. Некоторые другие исследовательские работы дошли до того, что объявили ООП мертвым, известные университеты исключают ООП из вводных занятий, а эксперты предупреждали о вреде ООП или описывали его как анти-паттерн. Такие предупреждения были опубликованы в Usenet, академических газетах и уважаемых изданиях, таких как журнал доктора Добба. Есть также это ныне известное утверждение, в котором резюмируется опасность ООП;
«Проблема с объектно-ориентированными языками заключается в том, что у них есть вся эта неявная среда, которую они носят с собой. Вы хотели банан, но получили гориллу, держащую банан и все джунгли». цитата Джо Армстронга о повторном использовании программного обеспечения в книге «Кодеры за работой: размышления о ремесле программирования»
Хотя мой опыт работы с JavaScript не был таким глубоким, как с другими языками программирования, я считал подобные заявления и разработки опасными и не отражал мой личный опыт. В конце концов, крайне сложно прийти к такому выводу непредвзято или сделать это утверждение верным для всего огромного сообщества, такого как JavaScript. Весной 2017 года я решил создать несколько инструментов, которые позволили бы мне провести надлежащее исследование этого вопроса.
Гипотезы
В начале этого проекта я размышлял о своем мировоззрении, которое противоречило приведенным выше утверждениям. Помимо основной гипотезы о том, что ООП в JavaScript опасен, не должен использоваться и, следовательно, не актуален, я записал несколько дополнительных гипотез, отражающих, при каких обстоятельствах я использую (или стараюсь избегать) ООП. Причинами этого были в основном размер команды разработчиков или сложность проекта.
При работе с небольшой командой (или в одиночку) обычно ничто не мешало мне использовать стратегии ООП, на самом деле я поощрял это и почти всегда делал это — если это было необходимо. Очевидно, что если проект не требует этого, нет необходимости впихивать это туда только потому, что вы можете. По мере того, как команды становятся больше, скажем, от трех до десяти человек, вероятность того, что все участники решат использовать этот шаблон, обычно снижается. Такие команды среднего размера также допускают участие людей с разным бэкграундом, и если проекты этого абсолютно не требуют, часто не требуется реализовывать ООП и знакомить всех с «джунглями» и «своими гориллами». Поэтому, исходя из моего опыта, моя гипотеза такова;
ООП более распространен в малых проектах, чем в средних проектах.
В больших командах (обычно десять и более человек работают над сложными проектами) использование ООП должно стать необходимостью. По мере того, как масштаб проекта увеличивается, а команды, как правило, делятся на более мелкие группы, ООП часто появляется как решение для преодоления многих проблем архитектуры программного обеспечения, и его часто предпочитают его альтернативам. Кажется логичным, что
ООП более распространен в крупных проектах, чем в средних проектах.
Наконец, последняя гипотеза пытается сделать заявление о сравнении больших и малых проектов. Хотя все они отражают мое личное мнение и мировоззрение, последнее, безусловно, больше всего. У меня также нет четкого объяснения, почему я ожидаю, что она будет вести себя именно так, но я думаю, что диверсификация более крупных команд на более мелкие группы затмевается способностью команды, которая и без того мала для начала, реализовывать ООП-стратегии. Следовательно;
ООП чаще используется в малых проектах, чем в крупных проектах.
В дополнение к этим трем гипотезам меня интересует, насколько популярно использование ООП в последних проектах по сравнению со старыми проектами, которые либо завершены, либо прекращены. Были заявления о том, что ООП в целом переоценивают и втискивают в проекты, которые в нем не нуждаются, и взгляд назад на то, как эта тенденция развивалась за последние годы, может пролить некоторый свет на то, является ли (чрезмерно) использование ООП может нанести вред проектам или сообществу в целом.
Мой подход
Чтобы получить достаточно большую выборку, чтобы подтвердить или опровергнуть любую из вышеперечисленных гипотез, я решил использовать GitHub (как следует из названия) в качестве источника для проектов JavaScript. Независимо от того, используете ли вы GitHub в качестве платформы для распространения, используете его совместно или просто для «размещения своего кода», GitHub, безусловно, является основным ресурсом, когда речь идет о больших объемах кода. GitHub API служит хорошо документированным инструментом для управления вашими проектами и учетной записью и обладает всеми функциями, которые пользователь имеет в браузере с помощью графического интерфейса. Кроме того, это также отличная возможность для интеллектуального анализа кода. API поиска GitHub, в частности, является отличным ресурсом для поиска репозиториев, соответствующих предопределенным критериям, например написания на определенном языке или создания в течение определенного периода времени. Благодаря огромному сообществу, использующему GitHub, такие запросы обычно приводят к тысячам результатов — в неделю!
К сожалению, количество соавторов данного репозитория не является частью стандартных аргументов поиска, таких как размер или наблюдатели (также известные как «звезды»), поэтому после извлечения репозиториев-кандидатов, соответствующих запросу, необходимо было выполнить программную фильтрацию.
Стратегия выборки работала следующим образом; На каждый месяц (начиная с января 2015 г.) найдите десять репозиториев для небольшого проекта (0–2 соавтора), десять для среднего (3–9) и пять для крупного проекта (10+). Этот поиск начинается в первый день месяца и сортируется по времени последнего обновления рассматриваемого проекта. Если вы найдете репозиторий, соответствующий первому месяцу 2015 года, это означает, что с тех пор этот репо не менялся. Здравый смысл подсказывает мне, что проекты, которые больше не обновляются, либо «идеальны» (потому что их разработчики не чувствуют необходимости что-то улучшать, добавлять или исправлять) — либо мертвы из-за отсутствия финансирования, пользовательской базы или интереса к команда разработчиков.
Поскольку репозитории фильтруются в соответствии с временем их последнего обновления, результирующие данные подобны снимку прошлого, просматриваемому с определенного момента времени. Чтобы найти подходящие репозитории для каждого из 31 месяца, было проанализировано в общей сложности около 30 000 репозиториев.
Поскольку подавляющее большинство репозиториев, размещенных на GitHub, соответствуют категории малых и средних размеров, из тысяч результатов каждый месяц важно контролировать баланс между этими категориями. Это было достигнуто с помощью процесса «группирования», который классифицирует репозитории-кандидаты по категориям, прежде чем они будут загружены и проанализированы. Таким образом, баланс между группами контролировался, потому что репозитории, которые помещаются в уже заполненную корзину, можно пропустить. По окончании агрегации три «корзины» одинаково заполнены, и поиск можно переходить к следующему месяцу. Следуя этому подходу, размер выборки для моего эксперимента вырос почти до 800 репозиториев, собранных за последние 2,5 года по состоянию на июль 2017 года.
Чтобы ответить на вопрос, сколько из этих выбранных репозиториев используют ООП, нам пригодился инструмент под названием ESLint. ESLint — подключаемая утилита линтинга для JavaScript. Обычно она используется для проверки соответствия кода определенным руководствам по стилю и выдачи предупреждений и ошибок с помощью статического анализа. ESLint можно расширить с помощью пользовательских плагинов, и это позволяет нам использовать ESLint для поиска любого шаблона в коде, а затем сообщать, сколько из них было найдено. Для своего анализа я решил использовать создание новых объектов в качестве индикатора ООП в проекте. В JavaScript объекты могут быть созданы с помощью метода «new Banana()» или метода Object.create, оба из которых являются шаблонами кода, которые мы можем поручить ESLint искать. Затем ESLint проходит по абстрактному синтаксическому дереву и сообщает, обнаружен ли такой шаблон.
Небольшое примечание: в процессе обнаружения этих блоков кода некоторые встроенные объекты JavaScript, такие как new Date(), String(), Array() или подобные, исключаются и не учитываются как шаблон, который идентифицируется как процесс создания объекта.
Объединив эти два фактора, можно автоматизировать агрегацию и анализ репозиториев образцов. После того, как «ведра» процесса выборки заполнены, сохраненные репозитории загружаются. Затем ESLint работает со списком папок и отдельно анализирует каждый файл в соответствии с правилами линтинга. Наконец, полученный отчет сохраняется в локальной базе данных SQL для дальнейшего изучения.
Результаты
Прежде всего, давайте рассмотрим общие результаты, суммированные по всем месяцам. Я получал репозитории в течение 31 месяца, 25 репозиториев в месяц, считая до 775. 406 репозиториев из тех, которые использовали ООП, что составляет примерно 52,4%. Важно отметить, что порог для использования ООП намеренно установлен на «один». Ноль, что означает, что отчеты от ESLint показывают, что проекты не создают никаких объектов, но один или несколько классифицируют проект как объектно-ориентированный.
Чтобы проверить гипотезы, я использовал критерий хи-квадрат N-1 для оценки результатов. Тест N-1 Chi-Square — это бинарный тест «пройдено/не пройдено», в котором любые признаки ООП в репозиториях интерпретируются как 1 и 0, если знаков не было соответственно. Значение p этого теста дает информацию о том, насколько статистически значимы эти результаты. Значение ниже 0,05 обычно означает, что они значимы.
Гипотеза 1
ООП более распространен в малых проектах, чем в средних проектах
Неверно!
К моему удивлению, только 44% всех репозиториев малого размера показали признаки ООП (маленький, что означает размер команды или количество соавторов). Однако в репо среднего размера эта доля составляла 55%. Значение p для этих результатов составляет 0,0049673, что означает, что результаты значимы.
Это было довольно шокирующим. В выборке нет ни одного года, когда ООП был популярнее в группе Small, чем в среднем за все время. Фактически, ООП неизменно менее популярен в малых проектах, чем в средних проектах. Возможное объяснение этого результата состоит в том, что эти результаты показывают, что люди используют свой опыт в ООП даже при работе в больших командах и не чувствуют себя запуганными (или обязанными) знакомить своих коллег с джунглями. Возможно, существует заданная вероятность того, что JS-программисту понравится объектно-ориентированный подход. Если да, то человек будет использовать это, независимо от того, что предпочитают или понимают его сотрудники. Таким образом, более крупные команды означают, что становится более вероятным, что энтузиаст объектно-ориентированного программирования внесет свой вклад. Масштаб и сложность таких проектов могут требовать или не требовать использования ООП, но готовность их реализовать свои таланты, похоже, остается неизменной.
Гипотеза 2
ООП более распространен в крупных проектах, чем в средних проектах
Верно!
64% всех крупных проектов в выборке использовали ООП, что даже выше, чем 55%, которые были показаны в группе среднего размера. Значение p для этих результатов составляет 0,0365432, что по-прежнему является статистически значимым.
Как и ожидалось, когда большие группы совместно работают над большими и сложными проектами, ООП имеет очень высокие шансы найти свое место в кодовой базе. Неясно, требует ли этого сложность по своей сути, или шанс поймать энтузиаста ООП тем выше, чем больше команда. Возможно, как и грипп, гораздо больше шансов «подхватить» его в городе или классе, чем при проживании в сельской местности.
На данный момент последняя гипотеза излишня — было бы интересно сравнить Малые и Большие группы, если бы Малые группы уже не были затмеваются Средней группой, а Средняя группа затем не уступала Большой группе, как и предсказывалось. Однако, поскольку у меня есть номера, я рад дать их вам:
Гипотеза 3
ООП более распространен в небольших проектах, чем в крупных проектах
Неверно!
В то время как 64% всех крупных проектов используют ООП, вероятность найти ООП в репозитории малого размера составляет всего 44%. Этот тест имеет самую высокую значимость из трех, с p-значением всего 2,44E-5 — практически нулевым. Это означает, что если вы сравните репозиторий со многими соавторами с репозиторием с очень небольшим количеством соавторов, у вас будет 99,998% вероятности того, что у репо со многими соавторами больше шансов использовать ООП.
Это также не то, чего я ожидал — снова кажется, что масштаб и сложность проекта просто важнее, чем позволить личным предпочтениям определять архитектуру программного обеспечения.
Ниже; вы видите графическую разбивку образца, который я собрал
Анализ тенденций показывает, что в 2015 году была наибольшая доля использования ООП в проанализированных проектах; Его используют 59% всех проектов. В 2016 г. этот процент был ниже – 47%, что является статистически значимым падением (p‹0,002). 2017 год, который следует рассматривать как год, в котором находятся еще живые проекты, показывает число около 49%, что все еще ниже, чем в 2015 году (p‹0,02). Есть много способов интерпретировать эти цифры, но похоже, что проекты, которые не обновлялись в течение длительного периода времени, более вероятно используют ООП. Это указывает на то, что проекты, использующие ООП, с большей вероятностью будут прекращены — вот почему существует большее «кладбище» проектов, которые больше не находятся в разработке, и их команды решили двигаться дальше (возможно, к проекту без ООП). Другая интерпретация заключается в том, что многие молодые проекты еще недостаточно зрелы, чтобы достичь сложности, требующей использования ООП.
Ниже вы видите другую визуализацию результатов, которая показывает тенденцию к снижению проектов, использующих ООП.
Ограничения и будущие исследования
Безусловно, это исследование помогло мне уточнить мое представление об актуальности, токсичности или роли ООП в сообществе JS. Исследование направлено на то, чтобы пролить непредвзятый свет на состояние JS-проектов на GitHub за последние пару лет. Для этого используются инструменты с открытым исходным кодом и общедоступные ресурсы, такие как GitHub. Очевидно, что существует большое количество проектов JavaScript, которые никогда не публикуются на GitHub, и я не ставлю себе целью делать заявление обо всех проектах, использующих JS.
В нынешнем виде этот пример показывает нам моментальный снимок прошлого, ведущий к будущему, а репозитории, расположенные дальше, сообщают нам, что они не обновлялись дольше, чем репозитории, которые ближе к настоящему. Вполне возможно, что для некоторых использование (или отсутствие) ООП само по себе может быть причиной прекращения проекта. Трудно сказать, насколько это распределение наклонено в ту или иную сторону, но его можно исследовать, используя время жизни каждого проекта, и показать, как внедрение и использование ООП повлияло на него.
Стратегия выборки может оказать существенное влияние на результаты. Например, день недели не учитывался при установке начального дня для каждого месяца. Как правило, чтобы найти достаточно проектов за определенный месяц, анализировались проекты за 2–3 дня, из которых выбирались репозитории. Мало того, что этот выбор смещен в сторону начала месяца, но в зависимости от даты этот процесс выборки может начаться в пятницу и продолжаться в выходные или в любой другой (рабочий) день недели. Повторное взятие образца и начало каждого месяца в один и тот же день недели может показать интересный сдвиг результатов в сторону ООП или в сторону ООП, потому что это может еще больше разделить проекты JS на разные группы, которые могут предпочесть работать и обновлять свои проекты по выходным ( такие как любительские или внештатные проекты, которые не связаны ежедневным или еженедельным графиком). Также можно выбирать репозитории равномерно в течение каждого месяца, чтобы полностью избежать этого эффекта.
Размер выборки, хотя и дает статистически значимые результаты, конечно, может быть расширен, чтобы охватить несколько лет назад или собрать больше репозиториев каждого типа в месяц. Поскольку оценка, интерпретация и визуализация результатов по-прежнему отделены от автоматизированного процесса сбора выборки, размер остается относительно скромным по сравнению с возможным количеством общих репозиториев, размещенных на GitHub за этот период времени, поскольку он состоит из значительной ручной работы.
Можно было бы принять во внимание размер проекта (в строках кода; LOC) и дать подробные сведения о распределении и актуальности ООП в свете этой метрики или скорректировать порог, если проект следует рассматривать как «использующий ООП». ».
Конечно, минимальное количество LOC сможет отсортировать большое количество пустых или неинтересных репозиториев, размещенных на GitHub, и помочь процессу выборки выбрать репозитории только из желаемой целевой группы. Затем образец может быть визуализирован в отношении этой метрики для дальнейшей поддержки различных гипотез или утверждений о том, почему ООП используется таким образом. Аналогичные показатели, такие как сцепление, сплоченность или цикломатическая сложность, могут быть проанализированы таким же образом во время или после процесса выборки, чтобы создать более точную выборку.
Выводы
Исходя из этих выводов, я возвращаюсь к своему первоначальному утверждению. Является ли ООП мрачной косой для JS-проектов? Я не думаю, что для подтверждения этого утверждения пока достаточно данных, но, безусловно, собранные данные не опровергают его, а наоборот. Объяснение того, что ООП убивает JS-проекты, правдоподобно и согласуется с данными о «нетронутых» (или мертвых) проектах, потому что количество проектов, использующих ООП, значительно сокращается по мере приближения к настоящему. Если наблюдаемая тенденция сохранится, всего через несколько лет количество живых проектов, использующих ООП, может быть вдвое меньше, чем в 2015 году, а это означает, что большая часть существующих сегодня JS-проектов, использующих ООП, умрет. Ниже вы можете увидеть визуализацию этой тенденции вместе с классификацией проекта по трем этапам. Первая фаза, «В разработке», охватывает последние 6 месяцев, «приостановлено/используется» в следующем году и «прекращено», если проект оставался неизменным более 1,5 лет. Несмотря на заметный сдвиг, который переводит проекты из второй фазы в первую (и сохраняет их «живыми»), общее падение JS-проектов, находящихся в разработке, значительно по сравнению с теми, которые были прекращены.
Другая правдоподобная интерпретация, вывод и объяснение наших данных заключается в том, что ООП может быть введено в проекты JavaScript через отдельных «энтузиастов ООП», которые не обязательно гарантируют, что команда в целом считает это шагом в правильном направлении или если эта стратегия даже необходимо для размера или типа проекта. Возможно, в прошлом ООП слишком разрекламировали, и многие разработчики слепо следовали этой тенденции. Это может означать, что не сам ООП убивает JS-проекты, а ООП, сделанный неправильно.
Это исследование придает правдоподобие этим двум интересным наблюдениям, но, как упоминалось в разделе выше об ограничениях этого исследования, многое еще предстоит сделать. быть сделано, прежде чем мы могли бы утверждать, что у нас есть близко к доказательству для этого.
Эти результаты особенно важны для меня, потому что они бросают вызов моему мировоззрению. Мне полезно знать, что я не должен основывать свое мнение на личном опыте или близких коллегах, а должен выйти из наших пузырей и основывать их (насколько это возможно) на рецензируемых общественных ресурсах.
Ссылки
Джо Армстронг об ООП
http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
Результаты анализа (с января 2015 г. по июль 2017 г.) в формате .csv
https://mega.nz/#!sVJQEITb!XVWtiAqpd2A4baXGFUecooVc79Ba1TO8Xq2ajXTkiqg
