Сколько строк кода в месяц пишут на Си

говнокодить собрался ?

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

2) Есть абсолютный факт - разработчики ошибаются, тебе надо с ним смириться. Выходы тут очень простые - а) хороший отдел тестирования; б) оценивать то насколько брака много, может и правда разработчики и тестеры плохие. Но делать это надо разумно и в каждом случае индивидуально. Концепция «сделал баг - плати» не работает. Главный залог успеха - это стремление к успеху, желание создать лучший проект, а не желание наказывать тех кто не делает все идеально. Команда в которой благобприятный климат работает лучше; в) задуматься о том, а не мудак ли ты? Иногда бывает, что заказчики хотят фантастики «чтоб все работало быстро, четко и вчера!!!» и полностью игнорируют разумные возражения экспертов и команды «сделайте! Я не понимаю, что тут сложного!». Ты видимо из таких.

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

Еще стоит отметить, что подход к оценке качества как к оценке скажем деталей авто не годится. Реалии таковы, что большинство проектов сейчас меняют ТЗ прямо на ходу, практически никто не использует каскадную модель разработки и «фикс прайс» в чистом виде. Это позволяет более гибко контролировать качества продукта, подстраиваться под изменяющиеся реалии, оптимизировать процесс, но это сопряжено с теми же рисками - ошибки при таком подходе просто неизбежны, а наказывать разработчиков за каждый баг - тупость. Если ты не хочешь, чтобы брак попадал клиенту задумайся 1) о том что ты клиенты обещаешь (функционал и сроки) и адекватно ли это возможностями твоей команды и тебя как ее руководителя 2) задумайся, а нормальный ли у тебя контроль качества; 3) нормальный ли ты руководитель? если нанимаешь одних криворуких ушлепков, которые плодят критичные для клиента бага, то может с тобой что-то не так?

как ты себя переосилил это читать?

48654 строчки.

Когда код влияет на создание этих самых деталей - неправильная строчка ведет к «физическому» браку. Как в этом случае прикажешь тестировать код? Симулятор оборудования всегда что-нибудь не учитывает.

Ну и «парни, тут кто-то закоммитил баг на прошлой неделе, вся продукция с конвейера теперь бракована, что делать». И в ответ по твоей логике должно быть «ничего не делать, понять и простить»?

В среднем, 300 в день (отлаженных). От ста (если уперся в поиск ошибки) до 1000 (если однотипный код, к-рый можно копипастить или сгенерить).

И в ответ по твоей логике должно быть «ничего не делать, понять и простить»?

Да. Иначе программер уйдёт к другому, и ты вообще без продукции останешься

Ну и «парни, тут кто-то закоммитил баг на прошлой неделе, вся продукция с конвейера теперь бракована, что делать».

Ну и ССЗБ конечно же, тестировать надо на ограниченной партии, непротестированный софт по дефолту нерабочий

Ну и «парни, тут кто-то закоммитил баг на прошлой неделе, вся продукция с конвейера теперь бракована, что делать».

Ты же понимаешь, что такой ситуации быть не должно. Где отдел качества? Почему это вообще попало в продакшен? Почему у тебя работают программисты которые постоянно косячат. Ты берешь терминальные примеры, ты или работаешь в IT совсем недавно, либо сталкивался только с проектами где все «по старинке», а вообще существует миллион разных кейсов, ситуаций. А ты все пытаешься под одну гребенку, научится рулить проектами по учебнику. Жизнь так не работает, лол.

Ну и ССЗБ конечно же, тестировать надо на ограниченной партии, непротестированный софт по дефолту нерабочий

У него статрап уровня «тяп-ляп и готово», «х*як, х*як и в продакшен», «и так сойдет». Какое тестирование, какие демки, какие прототипы, какой контроль качества, какое пробные партии? Он из людей для которых вопрос «кто виноват?» главный, а современное человечество решает уже вопрос «что делать?»

