Скільки рядків коду може розробляти розробник C # на місяць? [зачинено]

Керівник на моєму робочому місці задав мені та моїй групі розробників питання:

Скільки рядків коду може розробляти розробник C # на місяць?

Стару систему потрібно було перенести на C #, і він би хотів, щоб цей захід був частиною планування проекту.

З якогось (мабуть, достовірного) джерела він мав відповідь "10 SLOC / місяць ", але він не був задоволений цим.

Група погодилася, що це майже неможливо вказати, оскільки це залежатиме від тривалого переліку обставин. Але ми могли б сказати, що чоловік не піде (або сильно розчарується в нас), якби ми не придумали відповідь, яка його краще підходила. Тож він пішов зі значно кращою відповіддю "10 SLOC / день "

Чи можна відповісти на це запитання? (від руки або навіть з деяким аналізом)

Запитайте у виконавця, скільки сторінок договору може писати його адвокат на місяць. Тоді (сподіваємось) він зрозуміє, що величезна різниця між написанням договору на одній сторінці та написанням договору на 300 сторінок без лазівки та суперечностей. Або між написанням нового контракту та зміною існуючого. Або між написанням нового договору та перекладом його на іншу мову. Або до іншої правової системи. Можливо, він навіть погодиться, що "сторінки договорів за одиницю часу" - це не дуже вдалий показник продуктивності юристів.

Але , щоб дати вам деякий відповідь на ваш реальний питання: З мого досвіду, для нового проекту кілька сот SLOC в день і розробник не є рідкістю. Але як тільки з’являться перші помилки, ця кількість різко знизиться.

Скільки рядків коду може розробляти розробник C # на місяць?

Якщо вони хороші, менше нуля.

Бігай іншим шляхом ... Тепер.

LoC - одна з найгірших показників, яку ви можете використовувати.

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

Залежно від складності коду, перенесення може бути здійснено автоматизаційними процесами, що призведе до великих тисяч + зміни LoC в день, тоді як складніші розділи, де мовні конструкції дико відрізняються від коду, переносяться на 100LoC в день.

Надішліть йому, щоб він прочитав сторінку Вікіпедії на SLOC . Якщо наводити кілька приємних і простих прикладів, чому це така погана метрика.

Правильна відповідь: Ні ...

Цей керівник повинен бути освіченим, що SLOC не є дійсною метрикою для прогресу аналізу

Неслухняний відповідь: будь-яке число, яке ви можете скласти.

Просто дайте йому деяку кількість, ви і ваша команда зможете легко змінити це число в будь-якому випадку. (Якщо поставити хіба що рядки, порожні рядки, коментарі тощо тощо), просто для того, щоб цей хлопець продовжував жити у своєму світі фантазій, і переслідувати ще одну команду та продовжувати посилений бідністю цикл, який робить історію до thedailywtf.

Не приємно, але зробити.

З першого погляду це питання виглядає абсолютно нерозумно, і всі тут відповіли лише на тупу частину C # LoC. Але є один важливий нюанс - це питання про портативне виконання. Правильний спосіб задати це питання - запитати, скільки рядків коду вихідного проекту (той, який переноситься) розробник може обробити протягом певної одиниці часу. Це абсолютно виправдане питання, оскільки загальна кількість рядків коду відома, і саме та кількість роботи повинна бути виконана. І правильний спосіб відповісти на це питання - зібрати трохи історичних даних - попрацювати, скажімо, за тиждень, і виміряти продуктивність кожного з розробників.

Я маю сказати лише одне:

"Вимірювання прогресу програмування за допомогою рядків коду подібно вимірюванню прогресу будівництва літака за вагою"

-- Білл Гейтс

Після цього ви можете стверджувати, що Білл Гейтс не знав, як зробити успішне програмне забезпечення;)

Примітка: SLOC - це дуже хороший показник складності кодової бази!

I 
can
write
large
numbers
of
lines
of
code
per
month.

Насправді пропорційна кількості слів.

Ви бачите мою думку?

У мене може бути дещо інша позиція щодо цього, але я думаю, що я можу зрозуміти, чому керівник шукав цю інформацію, якщо вони зараз займаються плануванням проектів. Оскільки важко оцінити, скільки часу триватиме проект, одним із методів, що застосовуються (див. Оцінка програмного забезпечення: Демістифікація чорного мистецтва ), є оцінка того, скільки часу буде тривати проект, виходячи з кількості SLOC в подібних проектах і зараз розробники можуть виробляти в середньому. На практиці це мається на увазі за допомогою історичних записів, які група має під рукою для подібних проектів з тими ж або подібними розробниками.

Однак нічого не варто, що ці оцінки призначені лише для базового планування проектів і насправді не призначені для встановлення темпів розробників на проекті, оскільки все змінюється з дня на день. Таким чином, більшість з того, що ви читаєте про використання SLOC в якості інструменту оцінювання, - це те, що вони є хорошими в довгостроковій перспективі, якщо у вас вже є хороший досвід знань, але вболіва за щоденне використання.

