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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я единственный разработчик в нашей компании, работающий на полную ставку, и за последние 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 строк кода в день.

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

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

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

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

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

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

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

Было бы гораздо лучше понять, что говорить о физических строках кода бессмысленно. Количество физических строк кода (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 и время, необходимое мне, чтобы доставить ее в производство.

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

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

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

Всего строк: 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 строк кода в день?

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

Все зависит.

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

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

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

Стив МакКоннелл приводит интересную статистику в своей книге «Оценка программного обеспечения» (стр. 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 / день!

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

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

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

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

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

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

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