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

54

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

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

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

Sevo
источник
25
Производительность это неправильный термин. Этот термин определяется как объем работы, выполненной за период времени, который не связан с созданным кодом.
Фрэнк Хилман
25
Один мудрый человек сказал, что мы должны рассматривать строки кода не как «построенные», а как «потраченные»; в физической инженерии, когда мы учитываем количество деталей и длину спецификации, чем меньше, тем лучше.
pjc50
23
Сравнение разных языков (независимо от того, статические они или динамические) опровергает предположение «внутри одной компании со схожей культурой и сферой деятельности»: различия в языках делают сравнение SLOC бессмысленным.
ограбить
4
Этот метод трагически ошибочен. Даже два разных разработчика в одной и той же компании, использующих одну и ту же среду разработки, часто создают совершенно разные SLOC для реализации одного и того же набора функций.
17 из 26
8
Использование SLOC для измерения производительности имеет такой же смысл, как и использование выбросов, выбрасываемых для измерения пройденного расстояния, когда вам нужно заботиться о топливной экономичности. То, как это правильно, все еще неправильно. Используйте это .
candied_orange

Ответы:

65

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

  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, написанных за месяц.

Арсений Мурзенко
источник
8
Ага. Единственный показатель, которому я доверяю, - это количество заявок (функций, ошибок, исследований и т. Д.), Выполненных за единицу времени. Это зависит от команды (разные команды разбивают билеты с разной степенью детализации), но внутри одной и той же команды или группы команд появится культура, которая сделает размеры билетов достаточно точными (если вы не сравниваете их вне этой культуры)
Slebetman
10
То, что мне нравится больше: «Никогда не полагайтесь только на одну метрику»
Chococroc
30
@slebetman Я завидую точности / согласованности человека, создающего ваши билеты, но мне приходится решать проблемы, начиная от «Исправить написание двух слов» и заканчивая «Добавить функцию X». Метрика билетов для меня даже менее полезна, чем LOC. Сокращение кода класса на 20 LOC, по крайней мере, дает мне представление о проделанной работе. Разрешение 5 билетов может быть часом работы, но может быть и неделей.
Р. Шмитц
3
@ R.Schmitz Это то же самое в моей компании, но каждый билет также имеет связанный размер, поэтому суммирование по размерам билетов будет работать.
Нико Бернс
1
Даже попытки использовать эти метрики имеют проблемы. Что делать, если добавленные функции сложны и сложны в реализации? Или это может быть даже ситуация, когда конкретные функции особенно легко или сложно реализовать для языка, но в целом с языком работать легче / сложнее. Отсутствие производительности также может быть связано с тем, что нынешние сотрудники не знакомы с языком на первых порах. Не следует в первую очередь полагаться на метрики, чтобы определить, какой язык использовать.
Джон Смит
26

О производительности и 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 значительно снизили риски, связанные с динамической типизацией:

Christophe
источник
3
Ваши критические замечания уже были учтены в вопросе: « внутри одной компании, со схожей культурой, сферой деятельности и достаточным количеством данных различия (в отношении уникальных ситуаций и способностей отдельных лиц) достаточно смешиваются, так что метрика SLOC полезна ». Т.е. аргумент был в том, что в этом масштабе все базы кода были бы сопоставимого качества. Хотя лично я сильно сомневаюсь, что это правда.
Амон
Мы используем gitprime ( gitprime.com ) для конкретных измерений, и одна из его функций - отслеживать, сколько раз разработчик переписывает одни и те же строки кода. Поэтому, если вы пишете какой-то код, получаете отчет об ошибке и переписываете код, он фактически измеряет вашу эффективность и сообщает о вашей чистой производительности. Короче говоря, я не думаю, что ваши комментарии являются неотъемлемой проблемой при использовании SLoC в качестве меры производительности. Скорее, я думаю, что ваши жалобы связаны с системами, которые не измеряют SLoC «должным образом».
Конор Манконе
8
@ConorMancone Никому не платят за написание кода. Им платят за создание решений. Аналогия будет измерять плотника по тому, сколько гвоздей и досок он использует. С помощью этой метрики клоун, который обрезает доски и сгибает больше гвоздей, которые он отвезет домой, будет более продуктивным, чем мастер-плотник.
JimmyJames
1
@Christophe Я экспериментировал с измерением результатов производства в качестве основного показателя производительности. Единственная сложность заключается в том, что некоторые вещи могут быть более трудоемкими, чем другие, но из того, что я могу сказать, со временем все стремятся к довольно (статистически) согласованной пропускной способности в зависимости от размера и состава команды. Конечно, многое связано с тем, что атрибуция может быть проблемой, но она является якорем для любого другого измерения производительности разработки.
JimmyJames
2
Несколько лет назад, по крайней мере, в одном магазине по программированию некоторые люди писали логические диаграммы, а другие преобразовывали эти логические диаграммы в скомпилированный код. По сути, в компиляторе этого магазина были человеческие препроцессоры. Было бы справедливо использовать SLoC / month для измерения производительности одного из этих человеческих препроцессоров; это аналогично тому, сколько винтов может установить работник конвейера в отверстия, куда инженеры сказали, что они должны идти. Инженер, который определяет 100 винтов, когда 15 - это то, что требуется для работы, снижает производительность фирмы. (Точно так же, если они указывают 5 винтов!)
Дэвид К
7

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

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

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

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

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

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

