Курсовая работа на тему: Выявление ошибок и рефакторинг программы расчета среднего балла

Систематические ошибки часто связаны с некорректными инвариантами: например, смешением форматов оценок (целые/дробные), неправильным выбором множителя при взвешивании (веса применяются не к тем данным), а также ошибками в расчёте количества элементов (деление на число дисциплин вместо числа оценок с весами). Для выявления таких дефектов полезно формализовать модель: определить, какие поля участвуют в сумме и нормировке, затем проверить согласованность единиц измерения и граничных случаев (нулевые веса, пустые списки, дубликаты). Предварительная проверка включает аудит формул и ручные прогоны на минимальных контрпримерах.

Наиболее результативны property-based тестирование и параметризованные тесты: они системно перебирают классы входов и проверяют свойства результата, например монотонность при добавлении улучшающих оценок или корректность при масштабировании весов. Для крайних случаев важно отдельно тестировать поведение с отсутствующими оценками, невалидными строками, а также NaN/Infinity, если в программе возможны математические операции с ненормальными числами. Отдельный слой составляют тесты на устойчивость округления: сравнение с эталоном с учётом выбранной политики округления.

Оптимальной считается декомпозиция по ответственности: выделение чистой вычислительной функции (например, вычисления среднего по набору оценок и весов) и изоляция UI/IO в отдельных модулях. Это влияет на выявление ошибок, потому что чистая функция легче покрывается тестами, а также позволяет быстрее локализовать дефекты в конкретном этапе пайплайна. Кроме того, рефакторинг к более тестируемой архитектуре снижает риск регрессий: при изменении вычислительной логики вы проверяете только вычислительный контракт, не трогая ввод и отображение.

Маскируют дефекты дублирующиеся фрагменты формул, ветвления с неочевидной логикой округления, а также смешение типов (например, неявные преобразования строк в числа) и “магические числа” в коэффициентах. Статический анализатор помогает выявить неиспользуемые переменные, потенциальные ошибки преобразования типов, нарушения контрактов и возможные нулевые деления. Дополнительно полезны средства поиска “смежных” проблем: например, отслеживание несогласованности единиц (баллы vs проценты) или несоответствия названий переменных их смыслу.

Исторически логика расчёта в учебных системах эволюционировала от простых средних арифметических без весов к более сложным моделям: взвешивание по сложности курса, учёт попыток, исключение/временное “замораживание” оценок, а также переход на стандартизированные формулы. Нередко в наследуемом коде сохраняются старые допущения, которые теперь вступают в конфликт с актуальной методикой. Поэтому исторический контекст помогает понять, почему ошибки “не всегда выглядят как баг”: они могут быть следствием несостыковки между методикой и реализацией.

Рефакторинг часто затрагивает порядок операций, политику округления и формат представления чисел (например, переход от float к decimal), что влияет на погрешность и итоговую величину. Чтобы минимизировать риск, нужно зафиксировать контракт расчёта: описать формулы, правила округления, обработку исключений и политику по отсутствующим данным. Затем выполняется серия “сравнительных” прогонов: результаты на репрезентативном наборе входов должны совпасть (или быть объяснимо отклонены в рамках допустимой погрешности) до внесения функциональных изменений.

Спорность обычно связана с педагогической интерпретацией: арифметическое среднее чувствительно к выбросам, геометрическое — к нулевым значениям и иначе отражает “совокупный уровень”, а взвешивание требует чёткой методики определения весов. Отдельные дискуссии возникают вокруг исключения крайних оценок или игнорирования пропусков: с одной стороны, это повышает устойчивость, с другой — может искажать реальную успеваемость. На практике важно закрепить методику документально и согласовать её с целями оценивания, иначе рефакторинг будет воспроизводить не только кодовые, но и методические несоответствия.

Лучший подход — разделить доменную валидацию и вычисление: вычислительная функция принимает уже валидированные структуры данных и не занимается форматированием ошибок. Валидация выполняется отдельным слоем, который возвращает структурированный результат (например, либо успешный набор оценок, либо список нарушений). Такая схема повышает тестируемость и снижает вероятность “скрытых” дефектов, когда некорректные входы приводят к неочевидным численным артефактам вроде NaN или деления на неверное количество элементов.