Здравствуйте, 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) время выполнения проекта от числа строк растет экпоненциально(что и так очевидно) ?! В самом деле? Мне вот совсем не очевидно. Не поделитесь соображениями? Почему именно экспоненциально, а, скажем, не полиномиально или линейно?
и кем работаете или чем занимаетесь
кроме программирования еще куча дел поэтому сколько в среднем посчитать сложно.