cmaster
источник
1
Мне нравится твое последнее предложение.
Питер - Восстановить Монику
1
«статические языки, кажется, требуют большего количества стандартного кода и, следовательно, снижают производительность»: это еще раз показывает, насколько некорректна метрика SLOC. Конечное число строк не учитывает (1) сколько раз нужно было переписать код перед получением окончательного решения (2) сколько дополнительных строк кода в форме модульных тестов требуется (для динамически типизированных языков требуется в среднем больше модульные тесты, чтобы иметь сопоставимую уверенность в правильности производственного кода). Метрика SLOC определенно ошибочна.
Джорджио
6

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

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

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

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

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

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

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

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

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

Конор Манконе
источник
4
Есть и еще одно исключение: поиск ошибок. Поиск ошибок, особенно неприятных, может занять много времени, но обычно приводит к изменению кода.
Натан Меррилл
@NathanMerrill Это хороший момент, хотя он и не так важен для OP: отладка - это отладка на всех языках и (не в моей голове), я не вижу причин, по которым было бы существенно проще или сложнее переходить от одного стека к другому. Это является причиной того, что в целом вы не можете судить о производительности исключительно по написанному коду, больше, чем по любым другим показателям.
Конор Манконе
Мы используем gitprime ( gitprime.com ) в нашей компании, и, как менеджер, так и инженер, я думаю, что это лучшая вещь в мире. Опять же, это только часть картины для нас, но она очень помогла выявить потенциальные проблемы с инженерами задолго до того, как возникла реальная проблема. Прозрачность потрясающая, и все, что они делают, в конечном итоге сводится к SLoC. Принимая во внимание ценность и понимание, которые он добавляет, я всегда очень сомневаюсь в склонности некоторых инженеров отклонять SLoC из-под контроля. Любой может приветствовать их мнение, но оно определенно работает
Конор Манкон
Вопрос заключается в том, можно ли использовать LoC для сравнения инструментов и языков, в контексте того, что старший разработчик сказал, что он показывает более высокую производительность в «статических» языках. Похоже, вы отвечаете на другой вопрос - LoC можно использовать для сравнения разработчиков, но вы все еще согласны, что его нельзя использовать для сравнения языков, поскольку данный разработчик пишет одинаковое количество LoC независимо от инструмента / языка? Вы говорите, что вы противоречите другим ответам здесь, но, кажется, вы согласны?
TessellatingHeckler
Как разработчик я могу думать много раз, когда брал кучу не-СУХОГО кода и заменял его небольшим набором повторно используемых функций. Затем я добавил значительное количество новых функций. Сокращение количества кода при добавлении кратного реальной стоимости - хорошая вещь в моей книге. По моему опыту, лучшие инженеры пишут меньше всего строк кода, а худшие пишут больше всего.
JimmyJames
6

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

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

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

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

Нат
источник
Действительно ... любая метрика, которая препятствует кому-либо удалять избыточный код («у вас был отрицательный показатель SLoC на этой неделе!», Неверна, совершенно неверна!
Эндрю
1

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

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

Фрэнк Хилман
источник
1
Это могло бы быть правильным, если бы мы сравнивали производительность отдельных разработчиков. Вопрос, однако, о сравнении между языками, поэтому контекст очень отличается. Это также означает, например, что меньший код не лучше и не хуже, чем большой; Сравните LOC кода, написанного на Brainfuck, с кодом, написанным, скажем, на Ruby.
Арсений Мурзенко
1
@ArseniMourzenko Помимо шуток, таких как Brainfuck, хорошо разработанные языки фактически сравниваются на основе количества кода, необходимого для решения задачи. Обычно такое сравнение называется выразительностью. Правда, я говорил о LOC на одном языке, а не на разных языках. Производительность обычно определяется как время, необходимое для выполнения задачи; это не специфично для программирования.
Фрэнк Хайлеман
0

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

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

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

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

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

Берин Лорич
источник