SQM 10/24: Object Dimensions

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

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

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

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

• В языках программирования, таких как Java, C++, C#, Python, Ruby, JavaScript, объекты имеют определенные характеристики, которые можно использовать для анализа качества кода.  

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

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

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

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

• В библиотеке "Кактус" для Java, типичным дизайном является класс с 15 конструкторами и 2 методами.  

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

• Деструкторы обычно существуют только в нескольких языках, таких как C++ и Java.  

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

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

• Идеальное количество типов и интерфейсов - один.  

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

• Наследование через имплемент хэри - это отношение копирования, а не наследования.  

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

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

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

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

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

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

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

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

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

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

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

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

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

• Метрика "отношение методов" говорит о соотношении унаследованных и написанных методов.  

• Если метрика стремится к нулю, это говорит о качественном дизайне.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Метрика "количество чилдов" измеряет количество классов, на которые влияет изменение в одном классе.  

• Чем выше эта метрика, тем больше потенциальных проблем может возникнуть при изменении кода.  

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

• Чем меньше эта метрика, тем меньше активных классов в приложении.  

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

• Чем меньше эта метрика, тем меньше вызовов методов наружу и тем проще поддерживать и разрабатывать код.  

• В целом, эти метрики могут помочь в анализе и улучшении объектно-ориентированного кода.  

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

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

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

• Третья ошибка - отсутствие таксономии или классификации работ, на которые опираются исследователи.  

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

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

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