Чи відомі дійсні способи використання SLOC для вимірювання продуктивності?

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

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

Хоча я не думаю, що це твердження підкріплене суворим статистичним аналізом, чи є в галузі деякі докази, які б підтримували цю форму мислення?

Аргумент старшого архітектора може означати дві речі.

1. Це може означати, що середній розробник в компанії виробляє більше рядків коду при використанні статичних мов, ніж при використанні динамічних. Наприклад, якщо п'ятнадцять розробників працюють з Java протягом півроку, вони напишуть 100 KLOC, а якщо ті ж п’ятнадцять розробників працюють з Python протягом півроку, вони напишуть лише 50 KLOC.

   Тут немає кореляції між LOC та продуктивністю. Що робити, якщо для створення такої ж функції, як у Python, потрібно чотири рази більше рядків коду на Java? Якщо це правда, використання Python призвело б до вдвічі більшої продуктивності, грунтуючись на вищезазначених показниках KLOC.

2. Він також може означати, що середній розробник в компанії виробляє менше рядків коду при використанні статичних мов, ніж при використанні динамічних: п'ятнадцять розробників написали б за півроку 100 KLOC на Java, або 200 KLOC в Python.

   Хоча менше рядків коду зазвичай краще (менше коду для запису, читання та обслуговування), все ще незрозуміло, скільки функцій виробляли розробники Java у порівнянні з Python. Може вони написали половину рядків коду порівняно з розробниками Python, але також видали половину кількості функцій?

В обох випадках LOC не є цінною метрикою, оскільки одна і та ж функція не перекладатиметься в однаковій кількості рядків коду на різних мовах . Деякі мови, як правило, більш багатослівні; інші - більш компактні. Хоча в деяких випадках компактність цінна, загальних правил для цього немає. Надзвичайним прикладом може служити мова Brainfuck, яка має надзвичайну компактність, але яка не популярна своєю читабельністю. Порівняння навіть подібних мов може бути складним: наприклад, якщо мова йде про фігурні брекети, Java дотримується стилю K&R, тоді як у C #, відкриваюча фігурна дужка знаходиться у власній лінії в більшості випадків, коли дотримується офіційного стилю, що призводить до штучного збільшення LOC для C #. А що відбувається, коли порівнювати процедурну мову з об'єктно-орієнтованою або з функціональною мовою?

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

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

Про продуктивність та SLOC

Проблема з SLOC

Проблема метрики SLOC полягає в тому, що вона вимірює наближення кількості записаного коду, не враховуючи:

• якість коду (тобто що, якщо на кожні 100 SLOC вам доведеться додати ще 90 SLOC через помилки, але про те, що ви не знаєте на момент доставки вашого коду?)
• цілі, досягнуті за допомогою коду (тобто чи 10K SLOC обробляє всі очікувані випадки використання або історії користувачів? або лише крихітний підмножина?)
• ремонтопридатність коду (тобто вам доведеться додати на 1% або на 50% більше коду для пристосування коду до очікуваних змін, що розвиваються?).

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

Тож SLOC, безумовно, не найкращий спосіб вимірювання продуктивності.

Яку продуктивність ми розглядаємо?

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

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

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

Як виміряти результати програмного забезпечення?

Існує кілька підходів:

• Типовим підходом у класичній інженерії програмного забезпечення є Function Points (FP). Точки функціонування вимірюються виходячи з вимог, які необхідно виконати (наприклад, кількість форм, кількість полів у кожній формі тощо). Потім продуктивність вимірюється у ПП за одиницю часу та на людину. Деякі компанії навіть мають дані, які показують, скільки функціональних точок розробник може виробляти за одиницю часу на даній мові для певного домену. Проблема FP полягає в тому, що вона вимагає дуже детальних вимог наперед і це забирає багато часу.
• Більш сучасний і прагматичний підхід - це сюжетні моменти (СП). Вони використовуються для оцінки складності коду, який повинен бути вироблений, і зазвичай використовуються для оцінки швидкості роботи команд розвитку. Однак СП є оціночним показником роботи, виконаної до того, як будуть відомі всі деталі. Це не остаточний захід того, що насправді сталося. Тому потрібно бути обережним, використовуючи його як міру продуктивності, оскільки це може дати відсіч у процесі оцінки .

Про продуктивність статичного проти динамічного набору тексту

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

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

Чи правильно ваш архітектор?

Можливо, може й ні.

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

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

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

Будь-яке дослідження, яке підтверджує це твердження?

