Автор Патрик ДеВиво
По мере того, как я больше работаю над tickgit 🎟️, постоянно возникает вопрос, являются ли TODO-комментарии полезным индикатором работоспособности кодовой базы. В общем, думаю, что нет - по крайней мере, самостоятельно. Однако это заставляет меня задуматься об общем вопросе измерения работоспособности кодовой базы.
Как мы можем измерить «работоспособность» проекта только на странице Github, даже не глядя на содержимое кода? Это типичный вопрос при сравнении двух проектов или библиотек, которые имеют схожую функциональность, с целью решить, какой из них «лучше» использовать. Если все остальное в основном одинаково с точки зрения функциональности и сценария использования, какие факторы вы обычно используете, чтобы определить, какой проект «более здоровый»?
В данном случае «здоровый» для меня означает проект, который находится в хорошем состоянии и будет таким и дальше. Я думаю, что важно не только оценить, был ли проект в последнее время здоровым, но и искать индикаторы того, что он будет продолжаться.
Я перечислю некоторые «показатели» или факторы, которые кажутся мне важными. Я постараюсь быть максимально агностиком языка, поскольку разные языковые экосистемы имеют разные практики и отношения к оценке зависимостей сторонних разработчиков.
⏳ Когда последний раз обновлялся или выпускался код?
Я думаю, что это довольно распространенная и базовая мера, которую можно использовать при оценке проекта - был ли он недавно принят или нет? Были ли недавние релизы? Вероятно, это важный показатель состояния проекта, поскольку он показывает текущее обслуживание, разработку функций и общую «заботу» со стороны сопровождающих.
Однако в этой оценке есть некоторая тонкость, потому что я не думаю, что «новизна последней фиксации» имеет смысл сама по себе. Также важно оценить, когда произошли последние значимые фиксации, а не только поверхностные обновления (например, правки README или незначительные изменения кода). Это может быть трудно различить, и, возможно, хороший способ оценить - взглянуть на журналы изменений или текущие выпуски, чтобы лучше понять.
Однако если заметить, что проект не обновлялся годами или месяцами, это очень хорошая отправная точка для оценки нездоровья. Если прошло несколько лет, то, вероятно, это заброшенный проект (чтобы констатировать очевидное).
👤 Кто его обслуживает?
Поддерживает этот проект крупная технологическая компания или частное лицо? Кто основные участники проекта? Это сторонний проект одного человека или несколько человек вносят свой вклад?
Я думаю, что основной вопрос здесь о «ключевом риске». Зависит ли этот проект от одного человека или существует достаточный импульс, чтобы нагрузка по обслуживанию распределялась между командой или группой участников?
Я не думаю, что для проекта обязательно плохо быть зависимым от одного человека, особенно если у него открытый исходный код и есть какие-то рамки для получения пожертвований. Однако это риск. Возможно, важно также оценить человека, поддерживающего проект. Сами ли они работают в крупной компании, которая использует этот проект? Поддерживают ли они другие «успешные» проекты? Есть ли у них какой-то уровень «профиля» или репутация разработчика?
Я думаю, что проекты от устоявшихся компаний, вероятно, будут более надежными, чем от частных лиц (хотя слева и справа есть исключения). Однако это не означает, что в этих проектах нет никакого риска, связанного с ключевыми людьми, поскольку «ключевым человеком» действительно может быть сама компания.
В общем, суждение о том, кто поддерживает проект, является важной частью оценки того, будет ли он и дальше поддерживаться. Возможно, важно понимать причины, по которым сопровождающие тоже вносят свой вклад (это основная часть их бизнеса или просто побочный проект?)
↩️ Какие еще проекты зависят от этого?
Это может быть трудно понять, если не рекламируется самим проектом, но я думаю, что это важный показатель того, насколько «проверенной в боевых условиях» может быть кодовая база. Какие еще важные проекты также полагаются на эту библиотеку или инструмент?
Высококлассные проекты или большое количество пользователей указывают мне на валидацию и возможность продолжения обслуживания.
Валидация в том, что многие другие (или другие высококлассные проекты) предварительно проверили эту зависимость и приняли ее для себя. «Если это достаточно хорошо для них, это достаточно хорошо для меня».
Предположительно, проекты с большим количеством и / или важными пользователями будут более мотивированы оставаться в курсе и постоянно улучшаться благодаря отзывам пользователей.
❤️ Фактор «заботы»
Это, безусловно, более субъективная «метрика», которую нужно оценивать при просмотре репозитория. Фактором заботы для меня является поиск индикаторов того, что разработчики активно хотят, чтобы у потребителей их продукта был хороший пользовательский опыт, они активно заботятся о работоспособности своего кода и простоте его использования.
- README тщательно и хорошо продуман?
- Есть ли показатели заранее? Покрытие тестов, статус CI, количество загрузок, значки и т. Д.
- Как документация? Руководства по началу работы?
- Есть ли активное обсуждение проблем и PR?
- Есть ли у проекта собственный веб-сайт, список адресов электронной почты, сообщества?
- Есть ли четкая дорожная карта предстоящих функций, и процесс, в котором принимаются и разрабатываются изменения / улучшения?
Что еще?
Я ценю, что вы зашли так далеко! Вообще говоря, мне интересно лучше понять, как мы можем измерять «работоспособность» проектов без привязки к коду. Мне очень любопытно узнать, можно ли преобразовать вышеупомянутые соображения в более количественные значения. Как может выглядеть «оценочная карта» или диаграмма, фиксирующая вышеуказанное?
