Известны ли действительные способы использования SLOC для измерения производительности?

У меня был необычный, краткий разговор с очень старшим архитектором о динамических и статических языках. Он сказал, что данные компании показывают, что есть свидетельства повышения производительности при использовании статических языков. Обратите внимание, это большая компания с большой историей. К моему (и другим) удивлению, он использовал добавленные строки кода.

Он быстро отклонил возражения относительно метрики, сказав, что в одной и той же компании, с одинаковой культурой, сферой деятельности и достаточным количеством данных различия (в отношении уникальных ситуаций и способностей отдельных лиц) достаточно смешиваются, так что метрика SLOC полезна для сравнения производительности инструменты и языки.

Хотя я не думаю, что это утверждение подкреплено строгим статистическим анализом, есть ли в отрасли какие-либо доказательства, которые бы поддерживали такое мышление?

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

1. Это может означать, что средний разработчик в компании создает больше строк кода при использовании статических языков, чем при использовании динамических. Например, если пятнадцать разработчиков работают с Java в течение шести месяцев, они напишут 100 KLOC, и если те же пятнадцать разработчиков будут работать с Python в течение шести месяцев, они будут писать только 50 KLOC.

   Здесь нет корреляции между LOC и производительностью. Что если в Java требуется в четыре раза больше строк кода для создания той же функции, чем в Python? Если это правда, использование Python приведет к удвоению производительности, на основе приведенных выше показателей KLOC.

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

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

В обоих случаях LOC не является ценным показателем, потому что одна и та же функция не будет переводить одинаковое количество строк кода на разных языках . Некоторые языки имеют тенденцию быть более многословными; другие - более компактные. Хотя в некоторых случаях компактность важна, для этого нет общего правила. Экстремальным примером может служить язык Brainfuck, обладающий чрезвычайной компактностью, но непопулярный из-за читабельности. Сравнение даже похожих языков может быть сложным: например, когда дело доходит до фигурных скобок, Java следует стилю K & R, в то время как в C # открывающая фигурная скобка в большинстве случаев стоит на отдельной линии, когда следует официальному стилю, что приводит к искусственному увеличение LOCs для C #. А что происходит, когда сравнивают процедурный язык с объектно-ориентированным или с функциональным языком?

Вместо использования метрики, подверженной ошибкам, старший архитектор мог бы полагаться на группу метрик, которые измеряют производительность при совместном использовании: количество функций, разработанных за месяц, количество ошибок, внесенных в базу кода, и время, потраченное на устранение этих ошибок. эволюция технического долга и т. д. Это сравнение может быть непростым с самого начала, поскольку необходимо учитывать незнакомство команды с новым языком. Как только команда станет достаточно знакомой с ней, выбор должен быть основан на стабильных показателях, а также на большей части на предпочтениях самих членов команды.

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

О производительности и SLOC

Проблема с SLOC

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

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

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

Таким образом, SLOC - определенно не лучший способ измерения производительности.

Какую производительность мы рассматриваем?

Производительность измеряется для процесса. Таким образом, SLOC может быть совершенно достоверным индикатором только для процесса кодирования.

Например, если вы неправильно понимаете неудовлетворительные требования, потратите пять месяцев на создание программного обеспечения, покажите его пользователю, обнаружите, что оно совершенно неверно, и потратите еще пять месяцев, чтобы переписать его с нуля, вы получите ту же производительность в SLOC. / месяц, когда команда пишет код правильно с первого раза, например, потому что она использовала гибкий процесс, который уменьшает недопонимание за счет частой обратной связи. Эта очевидная равная производительность скрывает огромные проблемы.

Таким образом, измерение производительности разработки программного обеспечения должно учитывать весь процесс, включая анализ требований, разработку того, что кодировать, кодирование, тестирование, отладку и проверку того, что ожидания пользователей оправданы. Поскольку все эти действия очень разные, лучше всего измерить единственное, что имеет значение: работающее программное обеспечение, то есть то, что созданное программное обеспечение означает для пользователя .

Как измерить результаты программного обеспечения?

Существует несколько подходов:

