SQM 4/24: Halstead Complexity

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

• Размер кода влияет на его сложность, а сложность влияет на размер.  

• Если код большой, то его сложность, скорее всего, будет низкой.  

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

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

• Метрика когнитивной сложности учитывает весовые коэффициенты на каждый переход и ветвление, что позволяет оценить сложность восприятия кода.  

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

• Современные объектно-ориентированные языки, такие как Java, имеют элементы функционального программирования, что позволяет передавать функции как параметры в другие функции.  

• Это может усложнить понимание кода и увеличить его сложность.  

• Автор обсуждает изменение читаемости кода с появлением гибридных объектно-ориентированных языков, таких как Java.  

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

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

• Автор обсуждает предложение исследователя Муриса Холстеда, который предложил набор метрик для оценки программ.  

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

• Автор приводит пример использования этих метрик для анализа простой программы на языке Си.  

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

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

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

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

• Он вводит три новых метрики: длина, словарь и оценочная длина.  

• Длина программы определяется как сумма всех операторов и оператов, а оценочная длина - как сумма уникальных операторов и оператов.  

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

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

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

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

• Муррис предложил три метрики для оценки сложности кода: длина кода, дефити и эфф.  

• Вольюм - количество кода, дефити - сложность кода, эфф - количество усилий для написания кода.  

• Меньше операторов в коде делает его более понятным для чтения.  

• Тернарный оператор может быть альтернативой для if-else, но его использование может снизить андестда билити программы.  

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

• Автор обсуждает метрики для оценки качества кода, включая Effort, Time и Bugs.  

• Effort - это мера усилий, необходимых для создания программы, Time - время, необходимое для написания программы, и Bugs - количество ошибок, которые делает программист.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Процесс также включает в себя регулярный аудит кода и документирование технических решений.  

• В видео объясняется, как процесс разработки программного обеспечения оценивается с помощью двух показателей: "кей побилити" и "мачуете".  

• "Кей побилити" измеряет, насколько процесс соответствует требованиям, а "мачуете" измеряет, насколько процесс является "взрослым" и стабильным.  

• Если процесс соответствует требованиям, но не является "взрослым", ему присваивается низкий уровень "мачуете".  

• В видео также обсуждается сертификация процесса разработки программного обеспечения по стандарту "си-эм интеграшн".  

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

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

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

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

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

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

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