Machine Learning: сила данных

41 комментарий
Machine Learning: сила данных
bender Не так давно в списке вакансий одной белорусской компании, чьё название обычно пишется в виде HTML-тега, висела вакансия лингвиста. Зачем софтверной компании лингвист? Ответ можно найти в одном из пунктов требований – для “opinion mining” (“добыча мнений”, “извлечение мнений”, хотя сама компания переводит этот термин как “сентиментный анализ”, подразумевая, видимо, другое распространённое название этой задачи – “sentiment analysis”, дословно “анализ настроений”). Грубо говоря, извлечение мнений – это определение отношения говорящего к предмету разговора. Используется, например, для мониторинга репутации продуктов компании, оценки политических явлений и даже для предсказания индекса Dow Jones. Об извлечении мнений я обязательно напишу отдельную развёрнутую статью, но сначала расскажу про более общую область, на которой и основан opinion mining, а именно про машинное обучение. Можно сказать, что машинное обучение (machine learning) – это набор алгоритмов и методов, позволяющих вычислительной машине делать предсказания на основании предыдущего опыта, такого как статистические данные. Так, например, GMail собирает спам сообщения, помеченные пользователями, и на их основе строит классификатор, позволяющий определять, является ли спамом новое письмо. Другой пример иcпользования ML компанией Google – ранжирование результатов поиска. На основании статистики от пользователей или экспертов строится линейная модель (уравнение вида y = w0 + w1x1 + w2x2 + ... + wnxn, где w1…wn – веса, а x1…xn – признаки объекта), показывающая, какой вклад в итоговый рейтинг страницы вносят различные показатели, такие как количество ссылок с других страниц, количество ключевых слов в названии, тексте и ссылке, индекс tf*idf и т.д. При этом результатом обучения является не просто программа, способная сортировать результаты, но понятная человеку формула. То есть с помощью машинного обучения из “сырых” данных можно получить новую полезную информацию. В таких случаях вместо названия “машинное обучение” обычно используют другое – “извлечение данных” (data mining). Извлечение данных активно используется аналитиками для оптимизации процессов в своих областях. Например, изучение ассоциативных правил (см. ниже) может помочь выяснить, какие товары чаще всего покупают вместе, и разместить их в магазине соответствующим образом. Однако этот блог в первую очередь для технарей, а не для аналитиков, поэтому в дальнейшем я буду говорить в основном про машинное обучение, а случаи, когда алгоритм или метод может быть применён для извлечения данных, буду оговаривать специально. Иногда машинное обучение можно обнаружить в самых необычных местах. Так, например, не многие знают, что современные виртуальные машины, такие как CLR или JVM, используют его для оптимизации скомпилированного кода. Например, наиболее распространённая реализация JVM – Oracle HotSpot – постоянно следит за производительностью кода и собирает статистику. Как только статистики оказывается достаточно, чтобы принять решение об оптимизации, код перестраивается и улучшается. Отсюда следует ещё одно определение ML: машинное обучение – это научная дисциплина, занимающаяся созданием алгоритмов, позволяющим вычислительной машине улучшать свою производительность на основании эмпирических данных. При этом под производительностью понимается процентное количество правильно обработанных образцов, например, правильно угаданных ветвей выполнения программы. Всё это хорошо, но довольно абстрактно. Как же процесс машинного обучения происходит на практике? Ниже я опишу, как представляются входные и выходные данные, а также как происходит решение наиболее распространённых задач машинного обучения.

Представление данных