Ты исповедуешь типичную совковую идеалогию управления через «а кто виноват?», а по хорошему надо бы решать вопрос «а что делать?». Вопрос в том способен ли текущий состав твоих специалистов что-то с этим сделать? Возможно и нет. А может и способен. Наказывать виновных - это не означает решение проблемы. Я считаю штрафные санкции неприемлемы совсем. Увольнение? Да, возможно. Но это уже совсем другая история. Ты увольняешь некомпетентный штат и нанимаешь новый. Это решение проблемы. А наказывать текущий и оставлять его на своих местах. Зачем? Как это решает проблему? Они озлобятся на тебя и будут все делать еще хуже, а ты потеряешь время и еще больше денег. Это же все так очевидно.

вечный косячник детектед

Я считаю штрафные санкции неприемлемы совсем.

отсюда следствие, что отлично выполненная работа тоже не должна вознаграждаться (отсутствие вознаграждения - очевидный штраф)

Когда мне было лет 7 мы на даче общались с соседским чуваком, ему было лет 5 наверное. Так вот он как-то спросил до скольки нас в школе научили считать, а то он уже аж до ста умеет. Пришлось объяснить что как-то в другом дело. Вот твой вопрос и понимание программироваания на том же уровне пятилетнего.

так а до скольки вас в школе научили считать?

Ок, да, я вечный косячник=) На том и закончим.

отсюда следствие, что отлично выполненная работа тоже не должна вознаграждаться (отсутствие вознаграждения - очевидный штраф)

С чего бы? У тебя с пониманием психологии явные проблемы. Если ты будешь за каждый косяк штрафовать от тебя будут или уходить, или ненавидеть и косячить еще больше. А нормальных работников ты на такие проекты не найдешь. Даже если найдешь, то дохода у тебя не будет. Ты не решаешь проблемы, ты лишь штрафуешь.

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

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

Надо задаваться вопросом, сколько хочется получать за час работы, и искать тех, кто согласен платить по вашим хотелкам ). Если речь идет о «fulltime», то туда же входит и время на самообразование и поддержание профессиональной формы. Ну и надо сразу неформально как-то оговаривать, что мол в нормальном режиме кодирую не больше 5-ти часов в день. После авралов обязателен расслабон ) Ну, т.е. связываться надо с адекватными, здравомыслящими людьми.

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

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

если всем премию дали, а тебе нет, то чем это отличается от штрафа?

короче, твоему «рацпредложению» я хода не дам, и можешь называть меня совковым бюрократом

Да мне плевать чему ты ход дашь, а чему нет=)

просто следующий раз думай что пишешь. а то 5 звёзд, а такую пургу несешь

И тебе не хворать;)

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

Можно считать автоматически через методику COCOMO. Для этого есть готовая консольная утилита sloccount.

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

Берем для примера мой OpenSource проект MyTetra. Пишется для себя от случая к случаю одним человеком. Активная разработка года с 2010, то есть 8 лет. Вот что на нем показывает sloccount:

Computing results.

SLOC    Directory       SLOC-by-Language (Sorted)
12385   src_libraries   cpp=12385
7599    src_views       cpp=7599
5559    src_models      cpp=5559
1148    src_controllers cpp=1148
672     src_top_dir     cpp=672
424     doc             php=316,perl=108
47      bin             php=35,xml=12
32      android         xml=32

Totals grouped by language (dominant language first):
cpp:          27363 (98.19%)
php:            351 (1.26%)
perl:           108 (0.39%)
xml:             44 (0.16%)

Total Physical Source Lines of Code (SLOC)                = 27,866
Development Effort Estimate, Person-Years (Person-Months) = 6.58 (78.98)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.10 (13.15)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 6.01
Total Estimated Cost to Develop                           = $ 889,140
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler

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

дело, как наверно многие поняли, не в понимании сути программирования как профессии или даже искусства. а в материализации усилий программиста в глазах малосведущего в теме человека. с известными оговорками, но все же. ну и в оценке «пределов человеческих возможностей».

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

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

