Представьте себя на месте программиста в компании, которая разрабатывает большой и сложный продукт, которым пользуется большое множество людей. Этот продукт уже много лет на рынке и зарабатывает для компании большое количество денег. Не исключено, что вы уже являетесь таким программистом. С каждым новым циклом разработки вы выпускаете новую версию продукта и надеетесь, что она стала лучше, чем предыдущая. Более того, вы надеетесь, что с каждым новым коммитом продукт, над которым вы работаете, становится лучше и лучше.
Как можно оценить, стала ли новая версия лучше или хуже? Или может быть ваша правка вообще ни на что не повлияла? Ведь в конце концов самое главное, что важно для компании — сколько принесёт денег новая версия продукта?
Есть различные более-менее понятные метрики, с помощью которых можно попробовать измерять то самое «лучше» или «хуже»:
Количество строк кода.- Сколько было исправлено багов.
- Сколько было добавлено новых фич, которые хотят ваши пользователи.
- Насколько производительнее стал продукт.
- Насколько более удобным стал продукт.
- Насколько более качественным стал результат продукта, если для него вообще есть метрика качества (точность классификации, ранжирования и пр.)
- Другие различные метрики.
Но ни одна из них не отвечает на поставленный выше вопрос.
Представьте, что в какой-то день человечество изобретёт такую метрику, которая может измерять финансовый вклад каждого коммита. И тогда вы, например, сможете увидеть в логах репозитория напротив каждой правки число в рублях или другой валюте, означающее сколько данная правка принесла денег компании. Ну или сколько компания потеряла денег.
Этот день будет чёрным днём для всех программистов. Ведь такая метрика — идеальная целевая функция для обучения робота-программиста.
Но как?
Вам повезло не повезло, если в вашей компании есть естественные способы оценки финансового вклада какой-либо правки. Это может быть, например, точность классификации номеров автомобилей системой, которая фиксирует нарушения и выписывает штрафы. В таком случае вы, зная количество машин и распределение вероятностей различных нарушений, можете оценить, сколько рублей в виде невыплаченных штрафов даёт каждый процент ошибки классификации. Чуть сложнее оценить сколько денег вы потеряете от неверно выписанных штрафов. И вот вы являетесь разработчиком такой системы. У вас есть большая выборка изображений номеров, по которым вы оцениваете точность классификатора. И вы сделали правку, которая подняла полноту классификации с 80% до 90%, при точности 100%. Перемножаем несколько чисел и получаем стоимость вашей правки в рублях.
Но вы можете работать в компании, которая разрабатывает какой-либо сайт или мобильное приложение, при этом основной доход — от показов/кликов рекламы. В таком случае уже сложнее оценить вклад конкретной правки. Но можно попробовать оценить сразу целую версию продукта. Например, с помощью A/B тестирования можно оценить, насколько больше кликов рекламы вы получите с новой версией и теперь получить стоимость новой версии в рублях.
Ещё сложнее сделать такую оценку в случае, если вы выпускаете какой-то очень тяжелый десктопный продукт с длинным жизненным циклом каждой версии. Но, чисто теоретически, можно придумать методику, аналогичную A/B тестированию и проверять, какая версия лучше продаётся.
Нам нужно больше генетики
В двух последних случаях, описанных выше, мы получили оценку для целой версии продукта. Но как можно перейти к оценкам конкретных коммитов? Можно придумать сразу несколько способов:
- Делать сборку после каждого коммита и сравнивать две версии «до» и «после» между собой. В таком случае можно определить стоимость правки как разницу между стоимостями версий.
- Взять стабильную версию и попробовать собрать её с каким-то случайным коммитом из development версии. В случае удачной сборки можно аналогично определить стоимость правки, как и в предыдущем пункте. Ещё как вариант — взять development версию и выкинуть какую-нибудь случайную правку.
- Можно вообще брать случайные подмножества правок, пытаться собрать с ними билд и сравнить между собой, либо с какими-то фиксированными версиями. В таком случае можно для определения стоимости конкретной правки взять разницу в стоимостях версий и добавить бонус тем правкам, которые оказались в «выигрышной» версии, и добавить штраф тем правкам, которые оказались в «проигрышной».
- Наконец, можно определить генетический алгоритм, который будет скрещивать и мутировать различные подмножества правок. И определять, какая правка чаще всего приводит к «выигрышам».
Для всех случаев будет множество несобравшихся билдов. В таком случае можно ещё, например, дополнительно добавить штрафы правкам, если они входили в несобравшиеся билды.
А далее уже ничего не мешает пойти ещё дальше и перейти от оценки одного коммита к оценке конкретной строчки кода. Например, разделив стоимость коммита на все входящие в него строчки.
KPI
Теперь можно настроить автоматическую систему, которая будет дописывать к каждому коммиту в вашем репозитории его стоимость. Возможно не сразу, а с какой-то задержкой, необходимой для проведения тестирования.
Таким образом, мы получили мечту менеджера! Открываем лог репозитория и видим, кто из разработчиков сколько принёс денег компании, или на сколько денег навредил. Можем выписывать премии, можем увольнять неудачников. Но ещё круче — построить пирамиду в компании, где каждый сотрудник получает долю от стоимости всех своих правок и правок подчинённых. Да здравствует сетевой маркетинг!
Давайте добавим ещё связи между коммитами и задачами. В таком случае можно будет уже оценивать финансовый эффект от выполнения этих задач. И тогда мы можем добавить в пирамиду не только разработчиков, но и аналитиков и прочих менеджеров. И точно так же ничего не мешает добавить тестировщиков по тому, сколько багов они нашли в наиболее ценных местах кода.
Робот-программист
Предположим, что у кого-то действительно получилось придумать адекватную функцию оценки кода в рублях. Представьте, что произойдёт, если мы начнём применять методы машинного обучения к выборке из исходного кода и целевой переменной — стоимости каждой строчки.
Мы можем обучить классификатор или регрессор, который сможет предсказывать, является ли правка положительной с финансовой стороны и насколько. Можем сделать плагин к вашей любимой IDE, который будет подсвечивать красной волнистой линией строчку, которую вы только что написали и писать вам предупреждение, что «с вероятностью 98.7% с этой правкой вы получите штраф в $42». Или плагин к системе контроля версий, которая будет делать аналогичные предупреждения перед вашими коммитами.
Но, что самое страшное, нейросети уже умеют генерировать код просто посмотрев на исходники. А если добавить такой неройсети ещё и цель — сгенерировать наиболее ценный код, то тогда зачем вообще будут нужны программисты? Конечно, вы можете возразить, что что-то похожее уже пробовали делать с помощью генетического программирования и дело дальше страшилок не пошло. Но с текущими темпами развития в области машинного обучения уже нельзя быть уверенным в том, что за время вашей жизни не появятся роботы-программисты.
Послесловие
Есть надежда, что в «первой волне», когда появятся первые роботы-программисты, они ещё не смогут заменить тех, кто их пишет. Во всяком случае, на первое время. Так что самое время начать изучать машинное обучение. Благо, в интернете полно бесплатных материалов и даже есть немного на русском языке.
Автор: SKolotienko
