Мифический месяц месяца 10 строк за день разработчика - как близко к крупным проектам?

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

Мне нравится эта цитата:

Если мы хотим подсчитать строки кода, мы не должны рассматривать их как "созданные строки", а как "потраченные строки". - Эдсгер Дейкстра

Несколько раз вы добавили больше, удалив код, чем добавив

Ответ 4

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

Ответ 5

Как делают другие люди?

Я являюсь единственным полнофункциональным разработчиком в нашей компании и за последние 7 лет написал 500 000 строк кода OCaml и F #, что составляет около 200 строк кода в день. Тем не менее, подавляющее большинство этого кода представляют собой обучающие примеры, состоящие из сотен отдельных проектов длиной в несколько сотен строк. Кроме того, существует много дублирования между OCaml и F #. Мы не поддерживаем внутренние кодовые базы размером более 50 кОК.

В дополнение к разработке и поддержке нашего собственного программного обеспечения, я также консультировался для многих клиентов в отрасли за последние 7 лет. Для первый клиент, я написал 2000 строк OCaml в течение 3 месяцев, что составляет 20 строк кода в день. Для следующего клиента, четверо из нас создали компилятор, который генерировал миллионы строк кода C/С++/Python/Java/OCaml, а также документацию через 6 месяцев, что составляет 2000 строк кода в день для каждого разработчика. Для другого клиента я заменил 50kLOC на С++ 6kLOC F # через 6 месяцев, что составляет -352 строки кода в день. Для еще одного клиента, я переписываю 15kLOC OCaml в F #, который будет иметь тот же размер, что и 0 строк кода в день.

Для нашего текущего клиента я заменю 1 600 000 строк кода С++ и Mathematica на ~ 160kLOC из F # за 1 год (написав на заказ компилятор), который будет составлять -6000 строк кода в день. Это будет мой самый успешный проект на сегодняшний день и сэкономит нашему клиенту миллионы долларов в год на текущих расходах. Я думаю, каждый должен стремиться писать -6000 строк кода в день.

Ответ 6

Без фактической проверки моей копии "Мифического Человека-Месяца" (все, кто читает это, действительно должны иметь доступную копию), была глава, в которой Брукс смотрел на производительность по строкам, написанным. Интересным моментом для него было не фактическое количество строк, написанных в день, а тот факт, что он был примерно одинаковым для ассемблера и PL/I (я думаю, что это был язык более высокого уровня).

Брукс не собирался выбрасывать какую-то произвольную цифру производительности, но он работал с данными о реальных проектах, и, насколько я помню, они могли бы составлять в среднем 12 строк в день.

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

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

Там также вопрос об окружающей среде. Брукс предположил немного о том, что сделало бы разработчиков более быстрыми или медленными. Как и многие люди, он задал вопрос, были ли текущие причуды (интерактивная отладка с использованием систем разделения времени) лучше, чем старые (тщательное предпланирование для двухчасовой съемки с использованием всей машины).

Учитывая это, я бы проигнорировал любой фактический номер производительности, который он придумал как бесполезный; постоянная ценность книги заключается в принципах и более общих уроках, которые люди упорствуют в процессе обучения. (Эй, если бы все их узнали, книга имела бы только исторический интерес, как и все аргументы Фрейда, что есть нечто вроде подсознания.)

Ответ 7

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

Ответ 8

Было бы намного лучше понять, что говорить о физических линиях кода довольно бессмысленно. Количество физических линий кода (LoC) настолько зависит от стиля кодирования, что оно может варьироваться от порядка одного разработчика к другому.

В мире .NET есть удобный способ подсчета LoC. Точка последовательности. Точка последовательности - это единица отладки, это часть кода, выделенная темно-красным цветом при помещении точки останова. С точкой последовательности мы можем поговорить о логической LoC, и эту метрику можно сравнить на разных языках .NET. Логическая метрика LoC-кода поддерживается большинством инструментов .NET, включая метрику кода VisualStudio, NDepend или NCover.

Например, здесь используется метод 8 LoC (точки начала и конца скобок не учитываются):

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

