ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ

Ордена Трудового Красного Знамени

Федеральное государственное бюджетное образовательное учреждение высшего образования

МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СВЯЗИ И ИНФОРМАТИКИ

ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Кафедра «Программная инженерия»

Лабораторная работа №3

по дисциплине «Рефакторинг баз данных и приложений» на тему

«Изучение рефакторинга приложений»

Выполнил: Студент гр. БПИ 2304

Афанасьев А.C.

2025

Цель работы

1. Ознакомиться с основными принципами и задачами рефакторинга.

2. Научиться выявлять проблемные участки кода (code smells) и устранять их.

3. Применить техники рефакторинга для улучшения читаемости, структуры и

производительности кода.

4. Развить навыки анализа и улучшения существующего кода.

Задание

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

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

список проблемных мест, которые требуют рефакторинга.

3. Примените техники рефакторинга для устранения выявленных проблем.

4. Подготовьте отчет, включающий описание исходного состояния кода (с примерами

проблемных участков), внесенные изменения (с пояснениями и обоснованием), итоговое

состояние кода.

5. Проверьте, что после рефакторинга программа работает корректно. Если возможно,

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

Ход выполнения

Я подготовил пример лабораторной работы с проектом около 150 строк кода на Python в Visual Studio Code. Проект будет представлять собой программное приложение, предназначенное для автоматизированного анализа успеваемости студентов на основе их оценок. Мы проведем рефакторинг и последовательно загрузим код на GitHub.

Рисунок 1. Исходный код

Рисунок 2. Исходный код

Рисунок 3. Исходный код

Рисунок 4. Модель студента Student.py после рефакторинга

Рисунок 5. Логирование действий – DebugLogger.py

Рисунок 6. Логика анализа оценок – GradeAnalyzer.py

Рисунок 7. Экспорт данных в разные форматы - Exporter.py

Рисунок 8. main.py

Рисунок 9. Проверка работоспособности кода

Рисунок 10. Загрузка исходного когда на гит

Рисунок 11. Загрузка всех изменений на гит

Подробное описание изменений

­­1.Code smells в исходной версии

1. Long Method (слишком длинный метод `calculate`)

2. Duplicated Code (повторяющаяся логика в `save_to_txt` и `save_to_json`)

3. Primitive Obsession (использование примитивных типов вместо объектов)

4. Magic Numbers (жестко закодированные числа, например `3` для проверки сдачи)

5. Feature Envy (методы класса зависят от данных другого класса)

6. Data Clumps (группы переменных, которые всегда используются вместе)

7. Shotgun Surgery (одна правка требует изменений в нескольких местах)

8. Inappropriate Intimacy (методы знают слишком много о внутренностях других классов)

9. Poor Error Handling (использование общего `Exception` вместо специализированных)

10. Hard-Coded Strings (строковые константы прямо в коде)

3. Проведенный рефакторинг

3.1. Разделение логики на классы

Вместо одного "монолитного" класса StudentCalculator созданы:

Student (хранит данные студента и вычисляет его статистику)

GradeAnalyzer (отвечает за анализ оценок)

Exporter (отвечает за экспорт в разные форматы)

DebugLogger (логирование)

3.2. Устранение Duplicated Code

Были выделены интерфейсы IExportStrategy и IAnalyzerStrategy для гибкой работы с экспортом и анализом.

3.4. Улучшенная обработка ошибок

Вместо общего Exception теперь используются:

class InvalidExportFormatError(Exception): pass

class InvalidStudentDataError(Exception): pass

3.5. Избавление от Feature Envy

Логика анализа оценок перенесена в GradeAnalyzer.

Логика экспорта в Exporter.

3.6. Data Clumps

Раньше данные студента (name, grades) могли передаваться отдельно в разные функции, что создавало дублирование, а теперь данные инкапсулированы в классе Student

3.7. Shotgun Surgery

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

Теперь вся логика экспорта — в Exporter, вся логика анализа — в GradeAnalyzer.

3.8. Inappropriate Intimacy

Если бы GradeAnalyzer напрямую менял оценки студента (student.grades = [...]), это нарушало бы инкапсуляцию.

GradeAnalyzer только читает данные через публичные методы Student:

3.9. Poor Error Handling

Раньше могли быть "голые" try/except без конкретных исключений, а сейчас добавлена проверка в GradeAnalyzer

4. Вывод

В ходе выполнения данной лабораторной работы нам удалось устранить smell-коды (длинные методы, плохие имена и т.д.), улучшить архитектуру (разделение на классы, SRP), повысить надежность (обработка ошибок), сделать код более гибким (легко добавить новые функции).

Теперь код соответствует SRP, DRY и KISS принципам

Ссылка на гит - https://github.com/andsee18/labrefact3