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