Як правило, називати свого начальника ідіотом погано, тому мої пропозиції починаються з розуміння та обговорення показників, а не відкидання їх.

Деякі люди, які насправді не вважаються ідіотами, використовували метрики, засновані на рядках коду. Фред Брукс, Баррі Бум, Каперс Джонс, Уоттс Хамфріс, Майкл Фаган і Стів МакКоннелл усі ними користувалися. Ви, напевно, використовували їх, навіть якщо просто сказати колезі, що цей модуль Бог складає 4000 рядків, його потрібно розділити на менші класи.

Є конкретні дані, пов'язані з цим питанням, з джерела, яке багато хто з нас поважає.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

Я підозрюю, що найкраще використання рядка коду на годину програміста - це показати, що протягом життя проекту ця величина почне досить високою, але, коли дефекти будуть знайдені та виправлені, будуть додані нові рядки коду для вирішення проблем, які не входили до початкових оцінок, а рядки коду, вилучені для усунення дублювання та підвищення ефективності, покажуть, що LOC / год вказує на інші речі, крім продуктивності.

• Коли код пишеться швидко, неохайно, роздуто і без будь-яких спроб рефакторингу, очевидна ефективність буде найвищою. Мораль тут полягатиме в тому, що ви повинні бути уважними до того, що вимірюєте.
• Для конкретного розробника, якщо вони додають або торкаються великої кількості коду на цьому тижні, на наступному тижні може виникнути технічна заборгованість за оплату в перегляді, тестуванні, налагодженні та переробці.
• Деякі розробники працюватимуть з більш послідовною швидкістю випуску, ніж інші. Може виявити, що вони витрачають найбільше часу на отримання хороших історій користувачів, дуже швидко розвертаються та роблять відповідні тести, а потім розвертаються та швидко роблять код, орієнтований лише на історії користувача. Перевагою тут є те, що методичні розробники, ймовірно, швидко обернуться, напишуть компактний код і матимуть невелику кількість переробку, оскільки вони дуже добре розуміють проблему та рішення, перш ніж вони почнуть кодувати. Здається розумним, що вони будуть кодувати менше, тому що кодують лише після їх продумування, замість до та після.
• Коли код оцінюється за його щільністю дефектів, він виявиться менш однорідним. Деякий код спричинить більшість проблем і дефектів. Це буде кандидат на переписування. Коли це станеться, він стане найдорожчим кодом, оскільки в силу нього високий ступінь переробки. Він матиме найвищі валові рядки підрахунку коду (додаються, видаляються, змінюються, про що можна повідомити з такого інструменту, як CVS або SVN), але найнижчі чисті рядки коду за вкладену годину. Це може бути комбінацією коду або реалізацією найскладнішої проблеми, або найскладнішого рішення.

Незалежно від того, як виходить дискусія щодо продуктивності програміста в рядках коду, ви виявите, що вам потрібно більше чоловічої сили, ніж ви можете собі дозволити, і система ніколи не буде завершена вчасно. Ви справжні інструменти - не показники. Вони використовують вищу методологію, найкращих розробників, яких ви можете найняти або навчити, а також контроль обсягу та ризику (можливо, методами Agile).

Дайте йому кращий показник для роботи

Замість LOC , пояснити це найгірший показник для використання. Тоді дайте йому альтернативу:

Кількість функцій / особливостей на особливості / запити на функції -> NOFF / RFF

Вам може знадобитися додати зважування / нормалізацію поверх NOFF / RFF, щоб задовольнити кількість запитів на тиждень.

:) Очевидно, що вище складено, але все, що краще, ніж SLOC ...

Я можу вам сказати, що велика кількість підрядників для великого проекту написала 15000 LOC (кожен) за рік. Це неймовірно груба відповідь, але вона була нам корисною, оскільки у нас є 400 000 існуючих C ++ LoC, і ми могли зрозуміти, що перетворення все це на C # зайняло б нам близько 26 чоловічих років. Дай або візьми.

Отож, тепер ми знаємо приблизний порядок, ми можемо краще планувати це - отримати 20 дев і оцінити роботу за рік для них все було б правильно. Перш ніж рахувати, ми не мали поняття, скільки часу буде потрібно для міграції.

Тому моя порада для вас - перевірити весь код, який ви написали за певну кількість часу (мені пощастило мати новий проект, з яким можна працювати), а потім запустити один із багатьох інструментів для вимірювання коду на ньому. Розділіть число на час, і ви можете дати йому точну відповідь - скільки LOC ви насправді пишете на день. Для нас це виходило на 90 LOC на день! Я думаю, у нас було багато зустрічей та документації щодо цього проекту, але тоді я думаю, що у нас буде багато зустрічей та документації на наступний :)

