Количество строк кода в течение жизни

Ответ 1

Это похоже на один из таких вопросов, как "Сколько шаров для пинг-понга вы могли бы поместиться в Boeing 747?" В этом случае вопросник хочет видеть, как вы демонстрируете свои навыки решения проблем больше, чем знаете, сколько строк кода вы на самом деле писали. Я был бы осторожен, чтобы не ответить на какую-либо критику вопроса, а вместо этого честно попытаться решить проблему; )

Ответ 2

Лучший ответ на такой вопрос - одно из следующих:

• Почему вы хотите знать?
• Какое значение вы бы приписали к такому числу?
• Все в порядке, если я просто уйду и уйду сейчас?

Я бы серьезно поставил под сомнение мотивы, стоящие за тем, кто задавал такой вопрос как нынешним, так и потенциальным сотрудникам. Скорее всего, это тот же тип компании, который начнет делать обзоры кода, фокусируясь на количестве строк кода, которые вы вводите.

Теперь, если они утверждают, что количество строк кода является мерой опыта программиста, я бы определенно оставил интервью в этот момент.

Простые решения можно найти для сложных задач, и они обычно лучше, чем просто бросать достаточное количество строк кода в проблему, и он будет сортироваться. Поскольку количество ошибок, вырабатываемых линейно и выше, с количеством операторов, я бы сказал, что обратное, вероятно, лучше, в сочетании с количеством проблем, которые они решали.

В качестве тестового ответа я бы спросил:

Если в программе я могу решить проблемы A, B и C в 1000 строках кода, а другой программист решает те же проблемы в 500 строках кода, кто из нас лучший (и ответ будет: недостаточно информации для суждения)

Теперь, если вы еще хотите оценить количество строк, я просто начну думать о проектах, которые написал человек, и сравните их размер с известным количеством. Например, у меня есть библиотека классов, которая в настоящее время насчитывает около 130 тыс. Строк кода, и я написал подобные вещи в Delphi и других языках, а также некоторые значительные проекты приложений, поэтому я бы оценил, что у меня есть хорошие 10 миллионов строк кода по крайней мере, по-моему. Является ли число значимым? Не в малейшей степени.

Ответ 3

Посмотрите ohloh. На сайте показаны показатели из проектов с открытым исходным кодом.

По оценкам сайта, 107 187 строк кода соответствуют усилиям 27 человеко-лет (4000 строк кода в год).

Примером глупости такой метрики является то, что число связано с проектом, который я занимался с внешней работой в течение 2 лет.

Ответ 4

Похоже, это вопросник D E Shaw?

Ответ 5

Существует три способа борьбы со смешными запросами на бессмысленные показатели.

• Откажитесь от ответа, оспаривая вопросника по их причинам и объясняя, почему эти причины глупы.

• Время траты, собирающее всю информацию, которую вы можете, и рассчитывая ответ в меру своих возможностей.

• Составляя правдоподобный ответ и двигаясь с минимальной эмоциональной вовлеченностью, возможной в глупости, насколько это возможно.

Первые ответы, которые я вижу, кажутся первыми. Подумайте о том, хотите ли вы продолжать работу, несмотря на тупость их требований. Если ответ еще есть Да, избегайте номера 1.

Второй метод предполагает просмотр ваших старых репозиториев кода из старых проектов.

В этом случае я бы пошел третьим путем.

Умножьте количество лет, с которыми вы работали на языке, на 200 рабочих дней в год, на 20 строк кода в день и используйте это.

Если вы требуете более одного языка в год, распределите его между ними.

Если вы больше работаете над анализом, дизайном или управлением, опустите цифру на три четверти.

Если вы работали в обстановке высокой оценки (защита, медицина), уменьшите фигуру на порядок.

Если вы работаете в среде с особенно низкой церемонией, увеличьте ее на порядок.

Затем поместите тупость позади вас и займитесь своей жизнью как можно быстрее

Ответ 6

В зависимости от того, что они делают с ответом, я не думаю, что это плохой вопрос. Например, если кандидат помещает JavaScript в свое резюме, я хочу знать, сколько JavaScript они на самом деле писали. Я могу спросить, например, количество строк в самом большом проекте JavaScript, который они написали. Но я ищу только масштаб, а не фактическое число. Это 10, 100, 1000 или 10000 строк?

Когда я спрошу, я сделаю очень ясно, что я просто ищу грубое количество, чтобы оценить размер проекта. Надеюсь, что работодатель в вопросе опрашиваемых после этого.

Ответ 7

Это интересная метрика, которая требует, чтобы вы могли написать много строк неправильного кода вместо того, чтобы писать только несколько умных.

Я могу только предположить, что они рассматривают большее количество строк лучше, чем меньше. Было бы лучше не планировать вообще и просто начинать писать код. Это был бы отличный способ написать больше строк кода, поскольку, по крайней мере, если я это сделаю, я обычно заканчиваю писать все как минимум дважды.

