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

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

Совершенно справедливо. Но ТС-то хочет мерить именно количеством строк.

ничего. просто один из вариантов ответа.

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

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

Человек, в момент изучения библиотеки, её тестирования и т.п. не является разработчиком ПО. Учащимся - да, но не разработчиком.

Во-первых какая разница? Если ты назовешь курицу тигром, то рычать она от этого не начнет. Человек работающий в сфере разработке ПО постоянно сталкивается с необходимостью непрерывного изучения в ходе работа. Потмоу что постоянно появляется новое железо, новые библиотеки, новые технологии, да в конце концов растут потребности потребителей, изменяются требования. Да даже постоянное желание улучшить продукт и продать его еще раз(или по лучшей цене). Поэтому обучение которое происходит всегда и непрерывно - это абсолютно неотъемлемая часть работы разработчика. А остальное это уже словоблудие: «вот сегодня я разработчик, а завтра так как буду изучать либу ученик!». Зарплата у тебя одна, цель конечная тоже одна.

Разработка ПО - это реализация алгоритмов, отладка и проектирование архитектуры в соответствии с готовыми решениями (паттернами). Всё остальное - это обучение, тестирование, поддержка, менеджмент, computer science, в конце концов, но не разработка ПО. И люди, занимающиеся этим всем не являются разработчиками.

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

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

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

С этим никто не спорил! Я никогда не говорил, что выполнение задач не приводит к написанию строк кода=) Вопрос был в том, что считать количество строк кода в месяц от одного разработчика в месяц - это тупость. Или ты считаешь, то это нормально сказать «для разработчика нормальный результат писать 500 строк в месяц» не уточняя предметную область, сложность алгоритма, требований к масштабированию и модернизации, к перформансу, к реал-тайму? Список этих уточнений может быть настолько велик, что мы можем составить список из 100500 записей различных частных случаяев и для каждого описать «нормальный результат в строчках кода в месяц», а завтра появится еще 9000 особых случаяв(ибо индустрия не стоит на месте) и мы их опять добавил и посчитаем. Вопрос есть ли в этой статистике хоть какой-то смысл? Один и тот же разработчик один месяц работает над одним типом задач, потом над другим. Кол-во кода будет разное. Потому что ЗАДАЧИ БЛ**Ь разные.

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

Вообще возможны еще и другие случаи, когда кол-во кода раздвувают для улучшения читаемости и/или архитектуры(масштабирование, модифицируемость) и это еще один довод почему считать кол-во кода - это тупость. С помощью тул для рефакторинга и/или grep/sed'а можно за час нагенерить/удалить пару сотен строк кода почти «из воздуха»=)

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

Я разве говорил что-то этому противоречащие?=)

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

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

С другой стороны, если рядом с loc будут ещё метрики сложности кода, то уже можно подумать.

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

Ибо одно и тоже loc может занимать банальная трансформация структур и дичайше-сложный алгоритм.

Именно, а с помощью IDE можно вообще избавиться вообще значительно увеличить производительность разработки=)

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

окей.

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

разработчик пишет код?

Разработчик разрабатывает.

Написание кода - это один из инструментов.

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

Разработчик не измеряет свой результат количеством кода.

а когда тебя спрашивают «сколько ты написал строк за сегодя?»

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

окей. а за размерами файлов с сорцами ты следишь?

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

Где я капслуком писал? Я возможно выделял отдельные слова, но историй я им не рассказывал, кончай пи*деть.

Нет, зачем? O_o

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

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

А ты я посмотрю шутник до*уя!

действительно)) бумага - она все стерпит!

Но это вообще не имеет ничего общего с топиком

ты так говоришь, как будто это ты топик создал.

это был сарказм. чини детектор.

уходи с лора)). с максимально возможной скоростью.

С таким уровнем собеседников это более чем разумный выход.

ты так говоришь, как будто это ты топик создал.

Тааак. Мне даже интересно стало, как то что описал я связано с кол-вом строк написанных за единицу времени?

Серьезно, зачем мониторить размер файлов с сорцами?

чтобы один файл исходников не было перегружен кодом

Это на глаз видно. И вообще субъективно. И как это связано с топиком? Я все еще непонимаю=)

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

и сколько строк захватывает твой глаз одновременно?

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

Ты о чем вообще? Нет никаких стандартов сколько файл должен быть по размеру, чувак=)

