- PVSM.RU - https://www.pvsm.ru -

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

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

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

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

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

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

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

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

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

Но как?

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

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

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

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

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

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

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

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

KPI

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

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

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

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

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

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

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

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

Послесловие

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

Автор: SKolotienko

Источник [7]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/bred/125873

Ссылки в тексте:

[1] Количество строк кода: https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F

[2] Насколько более удобным стал продукт: https://en.wikipedia.org/wiki/Usability_testing

[3] Другие различные метрики: https://habrahabr.ru/post/152445/

[4] A/B тестирования: https://en.wikipedia.org/wiki/A/B_testing

[5] нейросети уже умеют генерировать код: http://karpathy.github.io/2015/05/21/rnn-effectiveness/

[6] генетического программирования: https://ru.wikipedia.org/wiki/%D0%93%D0%B5%D0%BD%D0%B5%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

[7] Источник: https://habrahabr.ru/post/302422/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best