Міфічний чоловік місяць 10 рядків на день розробника - наскільки близько до великих проектів? [зачинено]

Всі завжди кажуть, що вони можуть перемогти "10 рядків на розробника в день" з "Міфічного місяця людини", і, починаючи проект, я зазвичай можу отримати пару сотень рядків за день.

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

Як роблять інші люди? І з якими вимогами ви стикаєтесь (я думаю, що це фактор)?

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

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

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

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

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

Мені подобається ця цитата:

Якщо ми хочемо порахувати рядки коду, ми не повинні розглядати їх як "створені рядки", а як "витрачені рядки". - Едсгер Дійкстра

Деколи ви робили більше, видаляючи код, ніж додаючи

Вам слід припинити використовувати цей показник, він здебільшого безглуздий. Згуртованість, з'єднання та складність є важливішими показниками, ніж рядки коду.

Як роблять інші люди?

Я є єдиним розробником на повній роботі в нашій компанії і написав 500 000 рядків коду OCaml і F # за останні 7 років, що становить приблизно 200 рядків коду на день. Однак переважна більшість цього коду - приклади підручників, що складаються з сотень окремих проектів, довжиною кілька сотень рядків. Також між OCaml і F # існує багато дублювання. Ми не підтримуємо жодних базових кодових баз більше 50kLOC.

Окрім розробки та підтримки власного програмного забезпечення, я також консультувався з багатьма клієнтами в галузі за останні 7 років. Для першого клієнта я написав 2000 рядків OCaml за 3 місяці, що становить 20 рядків коду на день. Для наступного клієнта ми четверо написали компілятор, який генерував мільйони рядків коду C / C ++ / Python / Java / OCaml, а також документацію за 6 місяців, що складає 2000 рядків коду на день на розробника. Для іншого клієнта я замінив 50kLOC C ++ на 6kLOC F # за 6 місяців, що становить -352 рядки коду на день. Для іншого клієнта я переписую 15kLOC OCaml у F #, який буде однакового розміру, тому 0 рядків коду на день.

Для нашого поточного клієнта я заміню 1600000 рядків коду C ++ та Mathematica на ~ 160kLOC F # за 1 рік (написавши замовити компілятор), який становитиме -6000 рядків коду на день. Це буде моїм найуспішнішим проектом на сьогоднішній день і заощадить нашому клієнту мільйони доларів на рік постійними витратами. Я думаю, кожен повинен прагнути писати -6000 рядків коду на день.

Не перевіряючи фактично мою копію "Міфічного чоловіка-місяця" (усі, хто читає це, дійсно повинні мати копію, доступну), була глава, в якій Брукс розглядав продуктивність за написаними рядками. Цікавим для нього моментом була не фактична кількість рядків, написаних на день, а те, що вона здавалася приблизно однаковою як у асемблері, так і в PL / I (я думаю, що це була мова вищого рівня, що використовується).

Брукс не збирався викидати якусь довільну цифру продуктивності, але він працював над даними про реальні проекти, і, як я пам'ятаю, вони могли становити в середньому 12 рядків на день.

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

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

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

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

Легко отримати пару сотень рядків коду на день. Але спробуйте отримати пару сотень якісних рядків коду на день, і це не так просто. Зверніть увагу, що при налагодженні та перегляді днів з невеликими або відсутніми новими рядками на день, і середній рівень знизиться досить швидко. Я провів тижні налагодження складних питань, а відповідь - 1 або 2 рядки коду.

Було б набагато краще усвідомити, що говорити про фізичні рядки коду досить безглуздо. Кількість фізичних рядків коду (LoC) настільки залежить від стилю кодування, що може змінюватись на порядок від одного розробника до іншого.

У світі .NET є зручний спосіб підрахунку LoC. Точка послідовності . Точка послідовності - це одиниця налагодження, це частина коду, виділена темно-червоним кольором, коли ставиться точка перерви. З точкою послідовності ми можемо говорити про логічний LoC , і цю метрику можна порівняти в різних мовах .NET. Логічний показник коду LoC підтримується більшістю інструментів .NET, включаючи метрику коду VisualStudio, NDepend або NCover.