Хотя существует довольно много моделей представления объектов в машинном обучении, наибольшее распространение получила так называемая модель пространства признаков. В ней каждый объект представляется в виде набора пар [атрибут, значение], которые и называются признаками. Например, кандидат на должность девелопера может иметь такие атрибуты как возраст, наличие высшего образования, количество лет использования платформы, запрашиваемая зарплата и т.д. Эта информация затем может быть использована для автоматического отсеивания кандидатов, принимать которых на работу слишком рискованно или невыгодно. Сами атрибуты могут быть нескольких типов. В примере выше возраст – это числовой атрибут. Наличие высшего образования – булевский. Кроме этих двух типов часто встречаются категориальные или номинальные атрибуты, грубо говоря – перечисления. Например, для кандидата на работу это может быть национальность или семейное положение (и речь тут не о дискриминации, а о сборе максимального количества доступной информации :)). Очень редко вводят также строковые атрибуты, где значением могут являться произвольные строки. Как правило, в наборе данных вводят также один специальный атрибут – так называемый атрибут класса. На обучающих данных (если используется метод с обучением, конечно же) его значение известно, а для обрабатываемых – его требуется вычислить. Для примера с кандидатами на работу обучающая выборка может включать в себя признак того, считается ли кандидат подходящим, неподходящим или возможно_подходящим для данной работы. Именно этот признак и будет являться атрибутом класса, и именно его будет требоваться вычислить для новых резюме. Для хранения таких наборов данных используется обычная табличная форма. Это может быть, например, база данных, файл CSV или таблица MS Excel. При этом названия колонок обозначают имена атрибутов, а строки самой таблицы – отдельные объекты, подлежащие обработке. (Внутри программы, как и при математических рассуждениях, объекты представляются в виде векторов в многомерном пространстве. При этом оси координат соответствуют отдельным атрибутам, то есть отдельным элементам вектора.)

Основные задачи

Большинство задач машинного обучения можно условно разделить на 4 группы: классификация, кластеризация, числовые предсказания и извлечение ассоциативных правил. Рассмотрим каждую из них.

Классификация

Классификация (classification) – это группировка объектов по определённому признаку или набору признаков. Спам/не спам, отзыв положительный/отрицательны, кандидат подходит/не подходит/возможно_подходит. Группировка вида тёплый/холодный, синий/зелёный/красный, мальчик/девочка и тому подобное – это тоже классификация, но только по одному признаку, поэтому правила для неё легко определить вручную. В сложных же случаях, таких как определение, является ли письмо спамом, сможет ли заёмщик отдать кредит и т.д. обычно делают так. Вначале собирается статистическая информация об объектах, для которых уже известен их класс, – набор этих объектов называется обучающей выборкой. Затем к этим данным применяется алгоритм машинного обучения, в результате чего получается обученный классификатор, или модель. То есть модель = алгоритм + обучающая выборка. Перед тем как применять модель на реальных данных, как правило, проводят тестирование её производительности. Наиболее распространённым методом тестирования является так называемая перекрёстная проверка (cross-validation). Её суть заключается в том, что обучающая выборка делится на n частей. Классификатор обучается на (n-1) частях, а одну часть используют непосредственно для проверки результата. Эта процедура повторяется n раз, а результатом считается среднее арифметическое результатов отдельных тестов.

Кластеризация

mazeКластеризация (clustering) в целом похожа на классификацию – в ней объекты также группируются по набору признаков, однако в отличие от классификации при кластеризации нет обучающей выборки. И классов, соответственно, изначально никаких нет. Есть просто набор объектов, которые нужно как-то объединить в группы. Спрашивается, и как же это сделать, если объекты даже не с чем сравнивать? А сравнивать как раз есть с чем – друг с другом. Оказывается, в основе всех алгоритмов классификации лежит понятие расстояния. Проще всего это представить в виде географической проблемы. Предположим, что нам нужно объединить точки на карте – дома, рестораны, стоянки и т.д. – в города. При этом всё, что у нас есть – это координаты отдельных точек, но никакой информации об административном делении. Человек визуально может решить эту задачу элементарно – любая группа точек, расстояние между которыми меньше расстояния до другой группы, и будет считаться городом. После понимания этого, всё, что остаётся сделать, - это выбрать меру расстояния и найти эффективный алгоритм. В общем и целом кластеризация используется скорее для изучения, то есть для извлечения и анализа данных, чем для «серийного» применения. Она может быть проведена для любых данных, которые можно представить в виде графа. Например, в последнее время всё чаще появляются исследования социальных сетей и блогов.

Числовые предсказания

