SQM 5/24: Maintainability Index

• Лекция о метрике Мейнтейн Набильти, которая была предложена в 1970-х годах.  

• Фред Брукс предложил понятие стоимости поддержки программного продукта, которая может быть выше на 40% или более.  

• Технический долг был предложен Уордом Каннингхэмом в 1992 году, когда мы создаем программный продукт и отдаем его на шиппинг, мы получаем долг.  

• Термин "технический долг" был предложен Уордом Каннингхэмом в 1992 году.  

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

• В 1994 году было предложено создание метрики Мейнтейн Набильти Индекс.  

• Ключевые авторы - Пол Омен и другие исследователи из Хьюлетт Паккард, Микроны Кондактор и Университета Айдахо.  

• В статье обсуждается таксономия метрик, предложенная исследователями из университета Айдахо.  

• Они предложили иерархический формат, в котором описали все метрики, влияющие на поддерживаемость системы.  

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

• Формула предполагает перемножение трех компонентов и взвешивание каждого элемента дерева.  

• В 1994 году исследователи из университета Айдахо и Хьюлетт-Паккард совместно написали статью, в которой рассказали о попытке измерить метрику на реальном коде.  

• Они использовали индекс на коде, написанном в Хьюлетт-Паккард, и применили другой подход к измерению метрики.  

• В статье обсуждается принцип метрик набилити, которые используются для оценки качества кода.  

• Авторы предлагают использовать дополнительные данные о коде, чтобы улучшить его качество.  

• Авторы предлагают формулу, которая включает четыре метрики: холт эфд, слом комплекти, количество строк кода и количество комментариев.  

• Формула была эмпирически найдена и может быть скорректирована в зависимости от конкретных ситуаций.  

• Максимальная цифра набилити составляет 221, минимальная уходит в минус бесконечность.  

• Если количество строк кода растет, то поддерживаемость кода падает, что отражается на значении набилити.  

• В видео обсуждается метрика Мейтена Билити, которая используется в продукте Microsoft Visual Studio.  

• Метрика была модифицирована, чтобы привести ее к диапазону от 0 до 100, вместо прежнего диапазона от 221 до бесконечности.  

• Это сделано для того, чтобы сделать метрику понятной и применимой для программистов.  

• В статье 2016 года автор критикует метрику Мейтена Билити, считая ее нонсенсом.  

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

• В статье 2014 года автор также критикует использование метрики Мейтена Билити как карающего инструмента для программистов.  

• Он предлагает использовать ее как наказание для программистов, пишущих плохо, но не как карающий инструмент.  

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

• Он отмечает, что этот индекс был создан в 1994 году и с тех пор не был перекалиброван.  

• Это может привести к использованию устаревших данных и неправильным результатам.  

• Автор платформы для анализа кода критикует использование индекса менте набилити для измерения относительной метенабилити.  

• Он считает, что этот индекс лучше использовать для сравнения абсолютных метрик.  

• В статье сравниваются разные варианты индекса менте набилити, включая вариант от Microsoft.  

• Авторы статьи анализируют корреляцию между различными метриками и индексом менте набилити.  

• В статье обсуждаются различные метрики качества кода, включая строки кода, комплекти, когнити и халст комплекти.  

• Авторы анализируют, как эти метрики коррелируют с индексом метейна билити.  

• В статье обсуждается мета-исследование, где исследователи анализируют существующие исследования и систематизируют их результаты.  

• В данном исследовании авторы нашли 174 различные метрики качества кода.  

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

• Обсуждаются метрики, такие как количество строк кода, количество комментариев и другие, и их влияние на качество кода.  

• Упоминается, что метрики не так сложно рассчитать, но сложность заключается в их интерпретации и применении в практических ситуациях.  

• Упоминается, что большинство программистов не всегда пишут качественный код, и что метрики могут помочь заставить их писать лучше.  

• Приводится пример, когда инструмент контроля качества блокирует сборку продукта, если код не соответствует определенным стандартам.  

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

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

• Второй шаг - описание методов исследования, как автор изучал влияние метрики на качество кода.  

• Автор описывает пошаговый рецепт приготовления продукта, начиная с набора программистов и заканчивая проведением эксперимента.  

• Он подчеркивает, что важно описывать процесс, как будто он уже завершен, чтобы ответить на ресерч-вопросы.  

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

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

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

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

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

• Он также подчеркивает важность доступности результатов для других исследователей и читателей.  

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

• Он признает, что его исследование имеет слабые стороны и что он не может проанализировать все классы Java.  

• В этом разделе автор может высказать свои мнения и спекуляции, которые не допускаются в предыдущих разделах.  

• Это позволяет ему расширить территорию исследования и обсудить свои мысли с читателем.  

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

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

• Автор должен создать заголовок, который бы в одном предложении описывал главный вывод его статьи.  

• Этот заголовок должен быть кратким и понятным, чтобы привлечь внимание читателя.