Я бы сказал иначе, иногда кол-во строк код - это показатель плохой работы. Хороший код - короткий код. 10 строк лучше, чем 200 делающие тоже самое. Ну и да, ты можешь копаться в доках, спеках, расчетах, тестах, раздумьях месяц, а на выходе будет десяток строк кода. Потому что задача может быть крайне нетривиальна. Оценивать программиста кол-вом строк кода нельзя совершенно. Никогда этого не делай, даже не намекай подчиненым тебе программистам, что качество их труда оценивается в строках кода/коммитах в гите/и.т.д.

Это путь к провалу, инфа 100%.

есть, в месяц писалось 350 строк! Поделим на 22 рабочих дня, получим 15 строк в день.

Ты измеряешь конечное кол-во строк кода, а где же промежуточное, ты же переписывал кучу всего, не?

ты упускаешь некоторые условия из стартового поста.

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

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

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

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

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

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

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

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

Кол-во кода вообще не является метрикой, ВООБЩЕ. Есть только одна метрика - это поставленные задачи и то как они решаются. Есть фича реквест, есть решение. Быстро/медленно/полное решение или нет/может обладает лучшими свойствами или нет/вскрылись ли новые обстоятельства или нет. Забудь о мере эффективности работы в айти по строчкам кода, вообще забудь.

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

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

Ты же понимаешь, что 4000 строк кода, который например реализует парсинг текстовых данных с сохранением их в бд и отправокой простых писем нотификаций с одной стороны, и код который например совершает коррекцию сигнала переданных по радиосвязи в 1000 строк с другой. Что эти задачи несмотря на большее кол-во строк кода в первом совершенно разного калибра задачи. Вторая очевидно на порядок более трудозатратная и сложная(учитывая что с вероятностью 99% это реал-тайм со всеми вытекающии). А ты пытаешься уравнять одну строчку в первом коде к одной строчке во втором.

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

отже ты неугомонный.

Но в итоге выходит что один врач починил за день 10 зубов, но простых, а другой 5 но сложных. Выходит первый врач в 2 раза круче второго?

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

но при этом 10 зубов - по-прежнему 10 вылеченных зубов, а 5 - по-прежнему 5. если у врачей в соседней поликлинике выходит 11 и 6 - это всегда повод задуматься. конкуренция она такая.

Все зависит от задач и другой специфики.

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

при все негативе в отношении оценки работы «по количеству зубов» от нее никуда не денешься.

но при этом 10 зубов - по-прежнему 10 вылеченных зубов, а 5 - по-прежнему 5. если у врачей в соседней поликлинике выходит 11 и 6 - это всегда повод задуматься. конкуренция она такая.

А еще может быть что там где сделали 10 и 5 качественно, а там где 11 и 6 через полгода-год переделывать придется.

Мало кода почти всегда лучше, чем много кода.

может. но в первоначальной оценке отталкиваются все равно от голых цифр.

количество,качество,время - это нормальные критерии? вот представь, что качество одинаково - что остается?

... количество,качество,время - это нормальные критерии?

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

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

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

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

Что такое одинаковое качество?

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

Интересная инфа, спасибо!

ЗЫ За твоим проектом слежу.

Это не имеет смысла. Сторипоинты - это дело командное. Не индивидуальное.

Да и сторипоинты «закроются» тогда, когда все уже будет сделано по фиче(в том числе и проведено тестирование), а это редко делает один человек.

Это не имеет смысла.

Как будто SLOC имеет смысл.

отчёт о разработке ядра линукс за прошлый год https://www.opennet.ru/opennews/art.shtml?num=47443
там производительность по количеству принятых патчей измеряют

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

область применения разработчику достаточно хорошо известна

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

поправь меня еще раз, если я ошибаюсь.

Интересует, сколько (примерно) строк _рабочего_ кода в месяц - нормальный результат для разработчика фуллтайм?

Нормальный результат не считают в строках. Ибо если ты решишь задачу за 20 строк вместо 50, то это будет лучше. А если ещё столько же попутно удалишь — идеально.

Сколько народа недавно спустились с деревьев и не слышали о CoCoMo.

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

видимо качество - это гарантийный срок. в этом контексте должен быть одинаков он.

в программировании качество - это когда поведение программы полностью соответствует ожидаемому.