• Типичный подход в классической разработке программного обеспечения - это Function Points (FP). Функциональные точки измеряются на основе требований, которые необходимо выполнить (например, количество форм, количество полей в каждой форме и т. Д.). Производительность затем измеряется в FP за единицу времени и на человека. Некоторые компании даже располагают данными, указывающими, сколько функциональных точек может получить разработчик за единицу времени на данном языке для данного домена. Проблема с FP заключается в том, что она требует очень подробных предварительных требований и отнимает много времени.
• Более современный и прагматичный подход - это сюжетные точки (SP). Они используются для оценки сложности создаваемого кода и обычно используются для оценки скорости групп разработчиков. Тем не менее, SP является оценочной мерой для работы, выполненной до того, как станут известны все детали. Это не окончательный показатель того, что на самом деле произошло. Таким образом, необходимо соблюдать осторожность при использовании его в качестве меры производительности, поскольку это может иметь негативные последствия для процесса оценки .

О производительности статической и динамической типизации

Я должен признаться, что лично я поклонник статически типизированных языков, потому что в своем внутреннем я знаю, что это более надежно (годы кодирования доказали мне это).

Итак, одно, что я уверен, это то, что статически типизированный язык способен предотвратить гораздо больше ошибок / ошибок во время компиляции (например, опечатки, несоответствие в ожидаемых типах и т. Д.), Чем не статически типизированные языки. Но при всей объективности я бы не посмел оскорбительно обобщить это как более высокую производительность.

Ваш архитектор прав?

Может быть, а может и нет.

Но его аргументы не кажутся верными: повышение производительности статически типизированного языка происходит от значительного числа ошибок, которые заранее обнаруживаются компилятором.

Следовательно, невозможно обнаружить этот «более высокий» прирост производительности, рассматривая только SLOC, не смотря на переделку, требуемую для динамически типизированных языков. Так что его сравнение не может быть справедливым.

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

Любое исследование в поддержку этого требования?

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

• Эмпирическое сравнение статических и динамических систем типов при использовании API в присутствии IDE: Java и groovy with eclipse , 2014
• Учитывая влияние на производительность явных объявлений типов , 2014, но не окончательно
• Эмпирическое исследование влияния систем статического типа на удобство использования недокументированного программного обеспечения

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

Если я напишу эти три класса на C ++, это довольно просто. Я объявляю классы, использую виртуальные в правильных местах и ​​делаю.

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

Дело в том, что все эти дополнительные вещи довольно бессмысленные. Я могу сделать их очень быстро. Итак, мне не понадобится намного больше времени, чтобы написать версию C, чем мне нужно написать версию C ++. Тем не менее, я произвел гораздо больше строк кода на C, чем на C ++. Настолько, что я буду более продуктивным в С с точки зрения SLOC.

Любой язык, который требует некоторого количества стандартного кода, будет казаться более продуктивным с точки зрения SLOC, чем язык, который не требует такого же количества стандартного кода.

Видите ли, аргумент SLOC настолько фундаментален, что я на самом деле вижу его наоборот: я бы взял утверждение «программисты склонны создавать больше SLOC на статических языках», что означает: «статические языки, похоже, требуют большего шаблонный код, и, следовательно, снизить производительность ".

Я буду противоположным.

Мы отслеживаем SLoC на нашей работе (хотя мы не используем его непосредственно при принятии кадровых решений), и у меня есть люди, которые спорят о том, что большинство людей говорят в своих ответах. По сути, «LoC не имеет значения, потому что технология X позволяет нам делать больше с меньшим количеством кода» или «Лучшие разработчики пишут лучше, более короткий код, и поэтому они не пишут больше, чем кто-либо другой». По моему опыту (хотя у меня нет точных цифр, подтверждающих эти вещи), эти возражения просто не верны. В свое время я видел четкую корреляцию как по скорости, так и по качеству производства кода для наших разработчиков по сравнению со всеми другими значимыми измерениями их общей «компетентности» как инженера. Чтобы привести некоторые контрпримеры к рассуждениям, приведенным выше:

1. Да, некоторые языки могут делать больше с меньшим количеством кода. Фактически, у нас есть целая структура, которую мы создали, которая «автоматизирует» большие части разработки для наших конкретных бизнес-задач (только для серверной части). Результатом всего этого является не то, что люди пишут меньше кода, а просто то, что у нас больше времени для написания кода. В результате в нашей компании общая скорость написания кода довольно постоянна для разных технологий и зависит, прежде всего, от уровня квалификации инженера.
2. Идея, что лучший разработчик будет производить меньше кода, потому что они пишут умнее, определенно не верна. Да, лучше разработанная программа может занимать меньше строк кода. Тем не менее, я лично обнаружил, что «лучшим» разработчикам, пишущим более эффективный код, не нужно больше времени для его планирования, чем более молодым разработчикам, пишущим долгий путь. В результате более опытный разработчик быстрее справится со своими задачами кодирования и перейдет к написанию другого кода с той же высокой скоростью.

