LINUX.ORG.RU

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

 , , ,


1

3

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

★★

Сколько осознанных строк ты напишешь за минуту?

Умножь это кол-во на 60. Теперь умножь на 8. Теперь на 21 рабочий день. Теперь подели это значение как минимум на 3, т.к. тебе еще подумать надо, чтобы написать. И теперь можешь делить еще на сколько-то в зависимости от конкретной ситуации и задач.

deep-purple ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

V1KT0P ()
Ответ на: комментарий от anonymous

куда разунее считать прибыль

всем известно, что прибыль приносит только владелец, который милосердно кормит бездельников и дармоедов

anonymous ()

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Как он это делал? В чем секрет? У меня даже близко так не выходит, это не говоря о том что ещё приходится удалять. Сцуко, пора менять профессию :(

anonymous ()

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

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

waker ★★★★★ ()

Не работает такой KPI, хотелось бы конечно автоматизированые метрики, но к сожалению нет. Это все равно что механика оценивать по количеству закрученных гаек. Конечно есть корреляция между количеством кода и продуктивностью разработчика, но при разглашении такого KPI начнутся подтасовки и накручивания до «нормы», и никто кроме специалиста этого не поймет. Про LOC в KPI я не помню, зато помню другой случай, как отличного программера потеряли, человек работал над проектом год, после смены менеджмента никто уже не мог (или не хотел) объяснить руководству и продажникам, что это за штука и над чем собственно работал ведущий девелопер (штука специфичная, ца у которой это компании связанные с финансами). Ему единственному з.п. по итогу года не индексировали и он уволился, через год сейлс разобрался что это и как продавать, продукт стал успешным и начал приносить значимую часть дохода компании. Всем нам прислали поздравление с великолепно написанным продуктом, хех..., думаете его кто-то известил из руководства? Неа! С - справедливость.

Aber ()
Последнее исправление: Aber (всего исправлений: 1)

По 1000 за 8 рабочих часов. На месяц сам помножь. Те кто говорят, что количество строк - плохая метрика - лентяи, сидящие на лоре и других ресурсах в рабочее время.

anonymous ()

Оо, я еще вспомнил случай, не про программирование. Когда мне было 20 лет работал я с каким-то crud, через который забивал данные по технической литературе в базу, делал много, по 50-80 документов в день, но вот делал кучу ошибок, и грамматических, и опечаток, это просекли (много же грамотных, это ведь не в коде разбираться) начали на меня бочку катать, а мне тогда было все пофиг, я почти не менял «стратегию», потом уволился.

Как-то случайно заглянул на старое рабочее место, тот человек который меня отчитывала и показывала «как надо» делать, теперь сидит и занимается тем, чем я занимался - заполняет формы, но заполняет медленно, все проверяет, и у ней получается что-то вроде 10-20 документов в день, и говорит она мне - «как жеж ты быстро все делал, все успевал»,теперь там на неё бочки катили за скорость, мол не эффективная и не продуктивная.

Много лет спустя, что-то подобное я услышал от менеджера проекта: «работал тут студент, он так все быстро делал, продукт овнеры были довольны», небыли довольны только мои коллеги программеры, те что с ним работали, только вот что они понимают в продуктивности? :)

Aber ()
Последнее исправление: Aber (всего исправлений: 3)
Ответ на: комментарий от anonymous

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

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

Aber ()

Пипец темы пошли...

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

Удобное количество строк для чтения кода (ados)

Почему этот бред в Development? Вы чего дебилы?

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

Aber ()
Последнее исправление: Aber (всего исправлений: 1)

Может быть и одна в месяц. Я серьезно. Оценнивать качество работы по строчкам кода может только человек вообще об IT ничего не знающий.

Dudraug ★★★★★ ()
Ответ на: комментарий от Dudraug

Вот простой пример. Один программист пишет пузырьковую сортировку в четырех строках. В итоге все работает медленно. Другой программист убирает эту поделку и делает вызов библиотечного кьюсорта в одну строку. В итоге одна строка добавлена. Четыре удалены. И удаленные строки здесь это брак первого программиста за который он должен нести материальную ответственность. Или другой пример. Программист за месяц не смог добиться 100% точности распознавания обектов с одного набора картинок. Напечатал несколько тысяч строк кода и все твердит о какомто переобучении. Только имитирует деятельность а результата нет. Нанял другого программиста по рекомендации от знакомых. Он за три часа сделал как надо и получил 100% точность. Результат поместился в пятьдесят строк кода. Чем считать предыдущие сотни строк кода от имитатора, если не браком? В итоге его выгнал чтоб неповадно было.

anonymous ()
Ответ на: комментарий от anonymous

И удаленные строки здесь это брак первого программиста за который он должен нести материальную ответственность.

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

Dudraug ★★★★★ ()
Ответ на: комментарий от anonymous

Во-первых твои примеры идиотские, во-вторых они ограниченные. Если не было требования, что сортировка должна отрабатывать за n-единиц времени( тактов процессора), то первый программист тоже сделал свою задачу нормально, другой просто улучшил результат. Это процесс постоянного развития и совершенствования проекта, никогда первоначальный вариант не бывает идеальным. Часто пишут специально код «в лоб», чтобы «просто работало». Делается это для тестирования, ну или для того чтобы система целиком работало нормально, а потом по ходу дорабатывают, оптимизируют. Первоначальный код в данном случае браком не является.

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

Или другой пример. Программист за месяц не смог добиться 100% точности распознавания обектов с одного набора картинок. Напечатал несколько тысяч строк кода и все твердит о какомто переобучении. Только имитирует деятельность а результата нет.

Это твои проблемы, что ты даунов нанимаешь или не умеешь с людьми работать. Кол-во строк кода или постулат «удаленные строчки - брак» тут совершенно не при чем.

Dudraug ★★★★★ ()
Ответ на: комментарий от Dudraug

Производственный брак — продукция, отбираемая на стадии производства, не удовлетворяющая установленным требованиям. Передача такой продукции потребителю не допускается из-за наличия дефектов.

Продукция в нашем случае - строки кода. Удаляются строки не удовлетворяющие установленным требованиям или содержащие дефекты. Т.е. это допущенный написавшим их программистом брак.

anonymous ()
Ответ на: комментарий от anonymous

Продукция в нашем случае - строки кода.

Продукция в данном случае - функционал. При чем тут вообще кол-во строк кода?

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

Dudraug ★★★★★ ()
Ответ на: комментарий от anonymous

Допустим, ты прав. Только где ты найдёшь программистов, готовых нести материальную ответственность, когда в индустрии разработки ПО нести ответственность совсем не принято.

Harald ★★★★★ ()
Ответ на: комментарий от Dudraug

Рефакторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.

То что затрагивает поведение является устранением дефектов или изменением функционала а не рефакторингом.

anonymous ()
Ответ на: комментарий от Harald

Ну вообще в целом принято, но не так как этот субъект описывает. По факту материальная ответственность несется, только если есть материальные последствия (выплата неустоек заказчику, спад продаж). Наказывать людей за баги(да еще до запуска в продакшен) - это финиш. Я знаю парочку таких контор, там работаь никто не хочет и все кто хоть немного превысил уровень джуниров из таких компаний бегут. Там еще и работатодатели ная**вают работников, не платя им премии(ок 50% дохода) по пол года и кормля «завтраками» и «скоропродадимпроект»-ами.

Dudraug ★★★★★ ()