Наприклад, ось метод 8 LoC (пункти послідовних і кінцевих дужок не враховуються):

Виробництво ЛоК необхідно враховувати в довгостроковій перспективі. Деякі дні ви будете плювати більше 200 LoC, в інші дні ви витратите 8 годин на виправлення помилки, навіть не додаючи жодного LoC. Деякі дні ви будете очищати мертвий код і видалятимете LoC, а деякі дні ви витратите весь свій час на рефакторинг існуючого коду і не додасте жодного нового LoC до загальної кількості.

Особисто я рахую один ЛоК у своєму власному показнику продуктивності лише тоді, коли:

1. Він покривається одиничними тестами
2. він пов'язаний з якимсь кодовим договором (якщо можливо, не всі LoC, звичайно, можуть бути перевірені контрактами).

У такому стані, моя особиста оцінка за останні 5 років, що кодує інструмент NDepend для розробників .NET, становить в середньому 80 фізичних значень на день, не пошкоджуючи жодної середньої якості коду . Ритм підтримується, і я не думаю, що скоро його скоротиться. Загалом, NDepend - це база коду C #, яка на сьогодні важить близько 115 К фізичного ЛоК

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

Немає такого поняття, як срібна куля.

Єдина така метрика сама по собі марна.

Наприклад, у мене є власна бібліотека класів. На даний момент вірна наступна статистика:

Усього рядків: 252.682 Рядки з
кодом: 127.323
Коментарі: 99.538
Порожні рядки: 25.821

Припустимо, я взагалі не пишу коментарів, тобто 127.323 рядки коду. Зважаючи на ваше співвідношення, ця бібліотека коду потребувала б писати приблизно 10610 днів. Це 29 років.

Я, звичайно, не витратив 29 років на написання цього коду, оскільки це все C #, а C # вже не так давно.

Тепер ви можете стверджувати, що код не все так добре, оскільки, очевидно, я повинен був перевершити ваш показник 12 рядків на день, і так, я погоджусь на це, але якщо мені доведеться звести часову шкалу до коли було випущено 1.0 (і я не почав створювати його до виходу 2.0), а це 2002-02-13, приблизно 2600 днів, в середньому - 48 рядків коду на день.

Всі ці рядки коду хороші? Чорт ні. Але до 12 рядків коду на день?

Чорт ні.

Все залежить.

У вас може бути найвищий програміст, який відбиває код у порядку тисяч рядків на день, і середній програміст, який вибиває код у порядку сотень рядків на день, і якість однакова.

І так, будуть помилки.

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

Стів МакКоннелл дає цікаву статистику у своїй книзі "Оцінка програмного забезпечення" (стор. 5.2, таблиця 5.2). Він розрізняє типи проектів (Avionic, Business, Telco тощо) та розмір проекту 10 kLOC, 100 kLOC, 250 kLOC. Номери наведені для кожної комбінації в LOC / StaffMonth. EG Avionic: 200, 50, 40 Інтранет-системи (внутрішні): 4000, 800, 600 Вбудовані системи: 300, 70, 60

Що означає: напр. для проекту Avionic 250-kLOC - 40 (LOC / Місяць) / 22 (Дні / Місяць) == <2LOC / день!

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

Наша база даних становить близько 2,2MLoC за близько 150 людських років зусиль. Це складає близько 75 рядків c ++ або c # на розробника на день, протягом усього життя проекту.

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

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

Підсумок, якщо ви працювали на мене по 2 лінії на годину, вам краще будете отримувати мені багато кави та масажувати мої ноги, щоб вас не звільнили.

Можна підозрювати, що цей багаторічний шматочок цукерки менеджера був винайдений, коли все було додатком sys, написаним на С, оскільки якщо б нічого іншого, магічне число не змінювалося б на порядок, залежно від мови, масштабу та характеру програми. І тоді вам доведеться знижувати коментарі та атрибути. І в кінцевому підсумку кого хвилює кількість написаних рядків коду? Ви повинні закінчити, коли ви досягнете 10K ліній? 100K? Так довільно.

Це марно.