Как Gismeteo определяет, сколько градусов завтра ожидать на термометре? Верно, плохо определяет. Но речь не об этом. Как вообще можно предсказать погоду? По народным приметам, конечно же! Думаете, это шутка? Отнюдь. Народные приметы формировались на основании опыта предыдущих наблюдений. Современные методы работы метеослужб, как ни странно, мало чем отличаются от прабабушкиных предсказаний. pac-manПо сути единственное отличие в том, что с появлением современных компьютерных технологий появилась также и возможность более точно собирать данные и на их основе строить статистические модели. Именно так работают метеослужбы, и именно на этом основаны числовые предсказания (numeric predictions). В отличие от классификации, числовые предсказания, занимаются определением не качественного, а количественного значения некоторой зависимой переменной. В случае погоды зависимым параметром является температура, а также возможное отклонение от среднего значения. Другим примером может быть предсказание количества голосов, отданных за отдельных кандидатов на президентских выборах на основании их политических программ и опыта предыдущих лет. Стандартным приложением числовых предсказаний является также определение технических характеристик, таких как, например, производительность компьютера, на основании данных о его компонентах и прошлых исследованиях. По методологии же числовые предсказания мало чем отличаются от классификации – в них также создаётся обучающая выборка с атрибутом класса числового типа, запускается один из подходящих алгоритмов машинного обучения, а затем обученная модель применяется для предсказаний на новых образцах.

Извлечение ассоциативных правил

Когда вы заказываете книгу на Амазоне или просматриваете трейлер нового фильма на КиноПоиске, где-нибудь внизу обязательно высвечивается несколько похожих книг/фильмов. Система рекомендаций сейчас есть чуть ли не на каждом сайте, который предлагает товары или услуги. Но как они работают? Очень часто веб-мастера поступают просто: берут название товара и ищут по базе данных похожие записи. Но что, если ни названия, ни какие-либо другие атрибуты товаров не пересекаются? Например, «Гарри Поттер» и «Властелин Колец» тематически довольно похожи, и ими, наверняка, интересуется примерно одна и та же категория людей, однако вряд ли вы найдёте много общего в описаниях этих фильмов. Так что же общего тогда между ними. А общие между ними зрители. Если 100 человек посмотрели оба фильма, а 101-й посмотрел только «Властелина Колец», то имеет смысл предложить ему посмотреть и «Гарри Поттера». Если 20 человек заказали книги «Паттерны проектирования» и «Совершенный код», а 21-й только «Паттерны», то почему бы не предложить ему и «Код»? Вывод таких правил и называется извлечением ассоциаций (association mining, association rule learning). Ассоциации не обязательно должны связывать только 2 объекта. В общем виде такие правила можно записать так: Если A1, A2, …, An, то B1, B2, …, Bn. Или даже проще: A1, A2, …, An => B1, B2, ..., Bn. Вот несколько примеров возможных ассоциативных правил для магазинов: ноутбук => мышка, сумка для ноутбука; суши => васаби, соевый соус; понедельник, 8 утра => плохое настроение. Ассоциативные правила – это мощнейший инструмент маркетинга, однако область их применения не ограничена рекламой. Метеослужбы могут использовать, например, следующее правило: область циклона, область антициклона => дождь. Ассоциации используются в медицине для определения причин болезней (курение, загрязнение окружающей среды => понижение иммунитета, рак), в экономике и социологии для предсказания возможных изменений (девальвация, командная экономика => народные волнения) и т.д.

Интересно?

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

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

EMERGE 2020
1 июня — 3 июня

EMERGE 2020

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

Читайте также

Захватывают объекты, ищут инфлюенсеров и породистых перспективных скакунов. InData Labs: от сервисов к продуктам
Захватывают объекты, ищут инфлюенсеров и породистых перспективных скакунов. InData Labs: от сервисов к продуктам

Захватывают объекты, ищут инфлюенсеров и породистых перспективных скакунов. InData Labs: от сервисов к продуктам

3 комментария
Microsoft Azure AI/ML тренинг в Godel Technologies: как это было
Microsoft Azure AI/ML тренинг в Godel Technologies: как это было

Microsoft Azure AI/ML тренинг в Godel Technologies: как это было

Наши на Delex: как прошла первая DevOps и advanced Test Automation конференция в Минске
Наши на Delex: как прошла первая DevOps и advanced Test Automation конференция в Минске

Наши на Delex: как прошла первая DevOps и advanced Test Automation конференция в Минске

Первопроходцы GODEL TECHNOLOGIES покоряют искусственный интеллект
Первопроходцы GODEL TECHNOLOGIES покоряют искусственный интеллект

Первопроходцы GODEL TECHNOLOGIES покоряют искусственный интеллект

Обсуждение

2

интересует, конечно. в свое время немного пробовал заниматься data mining, правда, без особого результата.

1

Интересная статья. Жду продолжения.

1

Да, хорошая качественная статья, интересно для общего развития