Ответ 8

Умные обычно избегают организации, задающей такой вопрос. Если правильный ответ "да, wtf??"

Ответ 9

Зачем беспокоиться о вычислении этой метрики без уважительной причины? И некоторая случайная компания, запрашивающая метрику действительно, не является веской причиной.

Если вопрос компании действительно серьезный, и вы считаете, что интервью может привести к чему-то интересному, тогда я бы просто выбрал случайное число, чтобы увидеть, где это ведет: -)

Ответ 10

Ха, напоминает мне, когда я взял на себя основу тестирования на основе C, которая начиналась как 20K + линии, которые я закончил тем, что рухнул в 1K LOC, вместо этого вместо подпрограммы из 20K строк кода diarrea, первоначально написанного оригинальным автором. К сожалению, Я получил более тяжелую работу за любые ошибки в коде, так как мой KLOC написал на самом деле отрицательный... Я думаю, долго и упорно о сокращении базы коды в метриках инициативы организации....

Ответ 11

Если бы вы были честными действительно, тогда вы сказали бы, что не знаете, потому что вы никогда не рассматривали его как действительную метрику. Если интервьюер является разумным/рациональным человеком, то это ответ, который они ищут.

Единственный другой способ сказать, что вы не знаете, это угадать, и это действительно не демонстрирует навыки решения проблем.

Ответ 12

Даже если я согласен с большинством в том, что это не очень хороший показатель, если это серьезное вознаграждение, как вы говорите, у них могут быть причины спросить об этом. Это то, что я, вероятно, сделал бы:

Возьмите один из ваших существующих проектов, получите количество строк и разделите их на время, когда вам понадобилось его кодировать. Это даст вам несколько строк в метрике часа. Затем попробуйте оценить, сколько раз вы работали с этим конкретным языком и умножить его на уже рассчитанную метрику. Честно говоря, я не думаю, что это отличный способ... но честно, это не большой вопрос. Я также расскажу компании о стратегии, которую я использовал, чтобы придумать этот номер.. возможно, MAYBE, это то, что они хотят... узнать ваше мнение об этом вопросе и как вы ответили бы на него?: Р

Или они просто хотят знать, есть ли у вас опыт. Итак, угадайте внушительное число и запишите его: D

Ответ 13

"Это очень уважаемая компания в своей области, и я уверен, что у них есть очень веская причина задать этот вопрос"

И я очень уверен, что они этого не делают, потому что "уважение" не означает "они все делают правильно", потому что это, конечно, не так, или если это так, то это по крайней мере глупо по моему мнению.

Что такое "Линии кода"? Полагаю, что я написал около 250 000 строк кода С#, возможно, намного больше. Проблема? 95% - это код, но не все для обучения. Я все еще нахожу, что пишу небольшую 3-строчную программу в десятый раз просто потому, что легче записать эти три строки снова (и изменить параметр), чем искать существующие.

Кроме того, строки кода означают ничего. Таким образом, у меня есть два парня, один написал на 20% больше строк, а другой, но на 20% больше ненужных сложных строк, "цикл-разворачивание" и в противном случае бесполезный материал, который можно было бы реорганизовать.

Так жаль, уважаемая компания или нет: просить строки кода - верный признак того, что они не имеют понятия об измерении эффективности своих программистов, а это значит, что они должны полагаться на методы каменного века, такие как измерение LoC, которые примерно так же точно, как календари в каменном веке. Это означает, что это, возможно, хорошее место для работы, если вам нравится расслабляться и раздувать ваши цифры каждый раз.

Хорошо, это было скорее напыщенностью, чем ответом, но я действительно не вижу абсолютно никакой причины для этого числа.

Ответ 14

И никто еще не привел рассказ Билла Аткинсона -2000...

В свою пятницу днем ​​(ну, около одной пятницы в месяц) упражнения по саморазвитию на работе за прошедший год, включая тесты, прототипы и инфраструктуру, я, вероятно, написал около 5 kloc. Однако один проект взял существующее приложение 25kloc C/С++ и повторил его как 1100 строк Erlang, а другой взял 15kloc существующей библиотеки C и превратил его в 1kloc С++, поэтому сеть сильно отрицательна. И единственная причина, по которой у меня есть эти цифры, это то, что я смотрел, как негатив.

Ответ 15

Я знаю, что это старый пост, но это может быть полезно кому-то в любом случае...

Недавно я перешел от компании, в которой я работал примерно 9,5 лет в качестве разработчика Java. Весь наш код был в CVS, затем SVN, с Atlassian Fisheye, в котором он был представлен.

Когда я ушел, Fisheye сообщал мой личный, общий LOC как + - 250 000. Здесь описание Fisheye показатель LOC, в том числе обсуждение того, как рассчитывается каждый пользовательский LOC пользователя SVN. Обратите внимание на проблемы с ветвлением и слиянием в SVN, и что LOC обычно должен основываться только на TRUNK.