Когда, если вообще, "число строк кода" является полезной метрикой?
Некоторые люди утверждают, что худшим врагом кода является его размер, и я склонен согласиться. Тем не менее, каждый день вы продолжаете слышать такие вещи, как
- Я пишу бла строки кода в день.
- У меня есть х строк кода.
- Windows - это миллион строк кода.
Вопрос: Когда полезно использовать "#lines of code"?
PS: Обратите внимание, что когда такие заявления сделаны, тон "больше, тем лучше".
45 ответов
Я бы сказал, что когда вы удаляете код, чтобы проект работал лучше.
Сказать, что вы удалили "X количество строк", впечатляет. И гораздо полезнее, чем вы добавили строки кода.
Я удивлен, что никто еще не упомянул знаменитую цитату Дейкстры, так что вот так:
Сегодня я хочу сказать, что если мы хотим посчитать строки кода, мы должны рассматривать их не как "произведенные строки", а как "потраченные строки": текущая общепринятая мудрость настолько глупа, что забирать книги с неправильной стороны гроссбух.
Цитата из статьи под названием " О жестокости по-настоящему преподавания информатики".
Это ужасный показатель, но, как отметили другие люди, он дает вам (очень) грубое представление об общей сложности системы. Если вы сравниваете два проекта, A и B, и A - это 10000 строк кода, а B - 20 000, это мало о чем говорит - проект B может быть слишком многословным, или A может быть сверхсжатым.
С другой стороны, если один проект содержит 10 000 строк кода, а другой - 1 000 000 строк, второй проект в целом значительно сложнее.
Проблемы с этим показателем возникают, когда он используется для оценки производительности или уровня вклада в какой-либо проект. Если программист "X" записывает в 2 раза больше строк, чем программист "Y", он может или не может вносить больший вклад - возможно, "Y" работает над более сложной проблемой...
По крайней мере, не для прогресса
"Измерение прогресса в программировании по строкам кода похоже на измерение прогресса в самолетостроении по весу". - Билл Гейтс
Есть один конкретный случай, когда я нахожу это бесценным. Когда вы проходите собеседование и вам говорят, что частью вашей работы будет поддержание существующего C++/Perl/Java/ и т. Д. унаследованный проект. Спросите интервьюера, сколько KLOC (приблизительно) вовлечено в унаследованный проект, даст вам лучшее представление о том, хотите ли вы их работу или нет.
Это полезно при загрузке вашего линейного принтера, чтобы вы знали, сколько страниц займет распечатанный код.;)
Напоминает мне об этом:
Настоящее письмо очень длинное, просто потому, что у меня не было времени, чтобы сделать его короче.
--Блез Паскаль.
Как и большинство показателей, они очень мало значат без контекста. Таким образом, короткий ответ: никогда (кроме строчного принтера, это забавно! Кто печатает программы в эти дни?)
Пример:
Представьте, что вы тестируете модуль и рефакторинге старого кода. Он начинается с 50 000 строк кода (50 KLOC) и 1000 видимых ошибок (неудачные модульные тесты). Соотношение 1K/50KLOC = 1 ошибка на 50 строк кода. Очевидно, это ужасный код!
Теперь, спустя несколько итераций, вы уменьшили известные ошибки вдвое (а количество неизвестных ошибок более чем вероятно) и основание кода в пять раз благодаря примерному рефакторингу. Соотношение теперь 500/10000 = 1 ошибка на 20 строк кода. Что, видимо, еще хуже!
В зависимости от того, какое впечатление вы хотите произвести, это может быть представлено как одно или несколько из следующего:
- На 50% меньше ошибок
- в пять раз меньше кода
- На 80% меньше кода
- 60% ухудшение отношения ошибок к коду
все это правда (при условии, что я не облажался с математикой), и все они отстой в обобщении огромного улучшения, которого должны достичь такие усилия по рефакторингу.
Перефразируя цитату, которую я прочитал около 25 лет назад,
"Проблема использования строк кода в качестве метрики заключается в том, что она измеряет сложность решения, а не сложность проблемы".
Я полагаю, что цитата от Дэвида Парнаса в статье в Журнале ACM.
Есть много разных метрик программного обеспечения. Строки кода являются наиболее используемыми и простыми для понимания.
Я удивлен, как часто строки метрики кода соотносятся с другими метриками. Вместо покупки инструмента, который может вычислять цикломатическую сложность для обнаружения запахов кода, я просто ищу методы со многими строками, и они также имеют высокую сложность.
Хорошим примером использования строк кода является метрика: количество ошибок в строках кода. Это может дать вам представление о том, сколько ошибок вы ожидаете найти в своем проекте. В моей организации у нас обычно около 20 ошибок на 1000 строк кода. Это означает, что если мы готовы отгрузить продукт, имеющий 100 000 строк кода, и наша база данных ошибок показывает, что мы нашли 50 ошибок, то, вероятно, нам следует провести еще какое-то тестирование. Если у нас есть 20 ошибок на 1000 строк кода, то мы, вероятно, приближаемся к качеству, которое мы обычно достигаем.
Плохой пример использования - измерение производительности разработчика. Если вы измеряете продуктивность разработчиков по строкам кода, то люди, как правило, используют больше строк, чтобы предоставлять меньше.
Ответ: когда можно говорить о негативных строках кода. Как в: "Сегодня я удалил 40 посторонних строк кода, и программа все еще работает так же, как и раньше".
Я бы согласился, что взятие общего количества строк кода в проекте является одним из способов измерения сложности.
Это, конечно, не единственная мера сложности. Например, отладка запутанного сценария Perl из 100 строк сильно отличается от отладки Java-проекта из 5000 строк с шаблонами комментариев.
Но, не глядя на исходный код, вы, как правило, думаете, что большее количество строк кода является более сложным, так же, как вы думаете, что исходный архив 10 МБ сложнее, чем исходный архив 15 КБ.
Профиль зрелости процесса Института разработки программного обеспечения сообщества разработчиков программного обеспечения: обновление на конец 1998 года (к которому я не смог найти ссылку, к сожалению) обсуждает опрос около 800 групп разработчиков программного обеспечения (или, возможно, это были магазины). Средняя плотность дефектов составляла 12 дефектов на 1000 LOC.
Если у вас было приложение с 0 дефектами (оно не существует на самом деле, но давайте предположим) и вы написали в среднем 1000 LOC, вы можете предположить, что вы только что ввели 12 дефектов в систему. Если QA обнаружит 1 или 2 дефекта, и это все, то они должны провести больше тестов, так как, вероятно, существует более 10 дефектов.
Мне кажется, что существует ограниченный предел количества строк кода, на которые я могу ссылаться в любом конкретном проекте. Предел, вероятно, очень похож на среднего программиста. Поэтому, если вы знаете, что ваш проект содержит 2 миллиона строк кода, и ваши программисты могут понять, связана ли ошибка с хорошо известными строками кода 5K, то вы знаете, что вам нужно нанять 400 Программисты для вашей кодовой базы должны быть хорошо прикрыты чьей-то памятью.
Это также заставит вас дважды задуматься о слишком быстром увеличении вашей кодовой базы и может заставить задуматься о ее рефакторинге, чтобы сделать ее более понятной.
Обратите внимание, я составил эти цифры.
Это полезно во многих отношениях.
Я не помню точного #, но у Microsoft был веб-каст, о котором говорилось для каждой X строк кода, в среднем существует y ошибок. Вы можете взять это утверждение и использовать его для определения базовых показателей для нескольких вещей.
- Насколько хорошо рецензент кода делает свою работу.
- оценка уровня квалификации 2 сотрудников путем сравнения коэффициентов ошибок по нескольким проектам.
Еще одна вещь, на которую мы смотрим: почему столько строк? Часто, когда новый программист оказывается в затруднительном положении, он просто копирует и вставляет куски кода вместо создания функций и инкапсуляции.
Я думаю, что я написал x строк кода за день - ужасная мера. Он не принимает во внимание сложность проблемы, язык, на котором вы пишете, и так далее.
Когда вам нужно составить бюджет на количество перфокарт, которые необходимо заказать.
Я написал 2 сообщения в блоге, отделяя все за и против подсчета строк кода (LoC):
Как вы считаете свое количество строк кода (LOC)? Идея состоит в том, чтобы объяснить, что вам нужно посчитать логическое количество строк кода вместо физического. Для этого вы можете использовать такие инструменты, как, например, NDepend.
Почему полезно подсчитывать количество строк кода (LOC)? Идея заключается в том, что LoC никогда не следует использовать для измерения производительности, а скорее для оценки покрытия тестами и оценки срока исполнения программного обеспечения.
Это отличный показатель для запугивания / впечатления людей. Вот и все, и определенно контекст, который я вижу во всех этих трех примерах.
Как уже говорило большинство людей, это может быть неоднозначной метрикой, особенно если вы сравниваете людей, пишущих на разных языках.
5000 строк Lisp!= 5000 строк C
Всегда. Куча новичков по этому вопросу. Мастера пишут код быстро и плотно. Хорошие выпускники пишут много строк, но слишком много пуха. Crappers копируют строки кода. Итак, сначала сделайте анализ Tiles или ворота, конечно.
LoC должен использоваться, если ваша организация не выполняет никаких точек сложности, характерных / функциональных точек, фиксации или другого анализа.
Любой разработчик, который говорит вам не измерять его или ее по LoC, - это дерьмо. Любой мастер кривошипа закодирует наш, как вы не поверите. Я работал с горсткой, которая в 20–200 раз эффективнее среднего программиста. И их код очень, очень, очень компактный и эффективный. Да, подобно Джистре, у них огромные ментальные модели.
Наконец, в любом начинании большинство людей не очень хорошо это делают, а большинство делают это не очень хорошо. Программирование ничем не отличается.
Да, проведите анализ хитов для любого крупного проекта и выясните, что 20% плюс - мертвый код. Опять же, мастера-программисты регулярно уничтожают мертвый код и дерьмовый код.
Это показатель производительности, а также сложности. Как и все показатели, его необходимо оценивать с осторожностью. Одной метрики обычно недостаточно для полного ответа.
То есть программа на 500 строк не так сложна, как на 5000 строк. Теперь вам нужно задать другие вопросы, чтобы лучше рассмотреть программу... но теперь у вас есть метрика.
Строки кода полезно знать, когда вам интересно, становится ли файл кода слишком большим. Хммм... Этот файл теперь 5000 строк кода. Может быть, я должен рефакторинг это.
Они могут быть полезны для указания масштаба приложения - ничего не говорит о качестве! Суть в том, что если вы укажете, что работали над приложением с 1000 строками, а у них было приложение, которое составляет 500 тыс. Строк (примерно), потенциальный работодатель может понять, если у вас большой опыт работы с системой или небольшое служебное программирование.
Я полностью согласен с Уорном, что количество строк кода, которые вы удаляете из системы, более полезно, чем количество строк, которые вы добавляете.
Указывая, почему изменение займет так много времени.
"Windows - это 7 миллионов строк кода, и для проверки всех зависимостей требуется некоторое время..."
При определении уровня усилия (LOE). Если вы составляете предложение, и у вас будет примерно столько же инженеров, работающих над новым проектом, то вы сможете определить, сколько инженеров нужно для того, как долго.
Строки кода на самом деле не так полезны, и если руководство использует их как метрику, это приводит к тому, что программисты проводят много рефакторинга, чтобы повысить свои оценки. Кроме того, плохие алгоритмы не заменяются аккуратными короткими алгоритмами, потому что это приводит к отрицательному количеству LOC, которое считается против вас. Если честно, просто не работайте на компанию, которая использует LOC/d в качестве показателя производительности, потому что руководство явно не имеет никакого понятия о разработке программного обеспечения, и, таким образом, вы всегда будете в шаге от первого дня.
Когда вы проводите рефакторинг кодовой базы и можете показать, что вы удалили строки кода, и все регрессионные тесты все еще пройдены.
Проверьте определение Википедии: http://en.wikipedia.org/wiki/Source_lines_of_code
SLOC = "исходные строки кода"
На самом деле, в эти метрики, где я работаю, уходит совсем немного времени. Есть также разные способы подсчета SLOC.
Из статьи в Википедии:
Существует два основных типа мер SLOC: физический SLOC и логический SLOC.
Еще один хороший ресурс: http://www.dwheeler.com/sloc/