Размышления на тему оценки коммитов и роботов-программистов

в 13:50, , рубрики: KPI, бред, искусственный интеллект, машинное обучение, ненормальное программирование, Совершенный код

Размышления на тему оценки коммитов и роботов-программистов - 1

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

Как можно оценить, стала ли новая версия лучше или хуже? Или может быть ваша правка вообще ни на что не повлияла? Ведь в конце концов самое главное, что важно для компании — сколько принесёт денег новая версия продукта?

Есть различные более-менее понятные метрики, с помощью которых можно попробовать измерять то самое «лучше» или «хуже»:

  1. Количество строк кода.
  2. Сколько было исправлено багов.
  3. Сколько было добавлено новых фич, которые хотят ваши пользователи.
  4. Насколько производительнее стал продукт.
  5. Насколько более удобным стал продукт.
  6. Насколько более качественным стал результат продукта, если для него вообще есть метрика качества (точность классификации, ранжирования и пр.)
  7. Другие различные метрики.

Но ни одна из них не отвечает на поставленный выше вопрос.

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

Этот день будет чёрным днём для всех программистов. Ведь такая метрика — идеальная целевая функция для обучения робота-программиста.

Но как?

Вам повезло не повезло, если в вашей компании есть естественные способы оценки финансового вклада какой-либо правки. Это может быть, например, точность классификации номеров автомобилей системой, которая фиксирует нарушения и выписывает штрафы. В таком случае вы, зная количество машин и распределение вероятностей различных нарушений, можете оценить, сколько рублей в виде невыплаченных штрафов даёт каждый процент ошибки классификации. Чуть сложнее оценить сколько денег вы потеряете от неверно выписанных штрафов. И вот вы являетесь разработчиком такой системы. У вас есть большая выборка изображений номеров, по которым вы оцениваете точность классификатора. И вы сделали правку, которая подняла полноту классификации с 80% до 90%, при точности 100%. Перемножаем несколько чисел и получаем стоимость вашей правки в рублях.

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

Ещё сложнее сделать такую оценку в случае, если вы выпускаете какой-то очень тяжелый десктопный продукт с длинным жизненным циклом каждой версии. Но, чисто теоретически, можно придумать методику, аналогичную A/B тестированию и проверять, какая версия лучше продаётся.

Нам нужно больше генетики

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

  1. Делать сборку после каждого коммита и сравнивать две версии «до» и «после» между собой. В таком случае можно определить стоимость правки как разницу между стоимостями версий.
  2. Взять стабильную версию и попробовать собрать её с каким-то случайным коммитом из development версии. В случае удачной сборки можно аналогично определить стоимость правки, как и в предыдущем пункте. Ещё как вариант — взять development версию и выкинуть какую-нибудь случайную правку.
  3. Можно вообще брать случайные подмножества правок, пытаться собрать с ними билд и сравнить между собой, либо с какими-то фиксированными версиями. В таком случае можно для определения стоимости конкретной правки взять разницу в стоимостях версий и добавить бонус тем правкам, которые оказались в «выигрышной» версии, и добавить штраф тем правкам, которые оказались в «проигрышной».
  4. Наконец, можно определить генетический алгоритм, который будет скрещивать и мутировать различные подмножества правок. И определять, какая правка чаще всего приводит к «выигрышам».

Для всех случаев будет множество несобравшихся билдов. В таком случае можно ещё, например, дополнительно добавить штрафы правкам, если они входили в несобравшиеся билды.

А далее уже ничего не мешает пойти ещё дальше и перейти от оценки одного коммита к оценке конкретной строчки кода. Например, разделив стоимость коммита на все входящие в него строчки.

KPI

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

Размышления на тему оценки коммитов и роботов-программистов - 2

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

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

Робот-программист

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

Мы можем обучить классификатор или регрессор, который сможет предсказывать, является ли правка положительной с финансовой стороны и насколько. Можем сделать плагин к вашей любимой IDE, который будет подсвечивать красной волнистой линией строчку, которую вы только что написали и писать вам предупреждение, что «с вероятностью 98.7% с этой правкой вы получите штраф в $42». Или плагин к системе контроля версий, которая будет делать аналогичные предупреждения перед вашими коммитами.

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

Послесловие

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

Автор: SKolotienko

Источник

Поделиться новостью

* - обязательные к заполнению поля