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

129

Все всегда говорят, что они могут превзойти «10 строк на разработчика в день» из «Месяца мифического человека», и, начиная проект, я обычно могу получить пару сотен строк за день.

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

Как дела у других? А с какими требованиями вы сталкиваетесь (я полагаю, это фактор)?

Маттиас Вандел
источник
13
должна быть вики сообщества.
Malfist 08
24
Если бы «10» было в двоичном формате, это было бы ближе к отметке.
geofftnz 08
2
Очень интересный вопрос. :)
Emil H
9
Я нашел эту красивую цитату: «Измерение прогресса программирования по строкам кода похоже на измерение прогресса постройки самолета по весу». на этом сайте [ссылка] ( devtopics.com/101-great-computer-programming-quotes )
mm24
2
@ Грег Бэкон, Билл Ящерица: Мне бы очень хотелось, чтобы этот вопрос был снова открыт. Возможно, это не совсем соответствует правилам SO, но определенно привлекает посетителей. (На данный момент 35875 зрителей)
Скиппи Фастол

Ответы:

46

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

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

Лиран Ореви
источник
На самом деле. Вначале в этом проекте чистая реклама была намного больше.
Matthias Wandel,
1
Таким образом, это подтверждает теорию о разделении большого проекта на множество независимых частей (могут быть даже независимые проекты) - для разделения.
sergzach
108

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

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

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

Чарльза Бейли
источник
49
+1 за негативные строки. Однажды я работал над небольшим проектом, в котором я сократил количество строк с 15 КБ до 5 КБ, добавляя новые функции (и значительно уменьшая количество ошибок и увеличивая скорость).
rmeador 08
55

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

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

Иногда вы внесли больше, удалив код, чем добавив

rlovtang
источник
30

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

Отавио Десио
источник
25
Я не использовал это как показатель производительности. Это было частным упражнением из моего собственного любопытства.
Matthias Wandel,
3
Справедливо. Даже в этом случае трудно ответить без более точного определения того, что следует считать строкой кода.
Otávio Décio
1
@Matthias: Я бы отредактировал это в OP, если бы я был вами, я, например, был бы менее ... агрессивным: P
annakata
28

Как дела у других?

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

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

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

JD
источник
1
Мне нравится ваш ответ, и я понимаю сарказм. В качестве любопытства, не могли бы вы пояснить, почему переписывание кода на F # сэкономит деньги вашему клиенту? Я был знаком с OCaml и написал интерпретатор на этом языке и не касался этого языка несколько лет, и теперь я продолжаю слышать о F # (так что мне это искренне любопытно)
mm24
7
@ mm24 "Не могли бы вы пояснить, почему переписывание кода на F # сэкономит деньги вашему клиенту". Во-первых, их сильно облажала компания Wolfram Research, которая взимала с них контракты на консультационные услуги в размере 1 млн фунтов стерлингов за исправление проблем, которые они намеренно вносили в обновления Mathematica, например, изменение семантики [LongDash]. Во-вторых, они могут объединить две базы кода (Mathematica и C ++), которые в настоящее время поддерживаются в тандеме, в одну базу кода F #, что сокращает не только дублирование усилий, но и количество взаимодействий с обновлениями продукта и исправлениями, выявленными при тестировании.
JD
7
@ mm24 В-третьих, автоматика. Они делают множество вещей вручную, для чего существуют либо уже существующие инструменты .NET для автоматизации, либо .NET упрощает создание таких инструментов. Задачи включают в себя оснащение кода таймерами для измерения производительности (использование профилировщика), написание сериализаторов вручную (использование библиотеки), копирование имен значений ключей вручную (использование отражения) и критические обновления действующих систем, представленные бизнесом, выполняются людьми в ИТ вручную (напишите инструмент, чтобы бизнес мог вносить изменения напрямую).
JD
7
@ mm24 В-четвертых, значительное улучшение производительности. F # на порядки быстрее, чем Mathematica, а их контрольный код на F # в 5 раз быстрее, чем их производственный код на C ++. Это означает, что тесты выполняются за секунды, а не за часы, и в этот момент тестирование становится неотъемлемой частью разработки, значительно повышая производительность.
JD
7
@ mm24 В-пятых, расширенные возможности. Они хотят выполнить удаление мертвого кода и измерить охват кода своих тестов, но они не могут сделать это с помощью инструментов, которыми они пользуются. Переход на .NET упростит это (и многое другое!).
JD
13

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

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

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

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

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

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