1

Если интересно, можно в продолжении почитать вот это:

Стюарт Рассел, Питер Норвиг
Искусственный интеллект. Современный подход
http://www.ozon.ru/context/detail/id/2480883/

слить в djvu виде можно тут:
http://flibusta.net/b/144506

хотя я когда-то купил себе в коллекцию, в бумаге, для общего развития.

0

Потом можно плавно переходить вот к этому:

А. А. Жданов
Автономный искусственный интеллект
http://www.ozon.ru/context/detail/id/3736220/

0

И все, после прочтения, вы орк 99 левела - можно в бой! :)

0

Продолжайте, конечно :)

1

Образование у нас тоже числовая характеристика - в процентах :)
Научно-пополярно получилось. Можно какой-нибудь минимальный проект замутить. Думаю, многие из читателей присоединились бы.

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

Для этого нужны данные. Пример с публично доступными наборами данных обязательно приведу, а приватными данными никто, как правило, делиться не хочет. Можно, конечно, попробовать сделать что-то с opinion mining, но для этого нужны кое-какие знания по обработке текстов. Хотя, если есть желание, могу быстренько накидать утилитку по переводу текста в набор признаков.

0

вот интересный проект - http://math.scu.edu/~gmohler/crime_project.html

0

Интересная статья, буду ждать продолжение про использование этих методов на практике, особенно в коммерческих приложениях.

0

пример коммерческого использования - http://company.yandex.ru/technology/crypta/

1

пиши еще!

-1

аффтар жжот! пешы исчо!

1

keil, понятно, что тут сложность не в кодировании. Положим, есть некий большой набор данных, где еще и шума очень много. И надо найти в нем полезные закономерности, сделать выводы. Пример - система учета времени или багтреккинга.
Да, я знаю, что есть много умных книг (хоть на амазоне по Datamining поискать), но было бы интересно сперва узнать применимо ли это в дэй-ту-дэй.

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

Чтобы сделать выводы, сначала нужно хотя бы примерно прикинуть, какие зависимости можно извлечь. В системах бактрекинга или учёта времени, честно говоря, не вижу особо интересных закономерностей. Можно, конечно, проанализировать зависимость времени исправления багов от их приоритета или от человека, который ими занимался, но мне кажется это не очень показательный пример.

Есть вариант проанализировать ассоциации между технологиями в вакансиях на dev.by. То есть просто забить все возможные технологии в базу, распарсить вакансии и посмотреть, какие связки технологий чаще всего используются на практике. Я делал похожую вещь с LinkedIn, только вместо вакансий использовал профили людей. Обноружил довольно неожиданные для себя зависимости (например, оказалост, что очень многие люди, знимающиеся маркетингом впоследствии переходят в менеджемент и наоборот).

То же самое можно сделать, например, с тегами на StackOverflow, ну и вообще с любыми данными из соц сетей.

Другой вариант - проанализировать статистику по покупкам/просмотрам/скачиваниям. Можно, например, собрать информацию о новостях, просмотренных с одного IP-адреса. "Обезличенные" такие данные не представляют собой коммерческой тайны, но являются прекрасным ресурсом для data mining. К сожалению, я не являюсь владельцем ни одного такого сайта, а те данные, с которыми работаю, увы, раскрывать не могу. Если кто-то может предложить такие данные, это могло бы стать замечательным примером.

Есть, конечно, популярные репозитории и даже целые сайты для поиска наборов данных, но вряд ли это можно назвать day-to-day usage.

Так что если есть какие-то пожелания или предложения, с удовольствие выслушаю.

-1

Нелогично. Если утверждать, что из системы багтрекинга (про учет времени не говорю) полезных данных извлечь нельзя, то следовательно их там нет. А зачем тогда мы все ими пользуемся и находим полезными? :)

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

Не данных, а информации, не полезных, а скрытых и интересных. Данные то все полезны, но если в базе системы учёта времени есть запись , то нет смысла применять алгоритмы извлечения данных, чтобы узнать, что Вася потратил целых 8 часов на исправление одного бага.

0

Да, видимо у меня намеки слишком тонкие. Данные багтрекинга сами по себе не живут. Рассмотрите их вместе с репозиторием кода и историей коммитов, diff-ами и найдете много интересных взаимосвязей, скрытых. Которые можно повыколупывать, было бы желание. Возможно даже получится универсальная метрика для оценки крутости разработчика :)

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

