Визуализация кодовой эволюции

[Halt]

Взгляните на три графика: все они показывают одно и то же. По оси X указаны файлы в системе с сортировкой по частоте изменений (число коммитов, взятое из данные контроля версий). Ось Y показывает число коммитов для каждого файла.

На графиках — данные из трех совершенно разных систем с разными предметными областями, сами кодовые базы различных размеров, разработанные в разных компаниях и с разным сроком жизни. Но все графики показывают одинаковое геометрическое распределение.

Видимо Адама можно поздравить. Он только что открыл закон Ципфа.

Напоминает анекдот про биологов, внезапно обнаруживших, что периметр муравейника примерно в 3 раза больше его размера от края до края.

[sven47]

Думаю что часть про новизну это часть маркетинга, который всегда склонен преувеличивать достижения и уникальность.
Основная же задача статьи пиар инструмента написанного автором.

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

[ivnC]

Я не вижу связи между распределением частоты слов естественного языка (про которое говорится в законе Ципфа) и распределением частоты внесения изменений в код по файлам. В целом, геометрическое распределение много где встречается.

[Oxoron]

«Рефакторь часто изменяемое» — идея интересная, но с подводными камнями. Во-первых, при рефакторинге файл может быть разбит на два файла, на некоторое время дополнительный файл выпадет из поля зрения. Во-вторых, надо помнить про кодогенерацию. В-третьих, есть readme файлы, которые могут изменяться весьма-и-весьма значительно. В-четвертых, изменения не всегда ходят по одиночке, часто с основным файлом меняются еще и тестовые. В-пятых, может быть зависимость от области (файлы с параметрами мобов в десктоп-игрушке могут меняться часто, но изменения эти рутинные).
Суммируя: инструмент интересный, но как единая метрика к любому языку вряд ли подойдет. В любом случае придется подгонять под каждый конкретный проект. Разве что, проекты типовые, но в такой ситуации проблемные места известны заранее.

[kenrube]

Спасибо, весьма интересно. Перевод второй части будет?

[ivnC]

Нет, вторая часть какая-то замороченная и более инструментальная. В этой же есть общие теоретические рассуждения. Если интересно, советую посмотреть статью Адама с галереей разных визуализаций, и выводами, которые он сделал на их основании ) http://www.adamtornhill.com/articles/crimegallery/codecrimescenegallery.htm