Дэвид Торнли
источник
3
Мысль о другой продуктивности программиста. По моему опыту, посредственный программист будет в x раз больше времени, чтобы решить заданную проблему, но, к сожалению, он напишет в x раз больше кода при этом. Таким образом, простыми «строками кода в день» посредственный программист становится столь же продуктивным.
Matthias Wandel,
11

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

Джеффри Хайнс
источник
На самом деле. Но по мере того, как проект становится больше, вы будете попадать в этот сценарий чаще. Я написал прекрасные программы из 10 строк, в которых не было ошибок. Все дело в масштабе.
Matthias Wandel,
1
Нет программ, в которых нет ошибок.
Daniel Moura
14
Ба! в вашей грамматике есть ошибки ...
RAL
3
@DanielMoura О, я бы не согласился с этим ... Программа "hello world" может быть не очень полезной, но вы можете довольно уверенно сказать, что в ней нет ошибок :)
WendiKidd
10

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

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

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

альтернативный текст

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

Лично я считаю один LoC в моей оценке производительности только в следующих случаях:

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

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

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

рев. Патрик из команды NDepend
источник
1
Ваш пост является фундаментальным и заслуживает гораздо большего количества голосов.
Скиппи Фастол
9

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

Одна такая метрика сама по себе бесполезна.

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

Всего строк: 252,682 Строки
кода: 127,323
Комментарии: 99,538
Пустые строки: 25,821

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

Я определенно не потратил 29 лет на написание этого кода, поскольку все это C #, а C # существует не так давно.

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

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

Черт возьми нет.

Все зависит.

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

И да, баги будут.

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

Лассе В. Карлсен
источник
Аминь! (плюс пробелы для встречи 15 мин. знаков)
Нейт
Обратите внимание, что эта статистика была рассчитана DPack ( usysware.com/dpack ).
Лассе В. Карлсен
5
Возможно, правило 10 строк в день неприменимо к чему-то меньшему, например к библиотеке классов, которую вы написали (я предполагаю, что это вы сами). Большая часть цифр Брукса получена из крупных проектов (IBM OS360), масштаб которых принципиально отличается от масштаба вашей библиотеки классов. Я предполагаю, что наблюдение Брукса (часто) справедливо для больших проектов, требующих большого количества людей и значительных человеческих коммуникационных сетей, но неверно для небольших проектов.
J. Polfer
6

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

Что означает: например. для проекта Avionic 250-kLOC это 40 (LOC / месяц) / 22 (дней / месяц) == <2LOC / день!

Валентин Хайниц
источник
1
250 строк кода Terra? Что не так с KLoC?
fadedbee 08
4

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

PGS
источник
3

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

Стив Купер
источник
2

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

Лорен Пехтель
источник
1
Помогают небольшие проекты, и одиночки тоже. Сначала я был шокирован, увидев, что мы затронули эту историческую фигуру, хотя бы постепенно. В начале этого проекта моя продуктивность была как минимум в 10 раз выше.
Matthias Wandel
2

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

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

lcabral
источник
1

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

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

annakata
источник
Как тогда описать размер проекта?
Matthias Wandel
1
Если это из «Мифического человеко-месяца», то оно намного старше C. В этой книге Брукс рассмотрел идею о том, что вывод программиста в строках в день довольно постоянен, несмотря на язык, и предположил, что написание на более выразительном языке (меньшее количество строк на единицу функциональности) приведет к повышению продуктивности программистов. Он знал, что это число будет широко варьироваться (его практическое правило гласило, что операционные системы примерно в 9 раз сложнее прикладных программ).
Дэвид Торнли
2
Дискретные единицы кода, точки подключения (то есть взаимодействие единиц), уровни, классы (в ООП) ... существует около миллиона способов. KLOC на самом деле не лучший показатель, кроме как потенциальная единица сложности. (Например, «это заняло 3 недели на отладку, потому что мне пришлось просмотреть 4 KLOC, чтобы найти это!»)
Джон Руди
2
@ Дэвид: Я знаю, откуда это, я могу прочитать вопрос, и прямо сейчас у меня есть упомянутая книга на полке передо мной. Интересно, что первая опубликованная дата также говорит о том, что это пост C на 3 года. Моя точка зрения - явно неудачно сформулированная - заключалась в том, что она архаична и, кроме того, сама концепция бесполезна. Хах! Это действительно по-библейски.
annakata
Ну, у нас было много точек подключения и тому подобное. Но как их вообще считать? Когда что-то становится точкой подключения? Когда имеет значение класс? Размер скомпилированного кода, вероятно, является лучшим показателем для данной системы и языка, но он варьируется в зависимости от системы.
Matthias Wandel,