А какого разработчика считать крутым? Того, кто сделал больше всех коммитов, или исправил больше всего багов, или написал больше всего строк кода? :) Не помню где, но где-то была история о том, как в одной компании вели учёт количества строк написанного кода. Один программист очень не любил эту систему, но вынужден был следовать ей. После очередного рефакторинга в своём отчёте он написал "- 200 строк". После этого его больше не просили заполнять такие отчёты :)

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

0

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

Не в ту сторону размышляите :) У вас есть набор тикетов: баг, таск, рефакторинг, ля-ля-ля... к каждому из них привязан один (или более) коммитов, которые есть на самом деле диффы. Диффы это, грубо, набор строк проекта, которые изменились. Проект имеет иерархию: строка-файл-директория(модуль)-директория(модуль)-.... а далее можно например следующим образом все рассмотреть:
* строка имеет историю коммитов: вася (таск), петя (рефакторинг), коля (багфикс), петя (багфикс) - с некотогрыми временными интервалами. Может большими, может маленькими.
* сам коммит состоит из изменений (логически связанных) в разных файлах и зачастую в разных модулях. То есть приличная статистика по коммитам дает вам некую внутреннюю зависимость между строками кода, файлами, модулями. Скажем, для толстого проекта с 10-летней историей подозреваю картинка связей будет очень познавательна и весьма близка к реалу.

Что с этой моделькой можно делать? Навскидку:
* раскрасить дерево файлов/классов проекта по индексу "бажности", "трудоемкости/сложности"
* кликнув по модулю, с некоей долей вероятности раскрасить дерево проекта по возможным проблемам в в других модулях, если внести изменений в данный модуль.
* накидать в карму разработчикам рейтинг, вычисляемый некоей интегральной оценкой по строкам кода которых "касался" данный разраб и истории маркеров на этих строках (маркера - это "баг", "таск" и т.п. из тикет системы). К примеру:
- строка закомичена петей как таск и живет долго и счастливо и больше не менялась. Хорошая строка, пете плюсадын.
- строка закомичена петей, поменялась как багфикс колей == минус пете в карму, + коле в карму.
- потом та же строка опять поменялась в результате багфикса == маленький минус коле в карму (возможно зафиксил херово), маленький минус пете (да что ж за код, который два раза фиксить надо).

Ну там много чего еще можно придумать. Это просто как идея навскидку.

Если напишите шаровару, мне, пожалуйста, бесплатную лицензию на 100 компов на всю жизнь :)

0

Хотя вам оно сто лет не надо наверное, а вот Микаэлю Дубакову к ихнему Целевому Процессу что-нить подобное прикрутить наверное и имело бы смысл :)

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
1

Ну, какой-то смысл в этой идее наверное есть, но мне кажется, что большую часть подобных задач можно решить с помощью обычной статистики без DM или ML, а те, которые касаются оценки разработчиков или предсказания для других модулей очень уж субъективны. Например, если в петином модуле нашли баг, то может это его ошибка, а может ошибка тим лида, который ему сказал так сделать. Или ошибка в сторонней библиотеке, которую использует в своём модуле Петя. Плюс если Петя - джуниор и ему дают писать только простенькие классы, а Ваня - супер-пупер сеньёр и занимается сложнейшими алгоритмами, то ошибок (и уж тем более правок) у Вани будет намного больше, но его "карма" по такой системе будет меньше.

Но можно пойти другим путём: попросить коллег или тим лида оценить каждого разработчика, скажем, по десятибальной шкале, а затем уже использовать статистику по багам, таскам, etc. для построения модели оценки разработчика. И вот уже эту модель использовать для оценки других программистов. Но тогда нужна внушительный набор данных для обучения - для самой грубой оценки нужны как минимум человек 30. Если обеспечите мне такую базу, модель я вам построю :)

0

Интересно вы рассуждаете. А оценки тим-лида и коллег субъективными не будут? Зависть, личная неприязнь, межличностные конфликты, любовный треугольник, иные благородные чувства :)

И тут вам надо всего 30 таких субъективных оценок, чтобы вывести грубую "объективную" оценку, а в случае 1к коммитов, которые меняет 100-500к строк кода оно почему-то субъективно будет.

