Автор Билл Хардинг на GitClear

Gitclear специализируется на количественной оценке вклада разработчиков. Узнав об этом, мы получаем наиболее частый вопрос, который мы получаем от опытных технических менеджеров, который часто задают из-под нахмуренной брови: «Использует ли ваш инструмент строки кода для оценки работы моего разработчика?» Большинство технических менеджеров, даже те, кто живет и дышит данными / измерениями в качестве предпочтительного средства принятия решений, поначалу опасаются попыток измерить влияние разработчика с помощью строк кода.

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

Когда вы говорите, что строки кода бесполезны, вы правы только на 97%.

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

Борьба, против которой мы ведем? Только то, что практически все строки кода, которые мы обрабатываем, являются «мусорными данными» с точки зрения того, что они не отражают значимую выполняемую работу. Но исследование, которое мы представим ниже, показывает, что, когда вы говорите, что строки кода «бесполезны», вы правы только примерно на 97%.

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

Как подсчет тарелок в ресторане

Общепринятая мудрость подсказывает нам, что можно улучшить бизнес-результаты, улучшив показатели бизнеса. Другими словами, то, что мы выбираем для измерения, - это то, что улучшается. Здесь есть большие возможности, но они сопряжены с не менее большим риском использования зашумленных данных LoC для принятия неверных решений. Чтобы проиллюстрировать, что делает подсчет LoC таким рискованным, рассмотрим эту аналогию:

измерение воздействия на разработчика с помощью строк кода
≡
измерение продуктивности ресторана по количеству использованных тарелок

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

Начнем с хороших новостей для владельцев ресторанов. Если они используют много тарелок, они, вероятно, подают много еды! А если они подают много обедов, они, вероятно, заработали на Yelp прочную репутацию и могут считаться «продуктивными» по нашему определению. Поскольку мы можем отсортировать только тарелки, которые используются для приготовления вкусных блюд, мы можем проанализировать, насколько продуктивным был ваш ресторан с течением времени. Наличие согласованной метрики, такой как «использованные отрегулированные значащие таблички» (скользит у вас на языке), позволяет нам отображать решения (например, специальные мероприятия, предлагаемые Groupon) в немедленную обратную связь. Затем вы повторяете то, что сработало.

Более того, данные, которые мы собираем, могут позволить нам проводить A / B-тестирование новых методов и методологий, чтобы мы постепенно применяли методы, которые максимизируют то, что мы измеряем. В мире кода измерения могут позволить руководству визуализировать, как влияние разработчика определяется такими событиями, как встречи, работа из дома или парное программирование. Хорошие измерения позволяют хорошему руководству уверенно экспериментировать.

В эти метрики, номерные знаки и LoC (вместе «единицы») встроен сигнал . Но надо этого сильно хотеть. Очень плохо. Но действительно этого нужно очень сильно хотеть.

Проблемы с поверхностью

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

Чтобы отделить сигнал от шума, мы должны идентифицировать любые подобные методы и не учитывать используемые ими пластины.

Пример 1. Эта табличка намеренно оставлена ​​пустой.

Условные обозначения определяют шаблоны использования

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

В США принято в модных ресторанах накрывать столы пустыми тарелками. Таблички, использованные для этой конвенции, не позволяют нам делать вывод о продуктивности ресторана.

Точно так же многие строки кода изменяются посредством языка или соглашения о проекте, добавляя много шума. Это такие строки, как: изменение пробелов (изменение слова на слово), пустые строки и ключевые слова на основе языка (начало, {}).

  • Изменения пробелов (изменение слова на слово)
  • Пустые строки (для удобства чтения)
  • Ключевые слова на основе языка (начало, конец, {})

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

Пример 2: Переход от пластины к пластине

"Насколько сильно изменилось" - это не то, что мы надеемся оптимизировать

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

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

В коде разработчики обычно копируют и вставляют строки из одного файла в другой или из одной функции в другую в одном файле. Такая смена производственной линии происходит быстро и практически ничего не говорит нам об объеме производимой работы.

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

Если вы используете службу количественной оценки кода, которая не распознает перемещенные строки, сигнал, содержащийся в ваших измерениях, разбавляется примерно на 15 процентов, средний процент «перемещенных строк» ​​среди всех LoC в репозиториях GitClear.

Пример 3: тарелки, которые вы никогда не видите

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

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

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

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

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

