The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Lines-of-Code (известный также как SLoC) - это метрика с ужасной репутацией. Попробуйте погуглить ее сами и вы найдете множество статей, осуждающих ее недейственность и разрушительность для процесса разработки программного обеспечения. Основной аргумент заключается в том, что мы не можем измерить прогресс программирования по количеству написанных строк кода. Вероятно, самая известная цитата принадлежит Биллу Гейтсу:
Измерение прогресса программирования по количеству строк кода — это, как измерение прогресса строительства самолета по весу.
В основном, это означает, что определенные части самолета потребуют гораздо больше усилий, при этом будут намного легче других (например, центральный компьютер). Вместо того чтобы измерять вес самолета, мы должны измерять усилия, вкладываемые в него… каким-то образом. Итак, вот идея. Что если мы измерим количество раз, когда программисты касаются строк. Вместо подсчета количества строк мы будем считать, сколько раз они были фактически изменены—эту информацию мы можем получить из Git (или любой другой системы контроля версий). Чем больше вы касаетесь этой части самолета—тем больше усилий вы вложили в нее, верно?
Я назвал это Hits-of-Code (HoC) и создал небольшой инструмент, чтобы помочь нам вычислить это число всего в одной строке. Это Ruby-пакет, установите его и запустите:
$ gem install hoc
$ hoc
54687
Число 54687 представляет собой общее количество кодовых хитов в вашей кодовой базе. Принцип, лежащий в основе этого числа, является примитивным - каждый раз, когда строка кода изменяется, создается или удаляется в коммите Git, счетчик увеличивается.
Основная причина того, почему эта метрика лучше, чем LoC, заключается в том, что она гораздо лучше соответствует реальным усилиям, вкладываемым в кодовую базу. Вот почему.
It Always Increments
Метрика HoC всегда растет. Сегодня она не может быть ниже, чем вчера - так же, как и усилия, она всегда увеличивается. Кодовые строки не ведут себя таким образом. У вас может быть огромная база кода сегодня, но после рефакторинга она станет намного меньше. Количество строк кода уменьшается. Значит ли это, что вы менее эффективны? Определенно нет, но метрика LoC говорит об обратном для непрограммиста. Например, менеджер проекта может решить, что поскольку размер кодовой базы остался неизменным за последний месяц, команда не работает.
HoC не имеет такого контринтуитивного эффекта. Вместо этого HoC растет вместе с каждым вашим коммитом. Чем больше вы работаете с кодовой базой, тем больше HoC. Не важно, насколько большим или маленьким является абсолютный размер вашего продукта. Важно, сколько усилий вы вкладываете в него. Вот почему HoC очень интуитивен и может использоваться в качестве меры прогресса в разработке программного обеспечения.
Посмотрите на этот график за 18 месяцев; он показывает оба показателя вместе. Я использовал ту же кодовую базу на языке Java, что и rultor, помощник DevOps. Как видно на графике, несколько месяцев назад кодовая база претерпела крупную рефакторинг. Я думаю, очевидно, какой показатель на этом графике больше говорит о затраченных усилиях на продукт.
It Is Objective
Для HoC не имеет значения, насколько большим является абсолютный размер кодовой базы, но только насколько значимым является ваш относительный вклад в нее.
Предположим, у вас есть 300 тысяч строк кода, и 95% из них были скопированы из сторонних библиотек (кстати, это очень распространенная и ужасная практика - хранить сторонний код внутри своего репозитория). Объем кода будет большим, но фактическая часть пользовательского кода будет относительно небольшой. Таким образом, метрика количества строк кода будет вводить в заблуждение - она всегда будет показывать 300 тысяч с небольшими приращениями или убываниями вокруг этого значения. У всех будет ощущение, что команда работает с базой кода из 300 тысяч строк.
С другой стороны, HoC всегда будет учитывать ту часть кода, которая фактически изменяется. Значение HoC будет объективно коррелировать с реальными усилиями программистов, работающих с кодовой базой.
It Exposes Complexity of Lines
LoC обычно критикуют за его нейтральность по отношению к сложности кода. Автоматически сгенерированный класс ORM или сложный алгоритм сортировки могут иметь одинаковый размер в терминах строк кода, но первый требует несколько секунд для написания, в то время как второй может занимать недели или месяцы. Вот почему строки кода обычно считают ложной метрикой.
Hits-of-Code учитывает сложность, потому что чем дольше вы работаете с этим алгоритмом сортировки, тем больше изменений вы вносите в его строки. Ну, это утверждение верно, если вы регулярно используете Git и часто фиксируете свои изменения - таким образом вы сообщаете Git о прогрессе вашей работы.
Conclusion
Наконец, посмотрите на этот список открытых проектов, выполненных нашей командой за последние несколько лет. У каждого проекта есть две метрики: количество строк кода и количество хитов кода. Интересно увидеть, что относительно небольшие проекты имеют очень большие (более миллиона) значения HoC. Это сразу напоминает мне, сколько времени мы в них вложили и насколько они старые.
Я использовал метрику HoC в этом анализе: Сколько вы платите за строку кода?. В этом посте сравнивается традиционный проект, который платил $3.98 за HoC, и открытый проект, управляемый Zerocracy, который платил ¢13.
Мой вывод заключается в том, что данная метрика Hits-of-Code может быть использована в качестве инструмента для отслеживания прогресса в проекте разработки программного обеспечения. Более того, она может быть использована для оценки размера команды, бюджета проекта, графика разработки и так далее. Очевидно, что HoC не может быть единственной метрикой, но в сочетании с другими она может значительно помочь при оценке, планировании и отслеживании.
PS. Попробуйте hitsofcode.com.
Translated by ChatGPT gpt-3.5-turbo/35 on 2023-09-09 at 05:11