На цю тему існує декілька останніх наукових досліджень. Хоча деякі з них бачать перевагу статичного набору тексту, загалом це обмежується певною метою (документація, повторне використання погано задокументованого коду чи API тощо). Розсудливі формулювання також використовуються, оскільки сучасні IDE значно знизили ризики, пов'язані з динамічним набором тексту:

• Емпіричне порівняння систем статичного та динамічного типу щодо використання API за наявності IDE: Java проти groovy з затемненням , 2014
• Враховуючи ефективність продуктивності декларацій явного типу , 2014 р., Але не є переконливими
• Емпіричне дослідження впливу систем статичного типу на зручність використання бездокументованого програмного забезпечення

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

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

Якщо я записую ці три класи на C, мені потрібно додати зовсім небагато коду: мені потрібно визначити structs для v-таблиць, мені потрібно додати покажчик v-таблиці до базового класу, мені потрібно додати код для конструкторів, щоб фактично встановити покажчики v-таблиці, мені потрібно додати код конструкторам, щоб насправді викликати конструктор базового класу, мені потрібно додати код для явного розподілу пам'яті перед тим, як викликати конструктор (що C ++ newробить за один крок ), так само, мені потрібно відокремити знищення від наступного free()виклику тощо, тощо.

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

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

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

Я буду противником.

Ми відслідковуємо SLoC на своїй роботі (хоча ми не використовуємо її безпосередньо при прийнятті кадрових рішень), і у мене люди заперечують, що більшість людей говорять у своїх відповідях. Насправді, "LoC не має значення, оскільки технологія X дозволяє нам робити більше з меншим кодом" або "Кращі розробники пишуть краще, коротший код, і тому вони не пишуть більше, ніж хто-небудь інший". На мій досвід (хоча я не маю жодних важких цифр для підтвердження цих речей), ці заперечення просто невірні. У свій час я бачив чітке співвідношення як швидкості, так і якості виготовлення коду для наших розробників, порівняно з усіма іншими змістовними вимірами їх загальної "компетентності" як інженера. Наведіть декілька зустрічних прикладів до подібних аргументів, наведених вище:

1. Так, деякі мови можуть зробити більше, якщо менше коду. Насправді у нас є ціла структура, яку ми створили, яка «автоматизує» великі частини розробки для наших конкретних бізнес-проблем (лише бек-енд). Результатом усього цього є не те, що люди пишуть менше коду, а просто в тому, що у нас є більше часу для написання коду. Як результат, в нашій компанії загальна швидкість написання коду є досить постійною в різних технологіях і залежить насамперед від рівня компетентності інженера.
2. Ідея про те, що кращий розробник буде виробляти менше коду, оскільки вони пишуть розумніші, точно не відповідає дійсності. Так, краще розроблена програма може містити менше рядків коду. Однак я особисто виявив, що "кращі" розробники, які пишуть більш ефективний код, не потребують більше часу, щоб планувати його, ніж більш молодий розробник пише речі на довгий шлях. Як результат, старший розробник швидше пройде через завдання кодування та перейде до написання іншого коду з однаковою швидкістю.

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

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

Один виняток

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

Очевидно, що все вище, базується на моєму особистому досвіді. Ваш пробіг може відрізнятися, і явно я в меншості. Не соромтеся погодитися. Підсумовуючи все ж:

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

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

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

1. Вони починають писати набагато довший код, щоб виконувати ту саму функцію
2. вони менше дбатимуть про якість свого коду
3. вони перестануть робити інші речі, які допомагають вашій команді (набір, налагодження, допомога юніорам)
4. вони будуть ненавидіти свою роботу і, ймовірно, пітимуть

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

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

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

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

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

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

Я працював над проектом, де інфраструктура була дуже крихкою, а інструменти застаріли. Проект був побудований на Java із застосуванням програми «Одна сторінка», але розміщений у контейнері портлетів без видимої користі. Час, який знадобився зробити навіть прості зміни, був смішно довгим. Якби ви базували всі свої висновки саме на цьому конкретному проекті, ви можете зробити висновок, що Java погана, або програми для однієї сторінки погані. Ні те неправда. Система, яку повинен був замінити потворний проект, була побудована на C # і WebForms. Коли ми створили діловий випадок, щоб розширити існуючий додаток для задоволення потреб клієнтів, наша продуктивність зросла. Чи означає це, що щільно пов'язаний додаток WebForms є кращим? Можна зробити такий висновок лише для конкретного випадкуі це не поширюється на весь світ. І це має сенс лише тому, що існував додаток із достатньою зрілістю для продовження.

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