Среди всех LoC, обработанных нами в 2017 году, около 11 процентов строк были «забиты», что означает, что они были заменены или удалены через короткое время после первоначального подтверждения.

Структурные проблемы

Даже когда блюдо на обеих тарелках, это не делает их одинаково вкусными

Второй класс проблем можно считать «структурным» по своей природе. К ним относятся эндемические факторы (например, удачное расположение), которые влияют на скорость использования тарелок независимо от производительности ресторана. В отличие от «проблем с поверхностью», структурные проблемы не меняют количество единиц (пластин или LoC), включенных в наш расчет. Скорее, они подразумевают, что к подсчету единиц следует применять скаляр, чтобы уменьшить влияние нерелевантных внешних эффектов.

Пример 1. Местоположение - это все

Неважно, ресторан ли вы - ресторан или код, - ваше окружение играет важную роль в вашей личности

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

В коде одни языки, естественно, производят больше LoC, чем другие. На таких многословных языках, как HTML и CSS, продукция разработчика будет плодотворной, особенно при внедрении новой функции. Напротив, сжатые языки программирования, такие как Python, Ruby или C #, естественно, будут иметь меньше LoC. PHP, Java и C ++ находятся где-то посередине. GitClear анализирует все эти языки, поэтому для нас важно помочь сделать их «яблоки к яблокам», если смотреть вместе на одном графике.

GitClear позволяет легко настроить Line Impact для разных языков и типов файлов. Менеджеры могут настроить коэффициенты, применяемые нашим алгоритмом обучения, в соответствии с языками и соглашениями, используемыми в проекте. Например, мы обнаружили, что строка CSS оказывает около 40 процентов воздействия как строка, написанная на кратком языке (например, Python, Ruby). Другими словами, мы ожидаем, что разработчик, пишущий CSS, произведет примерно на 40% больше LoC, чем тот же разработчик, пишущий Ruby. Одному Богу известно, сколько они могли сделать на одной строчке Лиспа.

Пример 2: дешевая еда приводит к увеличению количества заказываемых блюд

То, что это дешево, еще не значит, что это хорошо

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

Практически каждый разработчик работал в команде с кем-то, кто создает объемы «дешевых» строк кода. Когда разработчик копирует и вставляет код, он добавляет строки, которые служат определенной цели и выполняют свою работу. Но редко считается, что этот код оказывает положительное влияние. Он повторяет существующий код и становится проблемой, когда его необходимо изменить в будущем. Когда код копируется / вставляется или находится / заменяется, нам нужно уменьшить нашу интерпретацию оказываемого воздействия.

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

Пример 3: чаши на развязке

На небе и на земле больше, чем поместится на вашей тарелке для ужина

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

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

И чтобы вы не думали, что «документация» и «тесты» не являются основными составляющими вашего общего LoC, они всего лишь верхушка айсберга. Учтите: автоматически сгенерированный код, язык, вставленный в файлы представления, и код, добавленный как часть сторонних библиотек. Сложите все неклассические формы LoC, и у вас будет около 70 процентов строк в типичном репо. Мы позволяем вам определять и обнаруживать столько пользовательских типов кода, сколько применимо к вашему проекту.

Подумайте, сколько разных «категорий» кода существует в вашем репо. Есть «классический» код, реализующий функцию. Тогда есть: документация, средства тестирования, сторонние библиотеки и многое другое, о чем мы можем рассказать в коротком рассказе. Около 70 процентов LoC в типичном репо состоит из кода, который не является «классическим». Это должно быть чего-то, но этот идеальный скаляр зависит от категории кода.

Лучшее измерение с помощью Line Impact

Если вы зашли так далеко, то вы узнали основные причины, по которым так сложно использовать LoC для измерения влияния разработчика. Практически все LoC - это «шум» с точки зрения того, отражает ли он долгосрочное влияние на репозиторий кода; это объясняет, почему любая наивная интерпретация LoC будет надежно раздражать искушенных менеджеров. Они понимают, насколько мало традиционные инструменты LoC (или вкладка Github «Insights») соответствуют выполненной значимой работе.

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

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

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

Line Impact - это не производительность

Вы руководитель технических специалистов, который хочет больше узнать о том, как измерить и улучшить результативность вашей команды? Прочтите следующую статью нашей серии, чтобы узнать больше о взаимосвязи между Line Impact и Developer Productivity.

Первоначально опубликовано на www.gitclear.com.