Здравствуйте, меня зовут Дмитрий Карловский и я… практикую терморектальную ароматерапию. Понимаю, что каждый любит своё болото, и будет защищать его до последней капли жижи. Тем не менее, высокая инженерная культура требует объективности в оценке инструментов.

Часто для решения одной и той же задачи существует более чем один подходящий по функциональности вариант. При прочих равных, хотелось бы выбрать такой проект, который доставит меньше всего проблем. Но как навскидку оценить объём этих проблем, не тратя несколько человеколет для собственноручного набивания всевозможных шишек?

Что ж, давайте разберём, какие бывают проблемы, как их оценить и посравниваем некоторые популярные проекты.

Проблемы

Ошибки в коде

Никому не нужен инструмент, который глючит или попросту не работает. На них обычно заводятся issue c тегом "bug".

Грабли в архитектуре

Архитектура может быть не заточена под нужный вам способ использования. Более того, порой архитектура никуда не годиться, даже в казалось бы основных сценариях использования. Issue в таком случае если и заводятся, то пространные в духе "как сделать то-то?" или "почему работает не так, как я ожидаю?".

Документация

Если документация не полна, не актуальна или её вовсе нет, то освоение инструмента будет сопряжено с трудностями. На неё обычно заводятся issue с тегом "documentation".

Несовершенство

Если какая-либо фича реализована не очень удобно или вообще не реализована, то приходится писать свои фасады, декораторы, адаптеры и прочие прокси, чтобы приспособить инструмент к реалиям своего проекта. На них обычно заводятся issue с тегом "improvement".

Поддержка

Нет ничего идеального. Ни проект, ни его автор, ни его пользователь. А значит неизбежно появление проблем. И борьба с этими проблемами может быть отдельной проблемой. Например, вашу проблему могут не заметить, или забыть, или не понять, или просто послать вас с вашей проблемой куда подальше. Issue по такому случаю уже не заводятся. Но постоянно растущий список открытых проблем на это неиллюзорно намекает.

Сравниваем

Что ж, получается, что каждая issue — это та или иная проблема, которая либо уже возникла у пользователя, либо могла бы возникнуть, либо просто есть и принимается им как данность. А это значит, что чем больше открытых issue, тем больше проблем есть в проекте. Как правило проекты с простой архитектурой вызывают меньше проблем, чем хитровыкрученные олимпиадные изыски или нагромождение паттернов.

Однако, важно понимать, что быстро поднятое упавшим не считается. Даже большое количество проблем может компенсироваться хорошей оперативной поддержкой. Фактически значимость проблемы определяется не только её серьёзностью, но и тем, сколько времени она остаётся для вас актуальной. Если проблема решается за пару часов, то она слабо повлияет на вашу работу. Но если же она висит годами, то она попьёт много крови, даже если каждый глоток будет мизерным.

Поэтому наша оценка проблемоёмкости должна быть пропорциональна не только числу открытых проблем, но и времени, в течении которого они остаются открытыми. Так что просто выкачаем все открытые issue, сложим их возраста в днях и сравним этот показатель для разных проектов решающих одну и ту же задачу. Итак, поехали...

TypeScript или FlowJS?

Правильный ответ — Haxe. Во всяком случае проблемность его существенно ниже. Хотя и тоже далеко не блещет.

React или Angular?

Разрабы Angular замутили переусложнённую архитектуру, что привело к огромной кодовой базе, в которой много багов и граблей. На поддержку всего этого дела требуется настолько много сил, что команда профессионалов из Гугла не справляется с поддержкой своего детища. Такие у меня впечатления после полу года работы с этим фреймворком. И графики это хорошо иллюстрируют.

Redux или MobX?

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

А вот у RXJS с поддержкой всё не ладно. Очевидно, дело в куда более сложных абстракциях, которые протекают во всех возможных местах и очень плохо укладываются в головах разработчиков. Существование сайтов типа RxMarbles это только подтверждает.

MomentJS или Luxon?

Ага, красный флаг у date-fns. А ведь именно её часто рекомендуют любители функциональных многоножек и шатания деревьев.

Выводы

К сожалению, если за инструментом стоит большая корпорация, то это вовсе не значит, что огребёте вы с ним меньше, чем с другим, который поддерживает один разраб на голом энтузиазме. Более того, крупная корпорация с гораздо большей вероятностью сделает неповоротливого монстра, которого благополучно закопает через несколько лет, оставив вас с тонной легаси (привет, AngularJS, здарова, Polymer, виват, GWT, алоха, GCT). Малые же команды более мотивированы сделать что-то простое, что они смогут поддерживать своими небольшими ресурсами.

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

Разумеется, есть разные вырожденные случаи типа "да этот проект никто не использует", "да тут проблемы в принципе не закрывают" и "да там просто документацию в проблемах ведут, чтобы и на гитхабе лежала и с комментариями была". Поэтому важно не просто измерять пипирки, но залезать в проекты и разбираться почему длина пипирки именно такая, и является ли это шоу-стопером.

Моя тулза для сравнения доступна на compare.github.hyoo.ru. Имейте ввиду, что она использует API гитхаба с вашего IP, а у него довольно жёсткие лимиты. Так что если гитхаб начнёт сыпать 403 ошибками, то можете либо подождать немного, либо поменять IP через VPN.

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