Представьте себя на месте программиста в компании, которая разрабатывает большой и сложный продукт, которым пользуется большое множество людей. Этот продукт уже много лет на рынке и зарабатывает для компании большое количество денег. Не исключено, что вы уже являетесь таким программистом. С каждым новым циклом разработки вы выпускаете новую версию продукта и надеетесь, что она стала лучше, чем предыдущая. Более того, вы надеетесь, что с каждым новым коммитом продукт, над которым вы работаете, становится лучше и лучше.
Как можно оценить, стала ли новая версия лучше или хуже? Или может быть ваша правка вообще ни на что не повлияла? Ведь в конце концов самое главное, что важно для компании — сколько принесёт денег новая версия продукта?
Есть различные более-менее понятные метрики, с помощью которых можно попробовать измерять то самое «лучше» или «хуже»:
Количество строк кода.- Сколько было исправлено багов.
- Сколько было добавлено новых фич, которые хотят ваши пользователи.
- Насколько производительнее стал продукт.
- Насколько более удобным стал продукт.
- Насколько более качественным стал результат продукта, если для него вообще есть метрика качества (точность классификации, ранжирования и пр.)
- Другие различные метрики.
Но ни одна из них не отвечает на поставленный выше вопрос.
Представьте, что в какой-то день человечество изобретёт такую метрику, которая может измерять финансовый вклад каждого коммита. И тогда вы, например, сможете увидеть в логах репозитория напротив каждой правки число в рублях или другой валюте, означающее сколько данная правка принесла денег компании. Ну или сколько компания потеряла денег.
Этот день будет чёрным днём для всех программистов. Ведь такая метрика — идеальная целевая функция для обучения робота-программиста.
Но как?
Вам
Но вы можете работать в компании, которая разрабатывает какой-либо сайт или мобильное приложение, при этом основной доход — от показов/кликов рекламы. В таком случае уже сложнее оценить вклад конкретной правки. Но можно попробовать оценить сразу целую версию продукта. Например, с помощью A/B тестирования можно оценить, насколько больше кликов рекламы вы получите с новой версией и теперь получить стоимость новой версии в рублях.
Ещё сложнее сделать такую оценку в случае, если вы выпускаете какой-то очень тяжелый десктопный продукт с длинным жизненным циклом каждой версии. Но, чисто теоретически, можно придумать методику, аналогичную A/B тестированию и проверять, какая версия лучше продаётся.
Нам нужно больше генетики
В двух последних случаях, описанных выше, мы получили оценку для целой версии продукта. Но как можно перейти к оценкам конкретных коммитов? Можно придумать сразу несколько способов:
- Делать сборку после каждого коммита и сравнивать две версии «до» и «после» между собой. В таком случае можно определить стоимость правки как разницу между стоимостями версий.
- Взять стабильную версию и попробовать собрать её с каким-то случайным коммитом из development версии. В случае удачной сборки можно аналогично определить стоимость правки, как и в предыдущем пункте. Ещё как вариант — взять development версию и выкинуть какую-нибудь случайную правку.
- Можно вообще брать случайные подмножества правок, пытаться собрать с ними билд и сравнить между собой, либо с какими-то фиксированными версиями. В таком случае можно для определения стоимости конкретной правки взять разницу в стоимостях версий и добавить бонус тем правкам, которые оказались в «выигрышной» версии, и добавить штраф тем правкам, которые оказались в «проигрышной».
- Наконец, можно определить генетический алгоритм, который будет скрещивать и мутировать различные подмножества правок. И определять, какая правка чаще всего приводит к «выигрышам».
Для всех случаев будет множество несобравшихся билдов. В таком случае можно ещё, например, дополнительно добавить штрафы правкам, если они входили в несобравшиеся билды.
А далее уже ничего не мешает пойти ещё дальше и перейти от оценки одного коммита к оценке конкретной строчки кода. Например, разделив стоимость коммита на все входящие в него строчки.
KPI
Теперь можно настроить автоматическую систему, которая будет дописывать к каждому коммиту в вашем репозитории его стоимость. Возможно не сразу, а с какой-то задержкой, необходимой для проведения тестирования.
Таким образом, мы получили мечту менеджера! Открываем лог репозитория и видим, кто из разработчиков сколько принёс денег компании, или на сколько денег навредил. Можем выписывать премии, можем увольнять неудачников. Но ещё круче — построить пирамиду в компании, где каждый сотрудник получает долю от стоимости всех своих правок и правок подчинённых. Да здравствует сетевой маркетинг!
Давайте добавим ещё связи между коммитами и задачами. В таком случае можно будет уже оценивать финансовый эффект от выполнения этих задач. И тогда мы можем добавить в пирамиду не только разработчиков, но и аналитиков и прочих менеджеров. И точно так же ничего не мешает добавить тестировщиков по тому, сколько багов они нашли в наиболее ценных местах кода.
Робот-программист
Предположим, что у кого-то действительно получилось придумать адекватную функцию оценки кода в рублях. Представьте, что произойдёт, если мы начнём применять методы машинного обучения к выборке из исходного кода и целевой переменной — стоимости каждой строчки.
Мы можем обучить классификатор или регрессор, который сможет предсказывать, является ли правка положительной с финансовой стороны и насколько. Можем сделать плагин к вашей любимой IDE, который будет подсвечивать красной волнистой линией строчку, которую вы только что написали и писать вам предупреждение, что «с вероятностью 98.7% с этой правкой вы получите штраф в $42». Или плагин к системе контроля версий, которая будет делать аналогичные предупреждения перед вашими коммитами.
Но, что самое страшное, нейросети уже умеют генерировать код просто посмотрев на исходники. А если добавить такой неройсети ещё и цель — сгенерировать наиболее ценный код, то тогда зачем вообще будут нужны программисты? Конечно, вы можете возразить, что что-то похожее уже пробовали делать с помощью генетического программирования и дело дальше страшилок не пошло. Но с текущими темпами развития в области машинного обучения уже нельзя быть уверенным в том, что за время вашей жизни не появятся роботы-программисты.
Послесловие
Есть надежда, что в «первой волне», когда появятся первые роботы-программисты, они ещё не смогут заменить тех, кто их пишет. Во всяком случае, на первое время. Так что самое время начать изучать машинное обучение. Благо, в интернете полно бесплатных материалов и даже есть немного на русском языке.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (11)
Flammar
02.06.2016 19:37+2Процедура измерения ценности программного продукта — мероприятие длительное, дорогостоящее и склонное выдавать разные результаты в разные моменты времени. Обычно этой процедурой является попытка продать этот самый программный продукт. Если всё сводить к вкладам в деньги компании, то быстро окажется, что деньги приносят только продажники, а программисты совсем не нужны.А через пару-тройку итераций такой оптимизации на программистах продукт вообще перестанет быть интересен покупателям.
Что же касается разбиения стоимости на каждый коммит или строчку кода, да ещё с предсказанием… Здесь слишком велика вероятности ошибки и велика цена ошибки. Создать мотивацию разработчику трудно, сломать же её в десятки раз легче. В итоге мы будем иметь кучу разработчиков, демотивированных случайно по ошибке. Какое при этом может быть качество программного продукта — большой вопрос. И ценность такой системы финансовой оценки каждого коммита и каждой строчки кода окажется глубоко отрицательной.
SKolotienko
02.06.2016 20:25-1Тем не менее, можно представить себе такой продукт, где можно с какой-то точностью оценивать, получилась ли новая версия более успешной или нет и за довольно ограниченное время. Например, замерять показы/клики рекламы с помощью A/B тестирования. Конечно нужно делать всё это аккуратно, чтобы исключить влияние других факторов.
Вообще, конечно, идеальная функция оценки коммита должна уметь заглядывать в будущее. Иначе очень сложно будет проверять эффект от долгосрочных правок типа рефакторинга, чистки кода, документации и пр. Зато представьте, какие открываются перспективы! Ведь с такой функцией оценки можно будет с довольным лицом говорить начальству, что «выделив вот этот код в отдельный метод и переименовав переменные на более понятные имена я сэкономил компании $NN в будущем!»
Ну а про KPI программистов написано много и, насколько я понял, пока ни у кого по-нормальному не удалось этого сделать :)Flammar
03.06.2016 11:12+2«Можно представить», «с какой-то точностью»… всё допущения, допущения, а в итоге какой-то скрипт будет решать, выгнать вас с вашей ипотекой «на мороз» или нет. Программировать вы от этого будете лучше или хуже? Когда потенциальный отрицательный эффект явно больше потенциального положительного, то лучше такую новацию не внедрять.
Вообще, конечно, идеальная функция оценки коммита должна уметь заглядывать в будущее
Даже не идеальная, а минимально пригодная. Причём заглядывать быстро и бесплатно и с воспроизводимым результатом. Само по себе это задача на порядки круче всех остальных ваших желаний из этой статьи. Неосуществимо, а без этого никак.
qw1
05.06.2016 10:49получилась ли новая версия более успешной или нет и за довольно ограниченное время
Прогноз на ограниченное время — большая ошибка. У робота будет цель максимально быстро «прожечь» накопленные резервы, чтобы поднять прибыль в ближайший день, а дальше… извините, прогноз дальше не выполнялся.
Пример ниже в комментариях — «хабр переделать в порносайт». Первые дни ажиотаж будет высоким, а потом сайт забудут.
michael_vostrikov
02.06.2016 19:56+5Какова ценность отдельной точки в красивой фотографии или картине? Какой вклад они вносят? Ведь если убрать один пиксел, то никто ничего не заметит.
Чтобы табуретка стала устойчивой, ей нужно минимум 3 ножки. Какой вклад одной ножки в устойчивость табуретки? Если убрать одну ножку, станет ли она менее устойчивой на треть?SKolotienko
02.06.2016 20:16Конечно, предположение о том, что все правки можно рассматривать независимо друг от друга — неверное. Поэтому первые способы, которые включают/выключают одну правку будут работать плохо. Но если предположить, что проверка стоимости одной сборки может происходить достаточно быстро и таких проверок можно делать много, то можно генерировать кучу сборок с различными подмножествами правок. Далее остаётся задача как перейти от разности в стоимости двух подмножеств правок в стоимость конкретной строчки кода или конкретной правки.
michael_vostrikov
02.06.2016 21:15Так в том-то и дело, что никак. Можно только равномерно размазать разницу в стоимости на разницу в правках. Чем больше мы дробим, тем меньше самостоятельной значимости у каждой из частей.
Arlekcangp
05.06.2016 16:23Совершенно в точку — никак. Метод во что бы то не стало увеличить целевой показатель(в данном случае некую стоимость что бы под этим не подразумевалось) называется локальной оптимизацией — что то оптимизируем здесь и сейчас не взирая на последствия. Еще хуже — часто оптимизируется один показатель так как если показателей несколько — например стоимость и время до релиза то уже совершенно не понятно как их сочетать Обычно мысль «эффективного менеджера» в этом направлении доходит только до «подобрать коэффициенты от балды и складывать (или перемножать ?) с ними целевые показатели. В итоге имеем показатель который не то не другое не отражает.
Второй момент — постановка самой цели Для сужения пространства поиска этой самой оптимальной стоимости задача должна быть поставлена как можно четче. Т. е. варианта 2 — она может быть поставлена формально, а это и есть собственно запрограммировать ее решение или не формально, но тогда робот-программист очевидно должен обладать ИИ в сильном смысле а не просто перебирать варианты — он должен понять постановку задачи, задать уточняющие вопросы, построить модель решения (некий план) и реализовать его в коде. Засада на этапе построения модели и уточняющих вопросов — робот должен думать как человек что бы понять что от него хотят абсолютно четко и не двусмысленно. А таких роботов никогда не будет так как зачем нам еще один человек =)
Suntechnic
02.06.2016 22:44+4Ну придумаете вы такого робота. Ну пустите, его к рефакторингу хабра. И получите утром порносайт…
Shamov
Пока что процесс развивается ровно в обратном направлении. Не роботы начинают работать вместо людей, а люди работают так, как будто они роботы: Google -> Stack Overflow -> Copy & Paste -> Build -> Commit