LOC, вероятно, является одной из наиболее злоупотребляемых метрик, и, как следствие, это, вероятно, одна из более бесполезных мер качества кода и еще более бесполезная оценка усилий по программированию.
Да, это смелое заявление для меня, и нет, я не могу указать вам на исследования, подтверждающие мою точку зрения. Тем не менее, с трудом заработав, я могу заявить, что когда вы начинаете беспокоиться о том, сколько кода вы написали, вы, вероятно, беспокоитесь о неправильных проблемах.
Сначала вам нужно спросить себя, что вы пытаетесь измерить или доказать, и является ли это доказательство просто интересным, или для поддержки более широкого улучшения качества, и где вам нужно использовать эту информацию, чтобы получить бай-ин от вашей команды. / управление, чтобы сделать что-то с этим.
Одна из вещей, для которых я склонен использовать LOC - это проверка работоспособности. Если я нахожу, что пишу много кода, меня больше интересует LOC для метода или LOC для класса, а не LOC для всех. Эти измерения могут быть индикаторами того, что вам нужно провести дальнейший рефакторинг, если вы чувствуете небольшую невнимательность к тому, насколько хорошо должен быть составлен ваш код. Очень большие классы могут быть реорганизованы в несколько более мелких классов, а длинные многострочные методы могут быть разбиты на несколько методов, других классов или даже могут указывать на некоторое повторение, которое можно удалить. Обратите внимание, что я использовал слово «мог» несколько раз там.
Реальность такова, что LOC предоставляет только возможный индикатор, и нет реальной гарантии того, что ваш код может потребоваться изменить. Реальный вопрос, который нужно задать, заключается в том, будет ли код вести себя так, как требуется и как ожидается. Если это так, то ваш следующий вопрос заключается в том, сможете ли вы легко поддерживать код, и будет ли у вас время либо сейчас, либо в будущем, чтобы внести изменения в работающий код, чтобы уменьшить затраты на обслуживание в будущем.
Часто большое количество кода означает, что у вас будет больше возможностей для поддержки позже, но иногда даже хорошо продуманный код может растягиваться до сотен строк кода, и да, иногда вы можете писать сотни строк кода в день. Однако опыт подсказывает мне, что, если я поддерживаю вывод сотен строк нового кода каждый день, то часто возникает риск того, что большая часть кода будет ненадлежащим образом вырезана и вставлена откуда-то еще, и это само по себе может указывать на проблемы с дублирование и обслуживание, но опять же, это не гарантия, поэтому я склонен полагаться на то, что мне подсказывают мой опыт и инстинкты в зависимости от того, как выполнялись поставленные задачи.
Лучший способ избежать дилеммы, поставленной в вашем вопросе ИМХО, - это забыть о LOC и проводить рефакторинг ВСЕГДА. Сначала напишите свой тест кода, внедрите, чтобы потерпеть неудачу, выполните рефакторинг, а затем посмотрите, что может быть подвергнуто рефакторингу, а затем улучшите код. Вы покинете задание, зная, что уже дважды проверили свою работу, и вам не придется беспокоиться о том, чтобы угадать себя в будущем. На самом деле, если вы используете тестовый подход, как я уже описывал, любое измерение LOC / день в вашем законченном коде действительно будет означать, что вы написали в 3-5 раз больше измеренной суммы, и эти усилия будут успешно скрыты вашим текущим рефакторингом. усилия.