SQM 2/24: Cyclomatic Complexity by Thomas J. McCabe

• Обсуждение метрики "лайнзу коут" для измерения размера кода.  

• Мейтейна билити как индикатор удобства и поддерживаемости кода.  

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

• Простота кода может быть важнее его компактности.  

• Примеры языков, таких как Perl и Brainfuck, где компактный код может быть трудночитаемым.  

• Поиск золотой середины между длинным и коротким, но трудночитаемым кодом.  

• Важность качества кода и его метрик.  

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

• Отсутствие единой метрики для измерения мейтейна билити.  

• Введение в метрику "сайлом комплексти" SCL.  

• Философское введение в измерение сложности кода.  

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

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

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

• Программисты могут использовать сложность кода для запутывания других.  

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

• Программы могут выполнять одинаковый функционал, но выглядеть по-разному.  

• Некоторые писатели считают, что сложный текст делает их более качественными.  

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

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

• Переход на опенсорс разработку и удаленную работу изменил подход к написанию кода.  

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

• Чем проще код, тем выше его ценность и стоимость работы программиста.  

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

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

• Программисты, понимающие такие языки, могут стоить очень дорого.  

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

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

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

• Банки часто сталкиваются с трудностями при переходе на новые технологии.  

• Финансовые структуры действуют медленно из-за высоких рисков.  

• Любое изменение кода связано с высокими рисками и требует значительных усилий.  

• Переход на другой язык или архитектуру может привести к потере функционала.  

• Необходимы новые циклы тестирования и баг-репортинга.  

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

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

• Пришлось покупать новый сервер и переносить приложение.  

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

• Необходимо регулярно проверять версии операционной системы и софта.  

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

• Важно понимать риски и готовиться к обновлениям заранее.  

• Чем сложнее код, тем хуже программист.  

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

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

• Сломти комплекти предложен как метрика Томасом Мак Кейпом Синером.  

• Томас Маккейп в 1976 году предложил метрику для оценки сложности программ.  

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

• Пример программы: если a больше пяти, то print x, иначе exit.  

• Вход на график обозначается кружочком.  

• Оператор if принимает решение и может пойти влево или вправо.  

• Если a больше пяти, выполняется print, иначе exit.  

• Граф программы имеет входящую и выходящую точки, а также два нода.  

• Сложность графа рассчитывается как количество стрелок минус количество нодов.  

• В примере с программой a больше пяти, то print, иначе exit, сложность равна четырем.  

• Количество решений, принимаемых в программе, влияет на сложность.  

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

• Чем больше решений, тем сложнее понять программу.  

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

• Томас Маккейп работал в компании, которая доминировала в области компьютерных наук.  

• Он предложил метрику для оценки сложности программного кода.  

• Задание для студентов: предложить свою метрику для оценки сложности кода.  

• Уровень вложенности кода можно использовать для оценки сложности.  

• Пример: если код идет по вертикали, сложность равна единице.  

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

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

• Разные трактовки метрики могут приводить к разным результатам.  

• Важно понимать, как метрика помогает оценить сложность программы.  

• Обсуждение метрик для оценки сложности кода.  

• Использование машинного обучения и моделей для анализа кода.  

• Пример с моделью, которая оценивает сложность кода на основе данных о восприятии программистов.  

• Переход к недоопределенным методам оценки сложности кода.  

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

• Пример эксперимента с 100 тысячами программистов и 100 тысячами примеров кода.  

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

• Возможность использования модели для оценки метеинабилити кода.  

• Пример использования модели в IDE для автоматического анализа кода.  

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

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

• Пример кода с метрикой сложности 3.  

• Метрика complexity как мера риска.  

• Использование инструментов для контроля сложности кода.  

• Примеры методов с высокой сложностью кода.  

• Обсуждение корреляции между метриками complexity и line count.  

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

• Различие между зависимостью и корреляцией метрик.  

• График показывает частоту несчастных случаев на воде и количество проданного мороженого.  

• Делается вывод о зависимости между продажей мороженого и несчастными случаями.  

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

• Жаркая погода увеличивает количество проданного мороженого и несчастных случаев.  

• Мороженое не связано с несчастными случаями, это просто корреляция.  

• Для подтверждения зависимости нужны дополнительные эксперименты.  

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

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

• Рекомендуется писать более короткий код для снижения сложности.  

• Два подхода: среднее значение для всех методов класса или расчет по всей программе.  

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

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

• Циклы в программе можно представить как условия и тело.  

• Компилятор переводит циклы в команды if и goto.  

• Важно правильно представлять циклы для расчета сложности.  

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

• Среднее значение не всегда отражает реальную сложность.  

• Важно учитывать все методы, а не только видимые.  

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

• В прошлом, когда разрабатывалась методика, не было понятия private и public.  

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

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

• Метрика "количество строк кода в методе" не дает полной картины.  

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

• Использование только одной метрики неэффективно.  

• Метрики должны работать в комбинации, чтобы контролировать код.  

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

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

• Жесткие границы помогают поддерживать качество кода.  

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

• Программисты могут возражать против установленных границ, считая их мешающими их творчеству.  

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

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

• Фичер крип — это добавление лишних функций в проект, что делает его сложным и неподдерживаемым.  

• Контроль сложности кода помогает предотвратить фичер крип.  

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

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

• Программисты вынуждены создавать новые функции или классы, если текущая функция превышает допустимую сложность.  

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

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

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

• В C++ многие анализаторы коммерческие, в Java и JavaScript есть бесплатные решения.  

• Можно создать собственный статический анализатор для отслеживания сложности кода.  

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

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

• Теоретическая часть о сложности кода завершена.  

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

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

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

• Метод должен включать шаги: сбор данных, сортировка, статистический анализ.  

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

• После написания метода проверьте, не дублируете ли вы уже существующие исследования.  

• Используйте базу данных Scopus для поиска научных статей.  

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

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

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

• В разделе "Обзор литературы" найдите работы, близкие к вашему исследованию, но с недостатками.  

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

• Если не нашли недостатков, возможно, ваше исследование не нужно.  

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

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

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

• Данные на GitHub могут исчезнуть, что делает исследования ненадежными.  

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

• Наука требует повторяемости экспериментов, иначе это не наука, а фольклор.  

• Создан скрипт для сбора и фильтрации данных с GitHub.  

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

• Планируется создание более свежей версии датасета.  

• Необходимость создания централизованного хранилища цифровых артефактов.  

• Текущие библиотеки текстов и документов не решают проблему.  

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

• Комментарии не учитываются в метриках, таких как SLOCC.  

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

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

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

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

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