Comments 14
Плотность решений: Отношение количества архитектурных маркеров (интерфейсы, инъекции, паттерны) к общему числу токенов. Такая метрика позволит оценить уровень «зашумленности» реализации.
И в каком случае реализация будет считаться зашумленной? Когда показатель высокий или низкий?
Низкое количество использования маркеров на общий объем кода. Если, например, на весь проект один интерфейс и 15 классов, если грубо. И наоборот
Метрика выражается числом же.
Как вы вычисляете это число? И что оно вам даёт?
на весь проект один интерфейс и 15 классов
То есть, кол-во маркеров=16 в вашем случае?
А сколько токенов? 1600 например. Тогда метрика равна 0,01, я правильно посчитал?
По итогу, это хорошо или плохо? Какой показатель у вас хороший?
Мы берем за токен любую букво-циферную последовательность, выделенную через регулярку, и делим количество найденных маркеров на общее количество найденных последовательностей.Вы посчитали правильно, если упростить. В примере, который мы обсуждаем 1% - это плохо, так как на 100 токенов у нас есть только один значимыйХороший или плохой показатель стоит выбирать относительно второй метрики - семантической плотности. При высокой плотности решений низкая семантическая плотность - это плохо. Значит, проект перегружен архитектурными решениями, не нужными на практике. И наоборот - при низкой/умеренной плотности решений высокая семантическая нагрузка показывает умелое применение архитектурных навыков
Возможно, в статье не прослеживается, но нельзя оценивать что-то однобоко. Все имеет свой контекст и метрики, которые используются, оцениваются так же в сумме. Навыки разработчиков оцениваются в контексте рыночной важности, код - в контексте его смысла и архитектуры
Высокая «концентрация информационной нагрузки» в статье рассматривается как показатель хорошего качества кода. В линтерах же оценка когнитивной сложности кода cognitive complexity, которую стараются снижать. Также есть показатель поддерживаемости кода maintainability index, который говорит, что чем выше когнитивная сложность, тем код сложнее поддерживать.
Важен контекст использования этой метрики. В данном случае мы пытаемся оценить как человек спроектировал свою систему, насколько грамотно использовал собственные знания. Разрабатываемая методика и выбор подхода "зонд вместо репозиториев" практикой пробует доказать, что маленький кусочек может сказать больше, чем проект в несколько тысяч строк. Это не призыв бездумно повышать сложность, это направление внимания на то, как много может быть воды в проекте и как мало смысла
Цель хорошая. В ООП коде такое часто встречается, шаблонный шаблон на 500 строк, что можно переписать в одну функцию на 10 строк.
Но, имхо, анализ кода должен быть автоматизирован. Если нужно еще думать, где метрику можно применять где нельзя - то это не масштабируемо и полуручной анализ получается.
А если на метрику опираться «бездумно», как вы сказали. То после ее оптимизации будет неизбежно повышаться когнитивная сложность кода и снижаться поддерживаемость
Данный вопрос рассматривался в той или иной мере вот в этой статье. Сейчас цель - разработать методику оценки грейда, которая была бы объективна и оценивала бы человека по тому, что он действительно умеет, а не показывает, что умеет. И то, что описано в этой статье значительно упрощает данный анализ. А вот если оценивать код в целом, то стоит смотреть и на классические метрики, и на смысл. Да и то, это не конечный список
В 26 то году, когда нам говорят что мы должны отстать от нейросети и дать ей писать так как она хочет))) на носу переход в нечитаемый байткод удобный и понятный только нейросетям))) имхо все это конечно интересно но не нужно)))
Это больно, когда лидеры индустрии, пусть и локальные, заявляют, что им выгоднее перекупить синьора и дать ему ИИ, вместо того, что брать джунов и миддлов. Особенно больно, когда они ссылаются вот на ЭТО. То есть мы четыре года будем учить, как работает разработка, как управлять проектом, как должен быть выстроен жц и так далее, а нам в лицо заявляют "а на*** мне тратить время синьора на адаптацию новеньких, если он мне быстро наваяет. И что, что уже были коллапсы из-за ИИ? Бывает. Да, индустрия и предпринимательство в жопе. Но вы можете выстрелить, дерзайте!"
Как же жопа от этого горит. Как будто я не понимаю чего-то, говоря об ограничениях контекста, дороговизны обучения ИИ, ее поддержки и работы с галлюцинациями... Как-будто все, что нам рассказывают, ломается о простое долгосрочное планирование...
Селява, капитализьм, конкуренция, итд))) но я вот как живой пока разработчик сам пересел со скрипом в курсор из спортивного интереса и внезапно обнаружил, что да, часто это нет красиво с точки зрения программирования и часто не ьак красиво семантически, но это тупо в 10 раз быстрее и работает. А время как известно это в отличии от людей и денег невосполняемый ресурс, так шта вот)
Я бы в качестве метрики брал расширение кода после рефакторинга. Т.е. сколько понадобится кода, чтобы добавить новый функционал. Ну, это на мидла. На синьора – ещё отличить, где это надо делать, а где оставить, как есть.
Мал, да удал: почему пять строк рефакторинга могут сказать о разработчике больше, чем весь его GitHub