Сохранение поведения включает внешние данные
Рефакторинг обычно понимают как улучшение устройства кода с сохранением значимого наблюдаемого поведения. Если другой участник системы ожидает определённое поле сообщения, его имя относится к такому поведению. Внутреннее переименование может стать внешним изменением, если формат автоматически зависит от имён в коде. Компилятор проверяет доступные ему связи, но внешний клиент может быть написан отдельно и не участвовать в сборке. Дополнительные зависимости бывают в конфигурации, строковых значениях и механизмах отражения. Поэтому отсутствие ошибок сборки подтверждает только часть необходимых условий, а не совместимость всего взаимодействия.
Сериализатор имеет собственные правила
В System.Text.Json имена свойств по умолчанию сохраняются при сериализации, включая регистр; при этом веб-настройки по умолчанию используют стиль с маленькой первой буквой. Конкретный результат зависит от применённых настроек. Если имя свойства в коде изменилось, соответствующее внешнее имя тоже может измениться. Атрибут JsonPropertyName позволяет явно задать имя отдельного свойства в JSON. Это имя применяется при сериализации и десериализации и имеет приоритет над политикой именования. Такой механизм помогает отделить внутреннее название от согласованного внешнего. Однако он не решает автоматически вопросы типов, обязательности данных и поведения других сериализаторов.
Проверяйте границу до и после изменения
В вымышленном ответе клиент ожидает поле displayName. Команда хочет назвать внутреннее свойство иначе, сохранив формат обмена. Перед изменением полезно зафиксировать пример ответа и убедиться, что он соответствует реальному контракту. После — сравнить результат сериализации и проверить чтение прежнего входного сообщения, если оно используется. Проверка должна соответствовать требованию. Если требуется именно сохранение внешнего имени, недостаточно теста, который создаёт объект и читает его новое свойство внутри того же приложения. При намеренном изменении контракта нужен отдельный план совместимости. Смешивание такой перемены с внутренней уборкой затрудняет понимание причин ошибки и обсуждение последствий.
Попробуйте на практике
Составьте бумажную проверку переименования для вымышленного ответа. Доступ к серверу, установка .NET и публикация приложения не требуются.
- Запишите внешнее требование: клиент должен продолжать получать поле displayName. Отдельно обозначьте внутреннее имя свойства, которое команда хочет изменить.
- Укажите, откуда берётся внешнее имя: из стандартного поведения, политики именования или явного атрибута. Если настройка неизвестна, оставьте вопрос для проверки.
- Опишите два контрольных действия: сравнить исходящий JSON и проверить чтение прежнего входного формата. Не заменяйте их обращением к объекту только внутри программы.
- Разделите изменения на сохраняющие контракт и намеренно меняющие его. Для второго случая запишите необходимость отдельного согласования совместимости.
Как проверить результат. План различает внутреннее имя и внешний формат. Успешная сборка не названа доказательством полной совместимости, а проверки обращены к той границе, которую требуется сохранить.
Частые вопросы
Автоматическое переименование в редакторе всегда безопасно?
Оно помогает обновить известные инструменту связи, но не гарантирует учёт всех внешних потребителей и строковых зависимостей. Нужно понимать границу изменения и проверять значимое поведение.
Явный атрибут имени полностью решает совместимость?
Он решает конкретный вопрос имени свойства для соответствующего сериализатора. Изменения типа, формата значения, обязательности или семантики требуют своих проверок. Одно сохранённое имя не подтверждает неизменность всего контракта.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.