Здравствуйте, evgenius, Вы писали:
E>Вопрос ко всем программерам всех мастей и цветов. E>Сколько строчек кода в среднем в день вы пишите?
E>Просьба указать также, как вы себя оцениваете (в смысле свой профессионализм), только правдиво и кем работаете или чем занимаетесь
LOC уже давно себя дескридитировал. У меня есть несколько проектов с одинаковым LOC в 10.000 срок и с трудоемкостью, отличающейся до 3 раз.
Опят же к примеру при рефакторинге чужого или старого кода количество новых строк порой может быть совсем незначительно. Недавно я потратил 2 дня на написания в общей сложности менее чем 30 строк. Позиция — Senior Java Developer.
Здравствуйте, evgenius, Вы писали:
E>Вопрос ко всем программерам всех мастей и цветов. E>Сколько строчек кода в среднем в день вы пишите?
E>Просьба указать также, как вы себя оцениваете (в смысле свой профессионализм), только правдиво и кем работаете или чем занимаетесь
Это очень неоднозначный вопрос. Задачки то разные бывают. Если что-то несложное и гладко идет за день можно и больше 1000 набить. Или над десятком строчек целый день возиться.
Delphi. Для своих проектов рекорд 800 строк — делал автореферента для IE. 500 строк с 2D графикой.
Нижнего предела нет, бывает, что объем и уменьшается.
Образование прикладная математика, 10 лет с компьютерами, на Dephi пишу лет 5. Должность по Бастракову "Вася П." кроме программирования еще куча дел поэтому сколько в среднем посчитать сложно.
Число строк довольно неудачная метрика. Могу предложить более объективную. Берем массив исходников как можно больше, включая текущий проект. Картинки и весь мусор нужно выбросить. Пакуем rar'ом с флажком "непрерывный архив", смотрим размер архива. Вечером пакуем заново. Смотрим разницу, думаю она всех удивит. Будет, допустим, около 500 бит, это значит за день работы принято около 500 элементарных решений.
Здравствуйте, evgenius, Вы писали:
E>Вопрос ко всем программерам всех мастей и цветов. E>Сколько строчек кода в среднем в день вы пишите?
E>Просьба указать также, как вы себя оцениваете (в смысле свой профессионализм), только правдиво и кем работаете или чем занимаетесь
Ты не слышал о такой штуке CoCoMo. Это такяа штука которая по количеству строк проекта гооврит сколько он времени займет. Для реальных целей мало пригодно т.к. количество строк по началу оценить сложно, если только functional points не считать что геморрой. А вот для таких вещей типа сколько строк писать вполне подходит.
Методика кстати с очень простой идеей и поэтому правильная чуть ли не по определению.
Т.е. весь смысл в следующем
1) время выполнения проекта от числа строк растет экпоненциально(что и так очевидно)
2) У экспоненты коэффициентов 2 штуки — и не надо их считать их можно подобрать по большому количеству реальных проектов.
Больше года назад я в ru.management написал вот такой сообщение.
(Прочитай там есть наша реальная статистика по строкам кода)
Там я обвинил систему, что она неправильно откалибрована. Но с тех пор статистика изменилась чуть сильнее приблизившись к CoCoMo, т.е. скорость разработки ощутимо замедлилась. Мне кажется, что это нормально.
В результате чего я пришел к выводу, что тогда я просто совершил классическую ошибку попутав программу и продукт(см первую главу Брукса, программа и продукт с одинаковой функциональностью требуют для реализации время различающееся в 3 раза).
Сейчас я стал чуть по умнее, понял Брукса, и у меня появилась задумка написать выводы из этой статистики, и я даже начал, но времени не хватает пока. Возможно чуть позже появится в моем LiveJournal.
P.S. Играясь с CoCoMo выбирайте наиболее позднюю версию. Помоему сейчас есть CoCoMo 2000.
P.P.S. Статистику по своему проекту легко получить поделив исходники на затраченное время, а некоторые программы, например CvsStat позволяют по репозитарию рисовать графики зависимости количества строк когда от времени.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Ты не слышал о такой штуке CoCoMo. Это такяа штука которая по количеству строк проекта гооврит сколько он времени займет. Для реальных целей мало пригодно т.к. количество строк по началу оценить сложно, если только functional points не считать что геморрой. А вот для таких вещей типа сколько строк писать вполне подходит.
A>Методика кстати с очень простой идеей и поэтому правильная чуть ли не по определению. A>Т.е. весь смысл в следующем A>1) время выполнения проекта от числа строк растет экпоненциально(что и так очевидно) A>2) У экспоненты коэффициентов 2 штуки — и не надо их считать их можно подобрать по большому количеству реальных проектов.
A>Больше года назад я в ru.management написал вот такой сообщение. A>(Прочитай там есть наша реальная статистика по строкам кода)
A>Там я обвинил систему, что она неправильно откалибрована. Но с тех пор статистика изменилась чуть сильнее приблизившись к CoCoMo, т.е. скорость разработки ощутимо замедлилась. Мне кажется, что это нормально.
A>В результате чего я пришел к выводу, что тогда я просто совершил классическую ошибку попутав программу и продукт(см первую главу Брукса, программа и продукт с одинаковой функциональностью требуют для реализации время различающееся в 3 раза).
A>Сейчас я стал чуть по умнее, понял Брукса, и у меня появилась задумка написать выводы из этой статистики, и я даже начал, но времени не хватает пока. Возможно чуть позже появится в моем LiveJournal.
A>P.S. Играясь с CoCoMo выбирайте наиболее позднюю версию. Помоему сейчас есть CoCoMo 2000. A>P.P.S. Статистику по своему проекту легко получить поделив исходники на затраченное время, а некоторые программы, например CvsStat позволяют по репозитарию рисовать графики зависимости количества строк когда от времени.
[cut]
Зачем же так оверквотить-то.
E>Интересная штучка CoCoMo, надо будет поискать E>з.ы. А как расшифровывается CoCoMo, не знаеш?
Constructive Cost Model
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Методика кстати с очень простой идеей и поэтому правильная чуть ли не по определению. A>Т.е. весь смысл в следующем A>1) время выполнения проекта от числа строк растет экпоненциально(что и так очевидно) A>2) У экспоненты коэффициентов 2 штуки — и не надо их считать их можно подобрать по большому количеству реальных проектов.
У экспоненты только один коэффициент есть характеристика процесса — тот, что в показателе. Второй — это начальное условие, которое процесс не характеризует. Он соответствует показаниям часов в момент когда кол-во строк = 0.
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, EM, Вы писали:
EM>Здравствуйте, Anatolix, Вы писали:
A>>Методика кстати с очень простой идеей и поэтому правильная чуть ли не по определению. A>>Т.е. весь смысл в следующем A>>1) время выполнения проекта от числа строк растет экпоненциально(что и так очевидно) A>>2) У экспоненты коэффициентов 2 штуки — и не надо их считать их можно подобрать по большому количеству реальных проектов.
EM>У экспоненты только один коэффициент есть характеристика процесса — тот, что в показателе. Второй — это начальное условие, которое процесс не характеризует. Он соответствует показаниям часов в момент когда кол-во строк = 0.
f(x)=A*e^(B*x)
А и B коэффициенты.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
EM>>У экспоненты только один коэффициент есть характеристика процесса — тот, что в показателе. Второй — это начальное условие, которое процесс не характеризует. Он соответствует показаниям часов в момент когда кол-во строк = 0.
A>f(x)=A*e^(B*x)
A>А и B коэффициенты.
Ежели ты читал мой пост, то я утверждал, что коэффициент "А" это не характеристика процесса. Это начальное условие. Сам подумай, момент, когда ты часы включил характеризует процесс, который ты собираешься измерять ?
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, EM, Вы писали:
A>>f(x)=A*e^(B*x)
A>>А и B коэффициенты.
EM>Ежели ты читал мой пост, то я утверждал, что коэффициент "А" это не характеристика процесса. Это начальное условие. Сам подумай, момент, когда ты часы включил характеризует процесс, который ты собираешься измерять ?
Ты формулу почитай внимательно. Этот коэффициент(A) характеризует скорость кодирования, коэффициент B характиризует замедление разработки от размера. А то что ты описываешь это третий коэффициент C который здесь не пристствует, ибо занулен. В начальный момент времени количество строк кода считаем расным нулю. Полная формула(для педантов вот такая)
f(x)=A*e^(B*x)+С
И ты говоришь именно о коэффициенте C. Вспоминай математику.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Ты формулу почитай внимательно. Этот коэффициент(A) характеризует скорость кодирования,
Этот коэффициент по размерности равен размерности f(x) (в нашем случае — кол-во строк кода) и скоростью быть не может — это начальное условие — количество строк кода, написанное к моменту, когда t=0
A>коэффициент B характиризует замедление разработки от размера. А то что ты описываешь это третий коэффициент C который здесь не пристствует, ибо занулен. В начальный момент времени количество строк кода считаем расным нулю. Полная формула(для педантов вот такая)
A>f(x)=A*e^(B*x)+С
это ерунда
A>И ты говоришь именно о коэффициенте C. Вспоминай математику.
Ну давай вспоминать математику.
Выводим формулу.
N — кол-во строк кода, t — время.
Здесь N0 — нач условие — количество кода, написаное к моменту t=0. Скорость кодирования описывается одной константой в показателе. (по размерности она = кол-во написанных строк / сек). Именно она и есть единственная характеристика собоственно процесса.
Никаких дополнительных коннстант нет.
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, EM, Вы писали:
EM>Здесь N0 — нач условие — количество кода, написаное к моменту t=0. Скорость кодирования описывается одной константой в показателе. (по размерности она = кол-во написанных строк / сек). Именно она и есть единственная характеристика собоственно процесса. EM>Никаких дополнительных коннстант нет.
Ну во первых то, что ты написал неправильно. Для того чтобы это понять достаточно осмыслить, что перед началом проекта N0 тождествено равно нулю, и по твоей формуле в этом случае ни одна строка в проекте не будет написана.
Во вторых методика CoCoMo оценитвает совсем другую формулу. Там формула не количество строк в день, а количество дней для того чтобы написать требуемое количество строк. Притом именно она экспоненциальная, а формула которую ты считаешь как экпоненциальную она на самом деле логарифмическая. Т.к. рост количества строк замедляется с течением проекта, а не растет до бесконечности.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
EM>>Здесь N0 — нач условие — количество кода, написаное к моменту t=0. Скорость кодирования описывается одной константой в показателе. (по размерности она = кол-во написанных строк / сек). Именно она и есть единственная характеристика собоственно процесса. EM>>Никаких дополнительных коннстант нет.
A>Ну во первых то, что ты написал неправильно. Для того чтобы это понять достаточно осмыслить, что перед началом проекта N0 тождествено равно нулю, и по твоей формуле в этом случае ни одна строка в проекте не будет написана.
A>Во вторых методика CoCoMo оценитвает совсем другую формулу. Там формула не количество строк в день, а количество дней для того чтобы написать требуемое количество строк. Притом именно она экспоненциальная, а формула которую ты считаешь как экпоненциальную она на самом деле логарифмическая. Т.к. рост количества строк замедляется с течением проекта, а не растет до бесконечности.
P.S. И еще если будешь снова начинать на счет формулы про которую я говорил то пойми что "растет экспоненциально" это не означает что вычисляется через функцию exp. Это значит имеет временную сложность O(exp(x)) а ее имеет в частности функци N^M которая и описывает весь процесс и которую можно перезаписать в виде A*exp(B*x).
При этом обрати внимание, что начальные значение A у этой функции уже имеет значение. Т.к. оно вычисляется не от времени t0(которое можно двигать), а от количества строк t0(которое двигать нельзя).
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
I wrote ten lines of code today,
I was more productive than yesterday...
Это с майкрософтовской презентации .NET'а, а смысл в том, что объем набиваемого руками кода сокращается с появлением новых сред разработки, которые берут некоторую часть рутины на себя.
... << Rsdn@Home 1.1.4 beta 1 >>
Re[2]: Опрос: сколько строчек кода в день вы пишите
Здравствуйте, poilk, Вы писали:
P>Здравствуйте, evgenius, Вы писали:
P>
P>I wrote ten lines of code today,
P>I was more productive than yesterday...
P>Это с майкрософтовской презентации .NET'а, а смысл в том, что объем набиваемого руками кода сокращается с появлением новых сред разработки, которые берут некоторую часть рутины на себя.
он сокращается только если все стандартно. шаг влево, шаг вправо и придем к тому же, если не большему, количеству.
лично я пишу от 30 до 1к строчек в день. все зависит от сложности кода
Здравствуйте, evgenius, Вы писали:
E>Вопрос ко всем программерам всех мастей и цветов. E>Сколько строчек кода в среднем в день вы пишите?
E>Просьба указать также, как вы себя оцениваете (в смысле свой профессионализм), только правдиво и кем работаете или чем занимаетесь
очень сильно разница по работе.
недавно сдал 40 страниц английской документации написаной с нуля (не кода) за неделю.
основной костяк проекта был написан за 2 месяца. это около мега ASP кода.
остальное время — можно медленно дебажить по 2-10 строк кода в сутки.
я бы не стал усреднять. скорее можно замерить "предельный обьем осмысленного кода" (того, который будет
правильно работать). такового за день получается 10-15кб. больше — можно, но осмысленным его назвать трудно.
Здравствуйте, evgenius, Вы писали:
E>Вопрос ко всем программерам всех мастей и цветов. E>Сколько строчек кода в среднем в день вы пишите?
По данным Carnegie-Mellon SEI cредняя продуктивность по индустрии колеблется от 20 до 60 строк отлаженного кода в час, в зависимости от:
1) используемого языка
2) характера задач
3) стиля конкретного программиста
4) методики сбора данных
По одному человеку производительность имеет гораздо меньший разброс. У меня примерно 40-45 для С++ для изолированных задач (когда я работаю в одиночку). На груповых проектах продуктивность у всей нашей группы (6 человек) меньше — 20-30 строк кода в час, что соответствует данным по всей нашей компании. Не судите по этой метрике о квалификации программиста — это в большей степени характеристика стиля, чем профессионализма. Например, я специально стараюсь писать код покороче и понятнее, на что трачу дополнительное время. Что произойдет с метрикой продуктивности?
Продуктивность зависит требований к качеству, так как туда входит время на отладку. Но в большей степени продуктивность зависит от методики сбора данных. Сравнивать значения продуктивности надо с осторожностью. Я кратко опишу методику, разработанную Carnegie-Mellon SEI, которая применяется у нас (не то, чтоб она было дико крута, но для примера).
Считаются только строки кода, написанные руками (не сгенерированные автоматически). Комментарии и пустые строки не считаются. Некоторые не считают за строку кода операторные скобки {} (begin — end).
Сюда не входит время на совещания, переговоры, выяснение требований, административную деятельность, ведение переписки, распитие кофе, перекуры и т. д. — только время, непосредственно потраченное на дизайн, кодирование и отладку. Это время меряется прогой-секундомером.
Установлено, что редкий программист способен тратить в среднем больше 4 часов в день на такую активность. Это чревато переутомлением в долгосрочной перспективе с одной стороны, плюс остальное время уходит на прочие выше перечисленные виды деятельности с другой. 4 часа — это хорошо.
Соответственно, считайте. За подробностями — добро пожаловать на сайт Carnegie-Mellon SEI (найдете), там много такого добра.
Здравствуйте, Anatolix, Вы писали:
A>Методика кстати с очень простой идеей и поэтому правильная чуть ли не по определению. A>Т.е. весь смысл в следующем A>1) время выполнения проекта от числа строк растет экпоненциально(что и так очевидно) ?! В самом деле? Мне вот совсем не очевидно. Не поделитесь соображениями? Почему именно экспоненциально, а, скажем, не полиномиально или линейно?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Anatolix, Вы писали:
A>>Методика кстати с очень простой идеей и поэтому правильная чуть ли не по определению. A>>Т.е. весь смысл в следующем A>>1) время выполнения проекта от числа строк растет экпоненциально(что и так очевидно) G>?! В самом деле? Мне вот совсем не очевидно. Не поделитесь соображениями? Почему именно экспоненциально, а, скажем, не полиномиально или линейно?
А это лучше у Barry Boehm, как у автора модели, лучше спросить
Здравствуйте, evgenius, Вы писали:
E>Вопрос ко всем программерам всех мастей и цветов. E>Сколько строчек кода в среднем в день вы пишите?
Я сегодня набил 500 строк (с пустыми строками и комментариями) + чуть меньше 100 с описанием. При том, код прошел с первого после коммита раза все smoke-tests на 2-х компиляторах (О, можно еще Makefile посчитать, но это будет неспортивно.) По науке, если бы я был мега-программистом, в этом коде еще было бы найдено 5 ошибок минимум. В моем случае, видимо, ожидается больше
Но это очень редкий случай. Обычно в день когда не читается очередная спецификация или не идет очередной саппорт очередного бага, пишется не больше 100 строк. Чаще, если не вводятся новые классы, а только расширяется уже намеченный каркас — и того меньше.
Про саппорт я молчу вообще — можно за весь день не написать ничего, а только читать.
Язык C++ (вернее, его подмножество для поддерживаемых компиляторов).
Здравствуйте, evgenius, Вы писали:
E>Вопрос ко всем программерам всех мастей и цветов. E>Сколько строчек кода в среднем в день вы пишите?
хм!
скажу только что я знаю проект где одна строчка в муках рожалась около 4-х мес \правда по причине недостаточности информации от MS, впрочем тогда эта беда многих коснулась, думаю те 4 мес были не самым большим сроком по родам этой строчки у коллег по всему миру\, без нее драйвер был "стабилен", но не более нескольких часов в идеальных условиях.
как оценить эту строчку, если не на вес золота (кстати и подороже-то будет — если посчитать все расходы за 4 месяца-то на супер-профи (спокойно, это был не я ) и как минимум QA team)
E>Просьба указать также, как вы себя оцениваете (в смысле свой профессионализм), только правдиво и кем работаете или чем занимаетесь
речь не обо мне, но могу оценить профессионализм того человека очень высоко, область — та же что и у меня
... << RSDN@Home 1.1.4 @@subversion >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, mikkri, Вы писали:
M>>LOC уже давно себя дескридитировал.
S>А можно аргументацию данного высказывания? Это личное мнение или есть какие-либо публичные источники, утверждающие то же самое?
1. Очень сильно зависит от уровня того, кто этот код пишет — у опытного дувелопера, который понимает, что copy-paste это плохо, этот показатель будет ниже, чем у начинающего.
2. В зависимости от уровня, кто-то напишет код, который решает конкретную текущую задачу, а кто-то при написании кода учтет необходимость его поддержки в дальнейшем и возможные изменения и дополнения.
3. Бывают third-party библиотеки/компоненты, которые приходится использовать из своего кода и количество дополнительного кода, который надо писать чтобы работать с ними может различаться в разы (10 строк, на написания которых уходит 2 часа на изучение документации, те же самые 10 шаблонных строк которые пишутся за 3 минуты или copy-pasted ввиду наличия пред. опыта, 100 строк, которые в 2 клика сгенерит среда разработки), но наличие которых все-же уменьшает к-во строк, которые нужно писать.
Если говорить о публичных источниках, то сам факт наличия COCOMO, которая учитывает степень знакомства с предметной областью, опыт/знание используемых технологий, качество дизайна, уровень разработчиков, некоторые нефункциональные требования и т.д. вполне фвторитетное подтверждение.
"Среднепотолочный коэффициент" пересчета FP в SLOC за последние 3 года уменьшился с 53 до 36, при этом сам язык не изменился, просто добавились/улутшились сопутствующие ему third-party библиотеки (появилясь J2EE).
Моя специфика, но тем не менее.
Из того, что я пишу только около 5% идет в реальную эксплуатацию, все остальное — в мусорку. Просто прмходится много экспериментировать и исследовать. В общем, по итогам года, моя реальная производительность — не более 10 строчек в день плюс около 200-300 в день — в мусорку. Таким образом, удельная стоимость моего реального кода получается 35...40$ за строку. И это нормально. Искренне желаю всем достичь такой же или большей производительности.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Опрос: сколько строчек кода в день вы пишите
Здравствуйте, Spidola, Вы писали:
M>>LOC уже давно себя дескридитировал.
S>А можно аргументацию данного высказывания? Это личное мнение или есть какие-либо публичные источники, утверждающие то же самое?
Во-первых чем опытнее разработчик тем меньше кода он пишет. Опытный разработчик может тратить значительное время на обдумывание кода, и напишет меньше. Однако если считать за некоторый значительный промежуток времени — выясниться, что он написал в 1,5 — 2 раза меньше кода, при том реализовав в 1,2 — 1,5 раз больше функциональности.
Кстати — при этом — в его коде вероятность ошибки может быть в 1,5 — 5 раз ниже, и на отладку его кода потребуется меньше времени (как минимум потому, что код компактнее и проще)
Во-вторых как совершенно справедливо заметил candle645 — одни разработчики тупо и не ээфективно реашют текущую задачу — малейшее изменение — и им может потребоваться на него больше времени чем на решение исходной задачи, а другой — за то же — иногда чуть большее, а иногда меньшее время — решает задачу, причём так что изменения требуют гораздо меньше времени. чем было потрачено сразу. А изменения и ПО — вещи совершенно неотемлемые.
Так же справедливы замечания по поводу библиотек и API.
В большинстве проектов — метод подсчёта количества строк кода — это средняя температура по больнице... Он появился во времена, когда лучшего просто не было, да и продуктивность программистов не различалась в 100 раз. (Т.е. когда не было шаблонов и даже макросов).
И тем не менее — этот метод применим в очень специфическом случае — когда у вас работает толпа тупых кодеров (т.е. тех, кто буквально и пунктуально реализуют готовые выданные им алгоритмы) — притом с одинаковым или очень близким уровнем и отсутсвием стремления к творчеству или саморазвитию. Тогда метод оценки по количеству строк — работает адекватно. НО! Остаётся за рамками вопрос о том, КТО будет выдавать им эти самы "готовые алгоритмы". В общем если вы не Пентагон или не министерство обороны какой-нибудь крупной страны — это не для вас.
Потуги даже довольно крупных коммерческих компаний в данном направлении — могут вызвать только усмешку. Так чаще всего они называют кодерами обычных разработчиков — которым дают весьма расплывчатую формулировку того, что от них хотят — и им надо соображать как это понять и что из этого можно сделать. И к ним применимо всё то, о чем я написал в начале поста...
Здравствуйте, evgenius, Вы писали:
E>Сколько строчек кода в среднем в день вы пишите?
Смотря какой проект. Если знаешь что нужно писать... то пишется быстро. Если же уже нужно думать...то скорость разработки сильно падает. Оценивать труд программиста надо не количеством строк в день, а их качеством. Один может написать 100 строк выполняющую какое-нибудь действие, а другое всего 10 и они более быстрые. Так что здесь лучше?
Best regards, p_kolya. WinAmp сообщает: Тишина — лучшая музыка
и кем работаете или чем занимаетесь
кроме программирования еще куча дел поэтому сколько в среднем посчитать сложно.
) и как минимум QA team) 
