Для описания программного обеспечения используется много слов: фреймворк, прогрессивный, модульный, многоразовый, расширяемый, масштабируемый, простой, до бесконечности. Поработав и написав ряд веб- и мобильных проектов, мне было любопытно: какие слова составляют коллективный лексикон разработчиков и на что они были ответом?

Чтобы решить эту проблему, я написал некоторый код Python для очистки и анализа README из 2000 лучших репозиториев GitHub, получивших наибольшее количество звезд. Я ожидал, что будет много модных словечек, но обнаружил, что лучшие README написаны для своей аудитории, других разработчиков. Многие из наиболее часто используемых слов касаются установки, модификации и документации: как быстро и эффективно приступить к работе.

Задний план

TL;DR

  • Гипотеза: библиотеки стали большими, поэтому разработчики создали альтернативы
  • Файлы README – важный инструмент для обнаружения проекта.
  • Разработчикам нужны фреймворки, которые просты в использовании и ремиксах.

jQuery

Возможно, тенденции в разработке программного обеспечения с открытым исходным кодом развиваются как великая гегелевская диалектика, состоящая из тезиса, антитезиса и синтеза. По мере того, как используемые нами фреймворки становились больше и монолитнее, естественной реакцией некоторых было упрощение и создание меньших, более модульных фреймворков. Возьмем пример jQuery:

С течением времени jQuery росла и в то же время становилась менее необходимой (хотя благодаря технологии сжатия фактические байты, отправляемые по сети, росли гораздо медленнее). Ответ?

Некоторые разработчики считают, что jQuery защищает нас от великого демона несовместимости браузеров, хотя, по правде говоря, после IE8 с браузерами довольно легко справиться самостоятельно. Вам может не понадобиться jQuery.

jQuery был создан в 2006 году, и спустя 12 лет он все еще жив! Это, несомненно, основная библиотека javascript, и первые несколько лет она была не чем иным, как незаменимой. Но по мере принятия стандартов ECMA и усложнения веб-приложений это постепенно стало обузой.

Основные критические замечания заключались в том, что разработчики используют только небольшое подмножество функций, бесполезно тратя байты неиспользуемых функций, что абстрагированная совместимость больше не является проблемой для большинства проектов, и что предоставляемые им инструменты были ортогональны задачам, с которыми инженеры сталкиваются сегодня. Введите Реакт.

Реагировать

По мере усложнения веб-приложений возникла новая проблема. Из Самая глубокая причина, по которой существуют современные JavaScript-фреймворки:

Основная проблема, которую решают современные фреймворки JavaScript, — синхронизация пользовательского интерфейса с состоянием.

Спустя более десяти лет после запуска jQuery мы находимся в том же месте и решаем другую проблему. Будь то виртуальный DOM React и алгоритмы сравнения или двусторонняя привязка данных Vue.js, все фреймворки пытаются решить эту проблему синхронизации того, что вы видите, с данными.

Кажется, сегодня мы сталкиваемся с теми же проблемами. Фреймворки решают общие проблемы, что всегда влечет за собой компромисс между функциональностью и размером. Чем более общий фреймворк и чем больше функций он включает, тем больше он становится. Возьмем, к примеру, React:

Похоже на траекторию jQuery. Ответ?

Одним из главных преимуществ React было то, что он был намного меньше, чем Angular/Ember/Backbone и т. д., но я не уверен, что этот аргумент можно использовать дальше. – coltonv

Итак, мы здесь, пресловутые дебаты бушуют между размером и функциональностью. Только сегодня у нас есть еще одна проблема: парадокс выбора. С чего вообще начать при выборе JavaScript Framework?

Фрэнк Чимеро написал фантастическую статью Всё, что легко, снова сложно, в которой выразил разочарование ростом сложности при создании современных веб-сайтов и приложений. Его мнение разделяют многие.

просто npm ваш веб-пакет через grunt с vue babel или bower, чтобы отреагировать asdfjkl;lkdhgxdlciuhw

Это возвращает нас к словам.

Слова

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

Как и большинство людей, разработчики ищут что-то легкое, простое и автоматическое. Частью успеха любого проекта с открытым исходным кодом является возможность обнаружения. Наиболее функциональным проектам по-прежнему необходимо решать проблемы своих пользователей, и им по-прежнему нужны участники для их поддержки и улучшения. Слова, извлеченные из GitHub README, хорошо сочетаются с советами, такими как Руководство для начинающих по написанию Kickass README. Любому большому проекту необходимо:

  • Скриншоты. Большинство посетителей просматривают и уходят в течение нескольких секунд
  • Демонстрации и примеры. Покажите посетителям реальный проект
  • Документация. Расскажите посетителям, как легко установить и адаптировать

Такие слова, как автоматически, доступно, поддерживается, установлено и просто, рисуют картину. того, как лучшие проекты привлекают новых пользователей.

Дополнительные сведения о коде и процессе см. в разделе Слова с открытым исходным кодом — часть 1.

Код и данные доступны на GitHub: Tombarr/open-source-words