Эта последняя часть - мое общее резюме, кстати. Что я обнаружил, так это то, что независимо от технологического стека или типа проекта, большинство разработчиков имеют свой собственный темп, в котором они работают. Если язык обладает множеством функций, которые делают код разработчиков более эффективным, то это является большим благом для бизнеса, но это не означает, что в результате они будут писать меньше кода. Вместо этого они быстрее выполняют функции и переходят к новому коду. Опять же, конечный результат заключается в том, что скорость, с которой они пишут код, зависит в первую очередь от их навыков, а не от их технического стека. Фактически, из-за этого, я бы вообще ожидал, что технический стек будет иметь большее значение для скорости разработки билетов и функций, чем для людей, которые пишут код.

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

Одно исключение

Единственное исключение, с которым я согласен, - это возможность кода котельной плиты. Если происходит много операций копирования и вставки из одного класса (или чего-либо еще) в другой, чтобы его запустить и запустить, то это, очевидно, приведет к искажению показателей. Это также верно, если у вас есть инструменты, которые могут автоматически генерировать для вас большие объемы кода. Однако я думаю, что это часто будет скорее исключением, чем правилом. Если ваши разработчики тратят какое-то время на копирование кода для начала, то вы используете неправильный набор технологий. Если они на самом деле пишут код, даже если он довольно повторяющийся, то я ожидаю, что это приведет к небольшому искажению любых измерений: при написании кода большую часть времени мы ограничены тем, насколько быстро мы можем решить проблему чем как быстро мы можем напечатать. Даже при написании относительно повторяющегося кода,

Очевидно, все вышеизложенное основано на моем личном опыте. Ваш пробег может варьироваться, и, очевидно, я в меньшинстве. Не стесняйтесь не соглашаться. В итоге, хотя:

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

Хотя я прыгаю на подножку. Я думаю, что влияние на поведение программистов должно быть подчеркнуто.

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

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

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

Обычно это не считается правильным способом измерения производительности. Меньший код обычно лучше, чем большой, поэтому более продуктивный разработчик обычно производит меньше кода. Производительность занимает главное место в отладке; эффективные разработчики тратят мало времени на отладку.

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

Единственная метрика, которую можно использовать для сравнения производительности для разработчиков по языкам, - это метрика, которая не сравнивает код между языками. Некоторые языки общеизвестно многословны (COBOL для прежней победы), а другие требуют нескольких шагов, чтобы сделать то, что вы можете сделать в одной строке кода (сборка или почти все остальное). Даже если вы сравниваете только активные строки кода (т.е. не учитываете объявления и учитываете только код, в котором есть какое-то действие), вы все равно можете исказить результаты.

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

На самом деле, сравнивать продуктивность команд / языков бессмысленно, потому что существует так много дополнительных факторов, которые влияют на производительность команды, и из этого нельзя сделать значимые выводы.

Я работал над проектом, в котором инфраструктура была очень хрупкой, а инструменты были устаревшими. Проект был построен на Java с одностраничным приложением, но размещен в контейнере портлета без видимой выгоды. Время, которое потребовалось, чтобы сделать даже простые изменения, было смехотворно долгим. Если бы вы основывали все свои выводы на этом конкретном проекте, вы могли бы заключить, что Java была плохой или одностраничные приложения были плохими. Ни то, ни другое не соответствует действительности. Система, которую должен был заменить уродливый проект, была построена на C # и WebForms. Когда мы сделали экономическое обоснование для расширения существующего приложения для удовлетворения потребностей клиентов, наша производительность взлетела до небес. Означает ли это, что тесно связанное приложение WebForms лучше? Вы можете сделать этот вывод только для этого конкретного случаяи это не распространяется на мир в целом. И это имеет смысл только потому, что существовало приложение с достаточной зрелостью для расширения.

Даже сравнение показателей разрешения элементов в системе отслеживания проблем является ошибочным в том смысле, что вы сравниваете полную инфраструктуру проекта друг с другом. Используемые библиотеки и платформы могут ускорить или замедлить процесс. Возможно, вы находитесь на начальном этапе с очень малой инерцией, которую нужно преодолеть, когда проект, в котором вы «лучше», находится на этапе технического обслуживания, где количество новых заявок относительно мало. Никогда нельзя сравнивать подобные вещи.