ты уже все пощитал, алло! пару страниц назад.

Человек работающий в сфере разработке ПО

Необязательно разработчик.

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

Это ни в коем случае не инженерная задача. А тестированием отдел тестирования занимается в приличных организациях.

Во всяком случае с си и си++ это так.

Да, в этом направлении всё очень печально. Культура процесса разработки хромает на обе ноги.

Или ты считаешь, то это нормально сказать «для разработчика нормальный результат писать 500 строк в месяц» не

уточняя предметную область,

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

сложность алгоритма, требований к масштабированию и модернизации, к реал-тайму?

На выходе будет больше строк кода примерно пропорционально

к перформансу

Для этого есть отдел нагрузочного тестирования

ЗАДАЧИ БЛ**Ь разные

Задача одна - прочитать ТЗ и написать соответствующий код. То, что на ТЗ, как правило без слёз не взглянешь, а разработчик вынужден быть «и швец и жнец и на дуде игрец» - вопрос из другой области.

С помощью тул для рефакторинга и/или grep/sed

Или копипасты. Но речь про то, сколько человек пишет кода, а не что сколько ему автоматика генерирует.

и мы их опять добавил и посчитаем

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

а кто говорит о стандартах? есть общепринятые договоренности.

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

Это ни в коем случае не инженерная задача. А тестированием отдел тестирования занимается в приличных организациях.

Отдел тестированием занимается тестирвоанием продукта, а не оценкой подходит ли библиотека/алгоритм/железо под ТЗ, это задача инженера.

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

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

Для этого есть отдел нагрузочного тестирования

В смысле? У тебя есть требования написать алгоритм/код с определенными требованиями по перформансу и реаль-тайму(таймингам в предельных кейсах). Выше я приводил, как пример, алгоритм нахождение обратной матрицы. Очевидно, что найти алгоритм в гугле и закодить его на си сможет и студент, а вот чтобы отвечать требованиям тайминг, что есть обязательная часть ТЗ, это уже совсем другая задача, которая заставляет разработчика запускать тесты и смотреть подходит ли его код под тз или надо продолжать работать.

Что такое портянка - это очевидно субъективно. То что для одного портянка, для другого ей не является.

Это ни в коем случае не инженерная задача.

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

Это прикладная математика.

вот для того чтобы избавиться от субъективизма и договариваются о codestyle, пишут style guide и хотят цифры. у тебя еще много инфантилизма в запасе? а то у меня уже терпение заканчивается азбучные истины тебе разжевывать.

Это мое терпение заканчивается. Тебе весь топик говорят, что все субъективно и зависит от частного случая. А ты говоришь «НЕТНИАТАК!» и приводишь как аргумент, что надов ввести субъективный и персональный критетрий, который зависит от субъективных взглядов людей стоящих у руля КОНКРЕТНОГО проекта.

да и я ни разу не сталкивался с код-стайлом который регламентировал бы кол-во строк кода в ОДНОМ ФАЙЛЕ. Видел когда ограничивают кол-во строк в функции и то обычно это в качестве рекомендации.

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

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

Очевидно, что найти алгоритм в гугле и закодить его на си сможет и студент

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

ты уже все пощитал, алло! пару страниц назад.

Ты то что я примерно помню за 3 последних месяца. То есть ты произвел экстеполяцию трех измерений 1000, 1000, 100 на «нормальный результат». похвальные методы=)

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

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

А как вы ещё реально можете оценить подходит ли вам библиотека/железо под ТЗ без тестирования? Если всё серьёзно, конечно. Как правило, т.е. когда особых требований и специфики нет, разумеется, проще - почитал спеки, погуглил, потрындел на форуме, сверился с погодой на Марсе - сделал выбор.

Цифры дают понятие больше/меньше, т.о. позволяют выбирать лучшие из решений.

В данном случае нет.

Необязательно разработчик.

У меня в трудовой книжке написанно инженер-программист.

С точки зрения внетренего порядка я R&D engineer.

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

А тестированием отдел тестирования занимается в приличных организациях.

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

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

поиск оптимальных алгоритмов, поиск оптимальных либ, оценка либ

Мне и всем моим друзьям таким приходится заниматься 5-6 раз в год, а то и меньше, если специальные вышеописанные люди в организации наличествуют. Не показатель.

кодинг, архитектура

вот это уже и есть разработка

рефакторинг

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