SQM 9/24: CAMC and NHD (cohesion metrics)

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

• Рассматриваются две метрики: кохижин и другие.  

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

• Автор предлагает исследовать эту тему и создать свою метрику.  

• Автор предлагает студентам придумать свою метрику, имплементировать ее и сравнить с другими метриками.  

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

• Рейшн Юни Файт Процесс - это фреймворк или система принципов и правил для разработки софта.  

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

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

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

• Тестирование - это проверка продукта на ошибки и создание баг-репортов.  

• Рефакторинг - это улучшение кода без изменения его функциональности.  

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

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

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

• Дипломент - это процесс отправки софта заказчику.  

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

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

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

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

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

• Две метрики оценивают ко хижин класса исходя из его интерфейса.  

• Они игнорируют имплементацию и оценивают только сигнатуру методов.  

• Пример: интерфейс с пятью методами, каждый с определенными параметрами.  

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

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

• Чем меньше ко хижин, тем лучше дизайн класса.  

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

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

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

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

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

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

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

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

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

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

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

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

• В Java есть абстрактный класс InputStream, который имеет три метода для чтения данных из потока.  

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

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

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

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

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

• В примере с файлом input stream, реализованным в Java, есть три метода: read, readInto и readFully.  

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

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

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

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

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

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

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

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

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