Комментарии 28
Чем больше у проекта пользователей, тем больше они будут создавать issues, поэтому сравнивать очень распространённый TypeScript с нишевым Haxe таким образом — абсолютно бесполезно. Можно улучшить эту метрику, если нормировать сумму возрастов всех открытых проблем по количеству звёздочек у проекта (звёздочки — грубая оценка популярности).
Но даже такой вариант очень далёк от идеала. Очень многие проекты используют ботов, которые закрывают неактивные issues, поэтому если открытых issues мало, то это совершенно не значит, что мейнтейнеры быстро решают проблемы.
Насколько я слышал автор знаменит своими набрасываниями на вентилятор в несчастных потугах продвинуть самописный инструмент ¯\_(ツ)_/¯
Проблемность проекта от числа пользователей слабо зависит. Зависимость может быть разве что от истеричности. Одни сами разбираются с проблемами и не беспокоят мейнтейнеров, другие строчат гневные комментарии из-за каждой мелочи. Но это опять же влияет не на самому асимптоту, а лишь на динамику приближения к ней.
У меня есть пет проект, там вообще нет issues,) выглядит так, как будто я лучше Google)
Проблемность от числа пользователей слабо зависит, но ты же не проблемность оцениваешь (даже грубо), ты оцениваешь число заведенных issue и их суммарный возраст. Доказательства, что этот параметр коррелирует с "проблемностью" у тебя в статье нет, и оно вовсе не очевидно.
Либо ты подразумеваешь под "проблемностью" что-то своё, что прямо соотносится с числом проблем в трекере. Ок, но в таком случае полезность понятия "проблемность" в твоей интерпретации точно так же стремится к нулю.
Каждая проблема вызывает боль своим существованием. Интегрируем по времени существования проблемы — получаем общий размер вызванной ею боли на текущий момент. Вероятность вызова боли конкретной проблемой единична лишь в худшем случае. Поэтому проблемность — оценка объёма боли сверху.
а вот для сравнения между собой angular/react/vue — весьма интересно наблюдение, не более
А вот у RXJS с поддержкой всё не ладно. Очевидно, дело в куда более сложных абстракциях, которые протекают во всех возможных местах и очень плохо укладываются в головах разработчиков. Существование сайтов типа RxMarbles это только подтверждает.
Что именно может подтвердить существование документации?
Это не документация, а интерактивная визуализация. Не от хорошей жизни она потребовалась тут. И не от плохой она не потребовалась для остальных.
Приведите пример достаточно сложного продукта, который не требует визуализации в том или ином виде в документации
Ну или пример суперпростой альтернативы продукту, аналогичному rxjs по функционалу/задачам
Рядом на скриншоте несколько достойных альтернатив.
Откройте тот же RxMarbles, и скажите, что из этого кроме Behavior Observable можно сделать на redux?
Пользователи всеми этими инструментами решают одни и те же задачи. И это отнюдь не задачи типа "как сджойнить потоки событий так, чтобы они не приводили ко гличам".
Пользователи всеми этими инструментами решают одни и те же задачи.Вообще-то нет. «Как сджойнить потоки событий» — это и есть изначальное предназначение rxjs. То, что одна из задач, решаемых с его помощью, пересекается с redux, не делает их аналогами.
Это примерно как сравнивать 5-осевой фрейзер и сверлильный станок на основании того, что «пользователи с их помощью решают одни и те же задачи».
То есть технология в которой 1 проблемный ишьюс не закрытый в течение 15 лет будет хуже чем та у которой 25 ишьюсов висящих полгода. Казалось бы. стоило бы хотя бы поделить возраст ишьюсов на их количество чтобы хотя бы среднее (а лучше медиану) оценивать.
А так что сказать
Какая же ерунда. Вы среднее то хоть пробовали считать в ваших "метриках"? Или какие-то другие статистики: медиану, квантили? Или отбрасывание выбросов делали? И даже так всё равно получится ерунда, потому что эти числа не выражают тот смысл, который вы в них вкладываете. Issues могут быть открытыми долгое время по разным причинам, это не обязательно должно означать, что проект плохо поддерживается и развивается. Тем более неразумно сравнивать "слона" с "муравьём" таким образом. Разные масштабы и отсутствует какая-либо нормировка. Это "исследование" вообще не выражает ровным счётом ничего разумного. Просто "я получил какие-то числа, давайте считать их мерой качества/проблемности проекта".
Issues маркированных как баги в typescript всего 1600 открытых на данный момент, например.
Спасибо за статью.
Не могли бы Вы дать определение термину проблемоёмкость?
Я, например, смотрю только на количество мейнтейнеров и обновляемость проекта.
Грубая оценка проблемности GitHub-проектов