Как вы думаете, что вызывает у людей наибольшее нетерпение, когда они перенимают устаревший код? Чрезвычайно сложный UML? Я так не думаю. Мой ответ: если с более чем двумя else или переключиться с более чем двумя случаями. Но нормально ли использовать в коде много операторов if else и переключать регистры ? неправильный! Большинство случаев if else и switch с более чем двумя ветвями не должны отображаться в жестко закодированной форме.
Откуда берутся сложные ветки?
Прежде всего, первый вопрос, который мы хотим обсудить, — почему в унаследованном коде часто бывает так много сложных ветвей. Эти сложные ветки часто не существуют в первой версии кода. Предполагая, что у проектировщика еще есть некоторый опыт, ему следует предусмотреть области, которые, возможно, потребуется расширить в будущем, и зарезервировать абстрактные интерфейсы.
Однако после того, как код пройдет несколько итераций, особенно после нескольких корректировок деталей требований, появятся сложные ветки. Детальные корректировки требований часто не отражаются в UML, а непосредственно отражаются в коде. Например, сообщения изначально были разделены на две категории: сообщения чата и системные сообщения. При проектировании они естественным образом были спроектированы как две подкатегории категории сообщений. Но однажды требования детально корректируются. Некоторые системные сообщения важны и их заголовки должны отображаться красным цветом. В это время программисты часто вносят следующие изменения:
Добавьте важный атрибут в класс системных сообщений
Добавьте ветку о важном атрибуте в соответствующий метод рендеринга, чтобы управлять цветом заголовка. Зачем программисту вносить такие изменения? Возможно, это потому, что он не осознавал, что это должно быть абстрактно. Поскольку в требовании говорится, что «некоторые системные сообщения важны», для программистов, прошедших дополнительную подготовку в области императивных языков программирования, первое, о чем они могут подумать, это бит флага - бит флага может различать важные и неважные сообщения. . важный. Он не ожидал, что это требование можно интерпретировать по-другому: «Системные сообщения делятся на две категории: важные и неважные». Интерпретируя это таким образом, он знал, что системные сообщения следует абстрагировать.
Конечно, возможно, что программист знает, что абстракция возможна, но по какой-то причине предпочитает этого не делать. Очень распространенная ситуация: кто-то заставляет программистов жертвовать качеством кода в обмен на скорость выполнения проекта — добавление свойства и ветки намного проще, чем абстрактный рефакторинг. Если вы хотите сделать 10 таких форм Modify, быстрее ли сделать 10? ветки или 10 абстракций? Разница очевидна.
Конечно, если «если» слишком много, некоторые умные люди встанут и скажут: «Почему бы нам не заменить его на переключатель?» В некоторых случаях это действительно может улучшить читаемость кода, если предположить, что каждая ветвь является взаимоисключающей. Но когда количество случаев переключения увеличится, код тоже станет нечитабельным.
Каковы недостатки сложных ветвей?
Каковы недостатки сложных ветвей? В качестве примера возьму фрагмент старого кода веб-версии Baidu Hi.
переключатель (json.result) {
случай «ок»:
переключатель (json.command) {
случай «сообщение»:
случай «системное сообщение»:
если (json.content.from == ""
&& json.content.content == "выгнали") {
/* отключиться */
} else if (json.command == "systemmessage"
|| json.content.type == "sysmsg") {
/* отображаем системное сообщение */
} еще {
/* отображаем сообщение чата */
}
перерыв;
}
перерыв;
Источник: опыт всех пользователей Baidu.