SQM 8/24: TCC and LCC

• Лекция посвящена качеству программного кода.  

• Качество кода измеряется метриками и цифровыми показателями.  

• Метрики помогают управлять процессом разработки и предотвращать дефекты.  

• Качество кода и продукта не всегда совпадают.  

• Код может быть качественным, но продукт может содержать дефекты.  

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

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

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

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

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

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

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

• Книга "Designing Object-Oriented Software" обсуждает связывание и кохижин.  

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

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

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

• В программном коде это моделируется как проблемный домен и домен имплементации.  

• Эти области помогают структурировать решение проблемы.  

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

• Точность аппроксимации сущности определяет качество модуля.  

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

• Ютилити классы не связаны с сущностями в домене проблем.  

• Рекомендация: читать книгу по метрике.  

• Метрика появилась с появлением объектно-ориентированных систем.  

• Структурирование кода через классы и методы.  

• Появление метрик для измерения связей и компонентов.  

• Идея структурирования кода через объекты и методы.  

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

• Класс Rectangle с четырьмя атрибутами и методами.  

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

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

• Определение количества диреклин коннект методов.  

• Определение диреклин коннект методов.  

• Расчет метрики TCC: количество диреклин коннект методов деленное на общее число методов.  

• Чем выше TCC, тем более кохизи класс.  

• Отсутствие зон ответственности улучшает кохизи.  

• LCC помогает выявить зоны ответственности.  

• Разделение класса на части улучшает кохизи.  

• LCC и TCC объединяются для оценки кохизи.  

• LCC инициирует объединение классов с низкой кохизи.  

• Метрики ко-хижина показывают количество связей между методами и переменными.  

• Чем выше значение метрики, тем плотнее структура класса.  

• Идеальные классы имеют высокие значения ко-хижина.  

• Слабые связи снижают ко-хижин.  

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

• Классы с множеством геттеров и сеттеров имеют низкий ко-хижин.  

• Объекты данных с множеством геттеров и сеттеров имеют нулевой ко-хижин.  

• Такие классы неэффективны и не соответствуют объектно-ориентированному дизайну.  

• Такие объекты лучше рассматривать как структуры данных.  

• Эд хок дизайн означает создание классов по ситуации, а не по плану.  

• Такие классы часто содержат множество концепций и методов.  

• Примеры: классы StringUtils и Apache Commons.  

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

• Такие классы не моделируют сущности реального мира.  

• Метрики ко-хижина помогают выявлять проблемы в таких классах.  

• Метрики ко-хижина должны быть выше 0.5 для улучшения качества кода.  

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

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

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

• Классы с высокой ко-хижиной фокусируются на одной центральной задаче.  

• Абстракция и ко-хижин тесно связаны.  

• Абстракция важна для создания хорошего кода.  

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

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

• Классы должны содержать только те методы, которые относятся к сущности реального мира.  

• Пример: класс автомобиля не должен содержать метод "дидактик мани юзер".  

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

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

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

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

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

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

• Добавление лишних свойств может сделать абстракцию плохой.  

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

• Пример: класс с 20 свойствами вместо необходимых веса и цены.  

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

• Узкая абстракция затрудняет доступ к нужным функциям.  

• Пример: операции с файлом разбросаны по разным местам в коде.  

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

• В Java неправильно реализована абстракция работы с файлами.  

• Линукс сделал это раньше, но не так тщательно продумал структуру.  

• Java-разработчики должны были лучше продумать управление файлами.  

• В Java-скрипте можно смоделировать файл на диске.  

• Программисту нужно знать и уметь работать с файлом.  

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

• Программисту не нужно знать все детали работы с файлом.  

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

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

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

• Абстракция должна быть контролируемой и не расширяемой.  

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

• Абстракция — ключевая концепция в объектно-ориентированном программировании.  

• Программирование, алгоритмы и тестирование вторичны по сравнению с абстракцией.  

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

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

• Наследование классов и их сравнение по метрикам.  

• Исследование направлено на понимание влияния наследования на ко-хижин.  

• Исследование рассматривает классы, наследуемые через ключевое слово "extends".  

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

• Первый вывод: классы, наследуемые через "extends", имеют более низкое качество кода.  

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

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

• Это противоречит интуиции, что наследование улучшает качество кода.  

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

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

• Это подтверждает, что наследование через "extends" может быть вредным.  

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

• Одна из гипотез: переиспользование кода в дочерних классах приводит к его "растаскиванию".  

• Это может ухудшить качество кода и привести к его деградации.  

• Композиция предлагает альтернативу наследованию через "extends".  

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

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

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

• Исследователи предложили свои метрики и сделали выводы, противоречащие интуиции.  

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

• Комментарий о контроле через наличие конструктора у родителя.  

• Рекомендация не использовать слово "extends" для всех классов.  

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

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

• Интерфейсы помогают программировать через абстракцию.  

• Интерфейс должен быть максимально четким и жестким.  

• Интерфейс абстрагируется от имплементации.  

• Фокус на абстракции, а не на реализации.  

• Интерфейсы помогают лучше понимать модель программы.  

• Интерфейсы должны быть небольшими и выделенными в отдельный пакет.  

• Модель программы должна быть отделена от реализации.  

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

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

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

• Имплементация следует за дизайном и моделью.  

• Кохижина напрямую связана с ин-хритенсом.  

• Ин-хритенс считается злом.  

• Саптайпинг - это другой механизм, когда интерфейс наследует интерфейс.  

• Обсуждение типов и классов в Java.  

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

• Полиморфизм и его роль в объектно-ориентированном программировании.  

• Моделирование новых типов на основе существующих.  

• Уточнение типов и их свойств без копирования функционала.  

• Полиморфизм как основа объектно-ориентированного программирования.  

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

• Пример инструмента для Java, созданного совместно с университетом.  

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

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

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

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

• Инструменты помогают избежать субъективности в оценке кода.  

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

• Метрики помогают программистам учиться на основе проверенных знаний.