Звучить правильно.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Якщо ви враховуєте налагодження, документацію, планування тощо. Це в середньому становить приблизно 10 рядків коду на день. Насправді я би оцінював 10 рядків на день на високій стороні (тобто дуже продуктивній розробці).

Навіть незважаючи на те, що за один день ви зможете викреслити пару сотень рядків (це не стійко). Це не якісний код, поки ви не додасте всю документацію на тестування пристрою і, звичайно, налагоджуєте код після того, як ваш тест приладу покаже помилки. Після всього, що ви зробите, ви повернетесь до 10.

Думаю, розробник, який працює з мовою на зразок C #, повинен мати можливість записувати / генерувати близько 10 КК на день. Я думаю, я міг би це зробити. Я просто ніколи не хотів.

Що ви хочете від розробника, це зробити його роботу за 10 локальних місць на день. Менше коду завжди краще. Я часто починаю виробляти основну частину коду, а потім вирізаю, поки не досягну максимальної простоти, тому в мене справді є дні з негативними ЛоК.

У певному сенсі кодування - це як поезія. Питання не в тому, скільки рядків може написати поет, а в тому, скільки він може передати в 14 рядках сонета.

Нехай ваш керівник впорається з цим, або починайте шукати роботу.

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

З іншого боку, обставини такі, що відповідальний керівник - це ваш інженер та / або керівник проекту. У вас є набагато більші та основні питання, які потрібно вирішити, навіть якщо вони ще не виявили себе. У такому випадку таке питання може послужити "попереджувальним пострілом" для подальших великих проблем.

Інші відповіді правильні, це німе питання, і відповідь не означає прокляту річ. Це все правда, але я випадково знаю, скільки рядків коду я створив приблизно за один місяць.

Це приблизно 3000 рядків коду C # без XML-doc. Я впроваджував нові функції і закінчував цю суму через місяць чи місяць та один тиждень. Це все, що опинилося в контролі джерела, було написано багато коду, а потім відновлено або видалено.

Я розробник C # і намагаюся бути в цьому хорошим, але не можу сказати, наскільки я об’єктивно хороший. Я намагався написати хороший код і доклав чимало зусиль, щоб полегшити його обслуговування. Я вкладаю в цей код лише один раз або два коментарі.

Я не знаю, чим це занадто багато або занадто мало рядків коду, і я повинен сказати, що мені це зовсім не цікаво. Це безглузда частина даних, і її не можна безпечно використовувати для екстраполяції. Але я випадково знаю ці дані, тому вирішив поділитися.

Ну, я трохи запізнююся на цю вечірку, як зазвичай, але це насправді цікаво. Я спочатку мав таку саму думку, як і більшість, що питання виконавчої влади є дрімим. Однак я прочитав відповідь SK-логіки і зрозумів, що це розумне запитання, задане безглуздо. Або, інакше кажучи, за цим питанням стоїть дійсна проблема.

Менеджерам часто потрібно намагатися визначити доцільність, фінансування, штатний розпис тощо для проекту. Це розумна проблема. Для прямолінійного порту оцінка, що базується на рядках коду порту, розділених на передбачувані середні рядки коду на розробника в день, приваблива простота, але приречена на збій з усіх причин, наведених на цій сторінці.

Більш розумним був би підхід:

1. Для оцінки на місці попросіть розробників, які мають найбільше досвіду роботи з кодом, щоб оцінити, скільки часу це займе. Це може бути невірним з багатьох причин, що я сюди не заходжу, але це найкраще, що вони зможуть зробити на самому початку. Принаймні, вони повинні мати уявлення про те, чи буде це легко зробити через тиждень чи роки навіть за рахунок додаткових ресурсів. Якщо були якісь порти подібного розміру або виконані роботи, вони могли б використовувати це як керівництво.
2. Оцініть порт за складовою, щоб отримати загальний розмір. Необхідно включати завдання, не пов'язані безпосередньо з портом, такі як налаштування інфраструктури (машини, побудова систем тощо), дослідження та придбання програмного забезпечення тощо.
3. Визначте найбільш ризиковані компоненти порту та почніть з цих перших. Це, швидше за все, підірве оцінку, тому слід, якщо це можливо, зробити попередньо, щоб у порту були обмежені сюрпризи.
4. Слідкуйте за прогресом щодо розміру, зробленого на кроці 2, щоб постійно обчислювати очікувану тривалість порту. Коли проект рухається вперед, це повинно бути більш точним. Звичайно, кількість перенесених рядків коду (функції в оригінальній кодовій базі, які зараз переносяться в код) також може використовуватися як метрика і фактично корисна для того, щоб оригінальний продукт переносився, а не купу нових цікавих функцій додається, не торкаючись фактичного порту.

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