Рассмотрите коммит, как оценку кода предыдущей ревизии. Если по строкам смотреть, у вас будут миллионы оценок строк для приличного проекта. И если еще учесть, что разработчики имеют некоторую мотивацию сделать код лучше при коммите, то оценка кода на основании анализа коммитов и последующие выводы будет куда более объективна, чем любые баллы друг другу в любой дурацкой анкете кадровой девушки.

И да... по жизни если, в 1к строк джуниора Пети будет Х ошибок, да еще Вася их будет постоянно править, потому что Петя дундук. А в 20к строках кода Васи ошибок будет 20*Х или все-таки меньше? И кто их будет править, Петя или сам Вася? И заметьте, система сбалансирована, то есть за каждую стабильную строку Вася будет получать плюс, а не только одни минусы (как у нас практикуют в некоторых конторах)... а стабильных строк у него будет очень много, он же хороший программист :)

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
-1

Почему-то меня приследуюет ощущение, что меня активно троллят. Люди никогда не будут объективны, но усреднённые значения от нескольких людей как правило считаются более или менее объективными (не только в статистике, но и в социуме). А то, что предлагаете - это как раз ваша односторонняя оценка разработчиков. Вы сами жёстко определили параметры, сами задали "веса", которые следует прибавлять или отнимать от "кармы" программиста. На каком основании вы выбрали именно эти параметры? Просто взяли из головы. А ML как раз и стремится не брать показатели на угад, а методично отобрать нужны и придать им нужные "веса".

0

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

Сейчас с телефона. Доберусь до "большого" компа попытаюсь расписать ответ. Заодно и подумаю, как лучше это сделать.

У меня просто как раз стойкое ощущение, что я нарисовал картинку очень схематично и в результате вот.

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

Тогда ещё раз про Васю и Петю. Если джуниор Петя пишет программы на уровне разбора файла конфигурации, а сеньёр Вася пишет новую систему сжатия данных, то Петя сможет за вечер настрочить 3 тысячи строк, в которых не будет ни одной ошибки из-за тривиальности кода, а Вася весь день потратит на две маленькие функции, при этом будет вносить в них массу измненений, чтобы протестировать результат. В итоге Петя по вашей системе получит + несколько тысяч, а Вася из-за своих правок получит значительный минус. И таких моментов может быть много. Два коммите, после которых появился баг - кто из комитчиков виноват? Баг видет внешне, но какая именно строка виновата не понятно, а значит и не понятно, кто виноват. Провели рефакторинг, удалили 1000 строк - непонятно, увеличивать или уменьшать карму. Выбрали неправильную архитектуру, написали в 10 раз больше кода, чем можно было бы написать - система показывает большой плюс, хотя на самом деле это жирный минус. И так далее и так далее.

0

Карма вообщем-то одно из возможных применений и не самое, по мне, главное.

Хочу заметить, что саму идею я набросал за 10-20 минут и ожидать от нее идеальности вряд-ли стоит. Суть простая - если строка исправляется, то предыдущая версия строки была неверная. В конкретном случае это возможно и не так, но усредняя по проекту это скорее верно, чем нет. Сами мои веса и примеры это просто схема идеи. В реализации надо думать, рассматривать варианты (как я написал вначале: возможно даже получится универсальная метрика для оценки крутости разработчика).

С весами напрямую скорее не получилось, чем получилось. Все вашим примеры, конечно можно так или иначе "исправить", но это значит рассматривать потенциально очень большое (если не бесконечное) количество вариантов и для каждого рисовать эмпирический фикс. Не айс. Сложно, а значит скорей всего неверно.

Как вам такой вариант:
карма = (количество строк разработчика исправленных с пометкой баг)/(общее количество строк разработчика)... * 100%
при этом никто не мешает в тикет системе вводить баги, которые не будут учитываться при подсчете кармы. Это уже административное решение, потому что баги разные бывают. Вполне возможно, учет бага, как бага влияющего на карму может быть и коллегиальным решением команды. Когда все согласны, что косяк имеет место быть.

Можно параллельно трекать карму2 = (количество строк разработчика исправленных с пометкой ревью)/(общее количество строк разработчика)... * 100%

Вполне возможно наверное придумать и еще какие-нибудь кармы со своими индексами.

Серебряной пули, само собой, не получится, но как инструмент в помощь команде... возможно.

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

0

