Comments 11
Пока что процесс развивается ровно в обратном направлении. Не роботы начинают работать вместо людей, а люди работают так, как будто они роботы: Google -> Stack Overflow -> Copy & Paste -> Build -> Commit
Процедура измерения ценности программного продукта — мероприятие длительное, дорогостоящее и склонное выдавать разные результаты в разные моменты времени. Обычно этой процедурой является попытка продать этот самый программный продукт. Если всё сводить к вкладам в деньги компании, то быстро окажется, что деньги приносят только продажники, а программисты совсем не нужны.А через пару-тройку итераций такой оптимизации на программистах продукт вообще перестанет быть интересен покупателям.
Что же касается разбиения стоимости на каждый коммит или строчку кода, да ещё с предсказанием… Здесь слишком велика вероятности ошибки и велика цена ошибки. Создать мотивацию разработчику трудно, сломать же её в десятки раз легче. В итоге мы будем иметь кучу разработчиков, демотивированных случайно по ошибке. Какое при этом может быть качество программного продукта — большой вопрос. И ценность такой системы финансовой оценки каждого коммита и каждой строчки кода окажется глубоко отрицательной.
Что же касается разбиения стоимости на каждый коммит или строчку кода, да ещё с предсказанием… Здесь слишком велика вероятности ошибки и велика цена ошибки. Создать мотивацию разработчику трудно, сломать же её в десятки раз легче. В итоге мы будем иметь кучу разработчиков, демотивированных случайно по ошибке. Какое при этом может быть качество программного продукта — большой вопрос. И ценность такой системы финансовой оценки каждого коммита и каждой строчки кода окажется глубоко отрицательной.
Тем не менее, можно представить себе такой продукт, где можно с какой-то точностью оценивать, получилась ли новая версия более успешной или нет и за довольно ограниченное время. Например, замерять показы/клики рекламы с помощью A/B тестирования. Конечно нужно делать всё это аккуратно, чтобы исключить влияние других факторов.
Вообще, конечно, идеальная функция оценки коммита должна уметь заглядывать в будущее. Иначе очень сложно будет проверять эффект от долгосрочных правок типа рефакторинга, чистки кода, документации и пр. Зато представьте, какие открываются перспективы! Ведь с такой функцией оценки можно будет с довольным лицом говорить начальству, что «выделив вот этот код в отдельный метод и переименовав переменные на более понятные имена я сэкономил компании $NN в будущем!»
Ну а про KPI программистов написано много и, насколько я понял, пока ни у кого по-нормальному не удалось этого сделать :)
Вообще, конечно, идеальная функция оценки коммита должна уметь заглядывать в будущее. Иначе очень сложно будет проверять эффект от долгосрочных правок типа рефакторинга, чистки кода, документации и пр. Зато представьте, какие открываются перспективы! Ведь с такой функцией оценки можно будет с довольным лицом говорить начальству, что «выделив вот этот код в отдельный метод и переименовав переменные на более понятные имена я сэкономил компании $NN в будущем!»
Ну а про KPI программистов написано много и, насколько я понял, пока ни у кого по-нормальному не удалось этого сделать :)
«Можно представить», «с какой-то точностью»… всё допущения, допущения, а в итоге какой-то скрипт будет решать, выгнать вас с вашей ипотекой «на мороз» или нет. Программировать вы от этого будете лучше или хуже? Когда потенциальный отрицательный эффект явно больше потенциального положительного, то лучше такую новацию не внедрять.
Вообще, конечно, идеальная функция оценки коммита должна уметь заглядывать в будущееДаже не идеальная, а минимально пригодная. Причём заглядывать быстро и бесплатно и с воспроизводимым результатом. Само по себе это задача на порядки круче всех остальных ваших желаний из этой статьи. Неосуществимо, а без этого никак.
получилась ли новая версия более успешной или нет и за довольно ограниченное время
Прогноз на ограниченное время — большая ошибка. У робота будет цель максимально быстро «прожечь» накопленные резервы, чтобы поднять прибыль в ближайший день, а дальше… извините, прогноз дальше не выполнялся.
Пример ниже в комментариях — «хабр переделать в порносайт». Первые дни ажиотаж будет высоким, а потом сайт забудут.
Какова ценность отдельной точки в красивой фотографии или картине? Какой вклад они вносят? Ведь если убрать один пиксел, то никто ничего не заметит.
Чтобы табуретка стала устойчивой, ей нужно минимум 3 ножки. Какой вклад одной ножки в устойчивость табуретки? Если убрать одну ножку, станет ли она менее устойчивой на треть?
Чтобы табуретка стала устойчивой, ей нужно минимум 3 ножки. Какой вклад одной ножки в устойчивость табуретки? Если убрать одну ножку, станет ли она менее устойчивой на треть?
Конечно, предположение о том, что все правки можно рассматривать независимо друг от друга — неверное. Поэтому первые способы, которые включают/выключают одну правку будут работать плохо. Но если предположить, что проверка стоимости одной сборки может происходить достаточно быстро и таких проверок можно делать много, то можно генерировать кучу сборок с различными подмножествами правок. Далее остаётся задача как перейти от разности в стоимости двух подмножеств правок в стоимость конкретной строчки кода или конкретной правки.
Так в том-то и дело, что никак. Можно только равномерно размазать разницу в стоимости на разницу в правках. Чем больше мы дробим, тем меньше самостоятельной значимости у каждой из частей.
Совершенно в точку — никак. Метод во что бы то не стало увеличить целевой показатель(в данном случае некую стоимость что бы под этим не подразумевалось) называется локальной оптимизацией — что то оптимизируем здесь и сейчас не взирая на последствия. Еще хуже — часто оптимизируется один показатель так как если показателей несколько — например стоимость и время до релиза то уже совершенно не понятно как их сочетать Обычно мысль «эффективного менеджера» в этом направлении доходит только до «подобрать коэффициенты от балды и складывать (или перемножать ?) с ними целевые показатели. В итоге имеем показатель который не то не другое не отражает.
Второй момент — постановка самой цели Для сужения пространства поиска этой самой оптимальной стоимости задача должна быть поставлена как можно четче. Т. е. варианта 2 — она может быть поставлена формально, а это и есть собственно запрограммировать ее решение или не формально, но тогда робот-программист очевидно должен обладать ИИ в сильном смысле а не просто перебирать варианты — он должен понять постановку задачи, задать уточняющие вопросы, построить модель решения (некий план) и реализовать его в коде. Засада на этапе построения модели и уточняющих вопросов — робот должен думать как человек что бы понять что от него хотят абсолютно четко и не двусмысленно. А таких роботов никогда не будет так как зачем нам еще один человек =)
Второй момент — постановка самой цели Для сужения пространства поиска этой самой оптимальной стоимости задача должна быть поставлена как можно четче. Т. е. варианта 2 — она может быть поставлена формально, а это и есть собственно запрограммировать ее решение или не формально, но тогда робот-программист очевидно должен обладать ИИ в сильном смысле а не просто перебирать варианты — он должен понять постановку задачи, задать уточняющие вопросы, построить модель решения (некий план) и реализовать его в коде. Засада на этапе построения модели и уточняющих вопросов — робот должен думать как человек что бы понять что от него хотят абсолютно четко и не двусмысленно. А таких роботов никогда не будет так как зачем нам еще один человек =)
Ну придумаете вы такого робота. Ну пустите, его к рефакторингу хабра. И получите утром порносайт…
Sign up to leave a comment.
Размышления на тему оценки коммитов и роботов-программистов