Лично я считаю один LoC в своем собственном баллате производительности только тогда, когда:

• Он покрывается модульными тестами
• он связан с каким-то кодовым контрактом (если возможно, не все LoC, конечно, могут быть проверены контрактами).

В этом состоянии мой личный рейтинг за последние 5 лет, кодирующий инструмент NDepend для разработчиков .NET, составляет в среднем 80 физических LoC в день без какого-либо снижения качества кода. Ритм поддерживается, и я не вижу, чтобы он уменьшался в ближайшее время. В целом, NDepend - это база кода С#, которая в настоящее время весит около 115K физических LoC

Для тех, кто ненавидит подсчет LoC (я видел много из них в комментариях здесь), я подтверждаю, что после адекватной калибровки, подсчет LoC - отличный инструмент оценки. После кодирования и измерения десятков функций, достигнутых в моем конкретном контексте развития, я дошел до точки, где я могу точно оценить размер любой функции TODO в LoC и время, затрачиваемое на то, чтобы доставить ее на производство.

Ответ 9

Нет такой вещи, как серебряная пуля.

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

Например, у меня есть собственная библиотека классов. В настоящее время верны следующие статистические данные:

Всего строк: 252.682
   Строки кода: 127.323
   Комментариев: 99.538
   Пустые строки: 25.821

Предположим, что я вообще не пишу никаких комментариев, то есть 127.323 строк кода. С вашим коэффициентом эта библиотека кода займет около 10610 дней для написания. Это 29 лет.

Я, конечно, не тратил 29 лет на этот код, так как все С# и С# не было так долго.

Теперь вы можете утверждать, что код не так уж и хорош, поскольку, очевидно, я должен был превзойти ваши 12 строк в день, и да, я соглашусь с этим, но если я приведу временная шкала до того момента, когда 1.0 был выпущен (и я не начал фактически делать это до тех пор, пока не будет выпущен 2.0), который составляет 2002-02-13, около 2600 дней, в среднем 48 строк кода в день.

Все эти строки кода хороши? Черт возьми нет. Но до 12 строк кода в день?

Нет.

Все зависит.

У вас может быть программный программист с наивысшим приоритетом, который выдает код в порядке тысяч строк в день, а средний программист разворачивает код в порядке сотен строк в день, а качество - то же самое.

И да, будут ошибки.

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

Ответ 10

Стив Макконнелл дает интересную статистику в своей книге "Оценка программного обеспечения" (p62, таблица 5.2) Он различает типы проектов (Avionic, Business, Telco и т.д.) И размер проекта 10 kLOC, 100 kLOC, 250 kLOC. Номера указаны для каждой комбинации в LOC/StaffMonth. НАПРИМЕР. Авионический: 200, 50, 40 Интранет-системы (внутренние): 4000, 800, 600 Встроенные системы: 300, 70, 60

Это означает: например. для проекта Avionic 250-kLOC существует 40 (LOC/Month)/22 (Days/Month) == < 2LOC/day!

Ответ 11

Я думаю, что это происходит из развития водопада дней, где фактическая фаза развития проекта может быть всего лишь 20-30 % от общего времени проекта. Возьмите полные строки кода и разделите на все время проекта, и вы получите около 10 строк в день. Разделите только период кодирования, и вы приблизитесь к тому, что люди цитируют.

Ответ 12

Наша кодовая база составляет около 2.2MLoC около 150 человеко-летних усилий. Это составляет около 75 строк С++ или С# для каждого разработчика в день на протяжении всей жизни проекта.

Ответ 13

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

Ответ 14

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

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

Ответ 15

Один подозревает, что этот многолетний бит менеджера-конфеты был придуман, когда все было sys-приложением, написанным на C, потому что, если бы ничто иное, количество волшебников не изменилось бы на порядки в зависимости от языка, масштаба и характера приложения. И тогда вы должны скидывать комментарии и атрибуты. И в конечном счете, кто заботится о количестве строк кода, написанных? Вы должны быть закончены, когда вы достигнете линий 10K? 100K? Так произвольно.

Это бесполезно.