Давайте вообще забудем про мои "веса" и плюсадин. Я не ввожу никаких своих оценок и баллов. Поставим вопрос так.

Рассмотрим простой коммит, который что-то правит:
1. Коммит является естественной оценкой самого разработчика для части кода предыдущей ревизии.
2. На коммит возможно повешен маркер из тикет системы манагером. Это тоже естественная оценка человека из команды.
3. Код, вообщем, имеет древовидную структуру (по-крайней мере для С/С++/Java/C# это верно). Коммит, правящий несколько файлов, задает горизонтальные связи между ветками (и отдельными вершинами) дерева.

Замечение по п3: Конечно могут быть варианты, когда в одном коммите заливаются два файла, правки в которых не имеют друг к другу никакого отношения. Но мой опыт мне шепчет, что в большинстве случаев логическая связь все-таки есть. Тут скорее типичен вариант, когда от лени заливают в коммите 10 файлов, которые содержат в себе решения 3 тасков одновременно.

Итого: Есть дерево. Есть много горизонтальных связей. Некоторые связи как-то отмаркированы.

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

0

"2. На коммит возможно повешен маркер из тикет системы манагером. "
Кривая фраза получилась. Маркер, это некая инфа из тикета:
тип тикета = баг, таск, улучшение, идея
приоритет = ....
компонент = ui, core engine, plugin 1, plugin 2
таги = ...
Маркер назначается манагером, то есть тоже не моя личная оценка, а можно считать что он анкету заполнил :)

Понятно, что связать коммиты и тикеты задача чисто техническая. В предельном случае - административная.

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

> при этом никто не мешает в тикет системе вводить баги, которые не будут учитываться при подсчете кармы. Это уже административное решение, потому что баги разные бывают. Вполне возможно, учет бага, как бага влияющего на карму может быть и коллегиальным решением команды. Когда все согласны, что косяк имеет место быть.

Очень напряжно для команды. Команда должна думать о том, как лучше сделать продукт, а не о том, как назвать баг - просто багом или багом с прибамбасами. А если это ещё и на каааарму влияет...

Вообще введение системы с кармой требует другой методологии. Похожую вещь используют ребята из StackExchange - они расчитывают зарплплату разработчика в соостветствии с их "полезностью" для компании, при этом "полезность" расчитывается не только по коду, но и по участию в конференциях от имени компании, написании статей в блоги и т.д. Мне кажется, систему, которую вы предлагаете, можно ввести в отдельно взятой команде или небольшой компании, но при этом выводы делать тоже не по коду, а по общему впечатлению о программисте. Например, разработчик предложил хорошее архитектурное решение - +20 в карму, разработчик не проставился на свой др - -100 в карму, потому что все ему скинулись на подарок, а теперь ходят злые и работать не хотят :) Но, в любом случае, полезность работника нельзя расчитывать исходя только из его кода, тем более с такой узкой метрикой как строки + метки.

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

Честно говоря, в голову приходит только использование горизонтальных связей для поиска модулей с высокой связностью, а это может помочь при рефакторинге. Однакое в 95% случаев гораздо более эффективным решением будет анализ исходных кодов и поиск импортов. Так что опять непонятно, какую именно скрытую информацию можно вытянуть из багтрекинговой системы.

0

Была слишком хорошая идея, удалил :)

0

Вот так и живем :)

0

ml-class.com, ai-class.com
уже все зарегистрировались?

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
0

Ради интереса зарегался на ml-class, но, честно говоря, не уверен, что будет время на полноценное изучение. Чувствую придётся скачивать и дочитывать материал в дальнейшем :)

Anonymous
Anonymous Sr. Developer/Team Lead в Paralect
1

Спасибо за интересную статью. Только вот зачем совсем не релевантные картинки вставлять? Эти КДПВ в технических статьях лишь мешают.

Anonymous
Anonymous Senior Pomidor в Силикон Лаб
-1

Они являются "якорями" для глаза - по ним легко отслеживать, где сейчас читаешь, и легко потом находить понравившуюся информацию. Для небольших текстов хватает обычного форматирования (выделения жирным, курсивом, заголовками), для более крупных текстов этого уже недостаточно.
Обилие картинок "по теме" будет в следующей части :)

0

Написано очень хорошо и популярно, так что даже я понял. Спасибо автору.

0

спасибо, позновательно

0

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

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже