Сколько строк кода может создать разработчик C # в месяц? [закрыто]

Руководитель на моем рабочем месте задал мне и моей группе разработчиков вопрос:

Сколько строк кода может создать разработчик C # в месяц?

Старая система должна была быть портирована на C #, и он хотел бы, чтобы эта мера была частью планирования проекта.

Из какого-то (очевидно заслуживающего доверия) источника у него был ответ «10 SLOC / month », но он не был доволен этим.

Группа согласилась, что это почти невозможно определить, поскольку это будет зависеть от длинного списка обстоятельств. Но мы могли бы сказать, что этот человек не уйдет (или будет очень разочарован в нас), если мы не придумаем ответ, который подходит ему лучше. Поэтому он ушел с гораздо лучшим ответом «10 SLOC / день »

Можно ли ответить на этот вопрос? (от руки или даже с некоторым анализом)

Спросите своего руководителя, сколько страниц контракта может написать его адвокат в месяц. Затем (надеюсь) он поймет, что существует огромная разница между написанием одностраничного договора и написанием 300-страничного договора без лазеек и противоречий. Или между написанием нового контракта и изменением существующего. Или между написанием нового контракта и переводом его на другой язык. Или в другую правовую систему. Может быть, он даже согласится с тем, что «количество страниц контракта за единицу времени» не очень хорошая мера для производительности юриста.

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

Сколько строк кода может создать разработчик C # в месяц?

Если они хороши, меньше нуля.

Беги в другую сторону ... Сейчас.

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

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

В зависимости от сложности кода, портирование может осуществляться процессами автоматизации, которые приводят к большим изменениям в тысячах + LoC в день, тогда как более сложные секции, где языковые конструкции представляют собой совершенно разные коды, переносятся при 100LoC в день.

Отправьте его на страницу Википедии на SLOC . If приводит несколько хороших и простых примеров того, почему это такая плохая метрика.

Правильный ответ: нет ...

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

Небрежный ответ: любой номер, который вы можете составить.

Просто дайте ему какой-нибудь номер, и вы, и ваша команда можете легко его набрать. (Помещая строку «если», «пустые строки», «комментарии» и т. Д., Просто чтобы позволить этому парню продолжать жить в своем фэнтезийном мире, преследовать еще одну команду и продолжать усиленный цикл страданий, который превращает историю в thedailywtf.

Не красиво, но выполнимо.

На первый взгляд этот вопрос выглядит совершенно глупо, и все здесь ответили только на глупую часть C # LoC. Но есть один важный нюанс - это вопрос производительности портирования . Правильный способ задать этот вопрос - спросить, сколько строк кода исходного проекта (портируемого) разработчик может обработать за определенную единицу времени. Это совершенно оправданный вопрос, поскольку известно общее количество строк кода, и это именно тот объем работы, который необходимо выполнить. И правильный способ ответить на этот вопрос - собрать немного исторических данных - работать, скажем, неделю, и измерять производительность каждого из разработчиков.

У меня есть только одна вещь, чтобы сказать:

«Измерение прогресса в программировании по строкам кода похоже на измерение прогресса в самолетостроении по весу».

-- Билл Гейтс

После этого вы можете утверждать, что Билл Гейтс не знал, как создавать успешные программы;)

Примечание: SLOC - очень хорошая мера сложности кодовой базы!

I 
can
write
large
numbers
of
lines
of
code
per
month.

Пропорционально количеству слов, на самом деле.

Вы видите мою точку зрения?

Возможно, у меня немного другая позиция по этому вопросу, но я думаю, что могу понять, почему руководители искали эту информацию, если они в настоящее время занимаются планированием проекта. Поскольку трудно оценить, сколько времени займет проект, один из методов, который используется (см .: Оценка программного обеспечения: Демистификация черного искусства ), заключается в оценке того, сколько времени потребуется проекту на основе количества SLOCs в подобных проектах, и теперь разработчики могут производить в среднем. На практике это должно делаться с использованием исторических записей, которые есть у группы для аналогичных проектов с одинаковыми или похожими разработчиками.

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

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

Некоторые люди, которые на самом деле не считаются идиотами, использовали метрики, основанные на строках кода. Их использовали Фред Брукс, Барри Бём, Каперс Джонс, Уоттс Хамфрис, Майкл Фаган и Стив Макконнелл. Вы, вероятно, использовали их, даже если просто сказать коллеге, этот модуль Бога состоит из 4000 строк, его нужно разбить на более мелкие классы.

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

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

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

• Когда код написан быстро, небрежно, раздуто и без каких-либо попыток рефакторинга, видимая эффективность будет максимальной. Мораль здесь будет в том, что вы должны быть осторожны с тем, что вы измеряете.
• Для конкретного разработчика, если он добавляет или касается большого количества кода на этой неделе, на следующей неделе может возникнуть техническая задолженность, связанная с проверкой, тестированием, отладкой и переработкой кода.
• Некоторые разработчики будут работать с более стабильной скоростью, чем другие. Может оказаться, что они тратят больше всего времени на получение хороших пользовательских историй, очень быстро оборачиваются и проводят соответствующие модульные тесты, а затем оборачиваются и быстро создают код, ориентированный только на пользовательские истории. Суть в том, что разработчики методики, вероятно, быстро развернутся, напишут компактный код и не будут много переделывать, потому что они очень хорошо понимают проблему и решение, прежде чем начнут кодировать. Кажется разумным, что они будут кодировать меньше, потому что они кодируют только после того, как они обдумают это, а не до и после.
• Когда код оценивается на предмет его плотности дефектов, он оказывается менее равномерным. Некоторый код будет отвечать за большинство проблем и дефектов. Это будет кандидатом на переписывание. Когда это произойдет, он станет самым дорогим кодом, потому что благодаря этому высокая степень переделки. Он будет иметь наибольшее количество строк кода (добавлено, удалено, изменено, как может быть сообщено с помощью такого инструмента, как CVS или SVN), но затрачивает наименьшее количество чистых строк кода в час. Это может оказаться комбинацией кода, реализующего наиболее сложную проблему или наиболее сложное решение.

Независимо от того, как получаются споры о производительности программистов в строках кода, вы обнаружите, что вам нужно больше человеческих сил, чем вы можете себе позволить, и система никогда не будет завершена вовремя. Вы настоящие инструменты не метрики. Это использование превосходной методологии, лучшие разработчики, которых вы можете нанять или обучить, а также контроль масштабов и рисков (возможно, с помощью Agile-методов).

Дайте ему лучший показатель для работы с

Вместо LOC , объяснить это худший показатель для использования. Тогда дайте ему альтернативу:

Количество функций / возможностей Per Feature / Функция Просьбы -> Noff / RFF

Вам может понадобиться добавить взвешивание / нормализацию поверх NOFF / RFF, чтобы удовлетворить количество запросов в неделю.

:) ясно, что вышеизложенное составлено, но все, что лучше, чем SLOC ...

Я могу сказать вам, что множество подрядчиков для большого проекта написали 15000 LOC (каждый) в год. Это невероятно грубый ответ, но он был полезен для нас, поскольку у нас есть 400 000 существующих C ++ LoC, и мы могли бы понять, что для преобразования всего этого в C # нам потребуется около 26 человеко-лет. Дай или возьми.

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

Поэтому мой совет для вас - проверить весь код, который вы написали за определенное время (мне повезло, что у меня был новый проект для работы), а затем запустить один из многих инструментов метрики кода. Разделите число на время, и вы сможете дать ему точный ответ - сколько LOC вы фактически пишете в день. Для нас это выходило на уровне 90 LOC в день! Я думаю, у нас было много встреч и документации по этому проекту, но потом, я думаю, у нас будет много встреч и документации по следующему :)

Звучит о правильном.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Если принять во внимание отладку, документацию, планирование и т. Д. В среднем оно составляет около 10 строк кода в день. На самом деле я бы оценил 10 строк в день на высокой стороне (т.е. очень продуктивный разработчик).

Даже если вы можете произвести несколько сотен строк за один день (это невозможно). Это не будет качественный код, пока вы не добавите всю модульную проверку документации и, конечно, отладите код после того, как ваш модульный тест покажет ошибки. После всего, что вы сделали, вы вернулись к 10.

Я предполагаю, что разработчик, работающий с таким языком, как C #, должен иметь возможность писать / генерировать около 10 000 LoC в день. Я полагаю, я мог бы сделать это. Я просто никогда не буду.

Что вы хотите от разработчика, так это чтобы его работа выполнялась за 10 циклов в день. Меньше кода всегда лучше. Я часто начинаю производить большую часть кода и затем сокращать его, пока не достигну максимальной простоты, поэтому у меня действительно есть дни с отрицательными LoC.

В некотором смысле кодирование похоже на поэзию. Вопрос не в том, сколько строк может написать поэт, а в том, сколько он может передать в 14 строках сонета.

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

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

В другой стороны, обстоятельства таковы , что исполнительная власть в своем вопросе IS ваш инженерная и / или руководитель проекта. У вас есть гораздо большие и более основные проблемы для решения, даже если они еще не раскрылись. В этом случае такая проблема может послужить «предупреждением» для более серьезных проблем.

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

Это около 3000 строк кода на C # без XML-документа. Я внедрял новую функциональность и в итоге получил эту сумму за месяц или месяц и одну неделю. Это все, что заканчивалось контролем исходного кода, много кода было написано, а затем рефакторинг или удаление.

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

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

Ну, я немного опаздываю на эту вечеринку, как обычно, но на самом деле она интересная. Первоначально у меня была та же мысль, что и у большинства, что вопрос руководителя глупый. Однако я прочитал ответ SK-logic и понял, что это разумный вопрос, который задают бессмысленным образом. Или, другими словами, за этим вопросом стоит серьезная проблема.

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

Более разумный подход будет:

1. Для оценки на месте спросите разработчиков с наибольшим опытом работы с кодом, чтобы узнать, сколько времени это займет. Это должно быть неправильно по многим причинам, которые я не буду здесь вдаваться, но это лучшее, что они смогут сделать с самого начала. По крайней мере, они должны иметь представление о том, будет ли это легко сделано через неделю или годы, даже с дополнительными ресурсами. Если бы были какие-либо порты подобного размера или выполненные работы, они могли бы использовать это в качестве руководства.
2. Оцените порт по компонентам, чтобы получить общий размер. Необходимо включить задачи, которые не имеют прямого отношения к порту, такие как настройка инфраструктуры (машины, системы сборки и т. Д.), Исследование и покупка программного обеспечения и т. Д.
3. Определите наиболее опасные компоненты порта и начните с них первыми. Скорее всего, они больше всего искажают оценку, поэтому следует делать это заранее, если это возможно, чтобы в порту было мало сюрпризов.
4. Отслеживайте прогресс в сравнении с размерами, выполненными на шаге 2, чтобы постоянно рассчитывать ожидаемую продолжительность порта. По мере продвижения проекта это должно стать более точным. Конечно, количество строк кода, которые были перенесены (функции в исходной кодовой базе, которые теперь находятся в перенесенном коде), также может использоваться в качестве метрики и фактически полезно, чтобы гарантировать, что исходный продукт переносится, а не куча крутых новых функциональных возможностей, добавленных, не затрагивая фактический порт.

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