«... он думает, что языка Блаб достаточно, и на данный момент его разум ассимилирован языком Блаб» — Пол Грэм
предисловие
Мне не нравится бизнес-код в стиле космического челнока.if/elseзаявление сложное и раздутое, по крайней мере эстетически,switchчемif/elseГораздо более элегантно. Если сравнивать языки, я думаю, что сопоставление с образцом ReasonML более распространено.switchУтверждения слишком сильны. Различные способы написания сложных суждений в JS вызывают разные чувства. В этой статье я кратко представлю несколько способов замены if/else. Только если вы знакомы с другими идеями кода, чтобы расширить наше мышление,Если мы не изучим больше возможностей написания кода, возможно, мы станем людьми, которыми управляет код..
if/else
В качестве примера возьмем процесс послепродажного обслуживания.После покупки продукта пользователь может обратиться к продавцу за послепродажным обслуживанием из-за неправильных или отсутствующих деталей/проблем с качеством/несогласованных описаний и т. д., что может включать послепродажное обслуживание, например как возврат/возврат/обмен/переоформление службы поддержки, послепродажное обслуживание продавца также повлияет на предпочтения пользователя для продавца.В таком сценарии мы предполагаем следующий псевдокод:
В этом сценарии содержание каждой службы послепродажной поддержки, основанное на причинах послепродажного обслуживания, отличается. Например, пользователи не могут выбрать услугу по замене, когда есть неправильные детали или недостающие детали. Таким образом, наше условие суждения становится[售后原因 * 售后支持服务]Двумерный список В настоящее время, в соответствии с различными причинами послепродажного обслуживания и службами послепродажной поддержки, условия суждения должным образом обновлены до трехмерных:[售后原因 * 售后支持服务 * 用户喜好]
Очевидно, что оператора if/else недостаточно в этом тяжелом месте бизнес-логики, основные причины заключаются в следующем:
-
Состояние после вынесения приговора, то есть в
} else if (serviceReason === '质量问题') {В предложении нам обычно приходится находить условие суждения в конце строки, а некоторое содержание не поддерживается выделением, поэтому его часто смешивают с обычным кодом следующей строки, делая его ослепительным и неузнаваемым. - Отступ кода не ясен, Когда количество слоев суждения увеличивается или содержимое фигурных скобок удлиняется, то при чтении кода всегда сложно найти конечную позицию, соответствующую оператору if.
-
экстравагантные разрывы строк, когда логика в операторе if/else короткая, например
else { user.love(-5 }Этот код, занимающий 3 строки, кажется слишком экстравагантным.
Тернарный оператор/выражение короткого замыкания
В некоторых простых выражениях для упрощения суждений можно использовать тернарные операторы или сокращенные выражения, например:user.loveВызов этой функции можно выделить в отдельное предложение, поэтому следующее суждение можно полностью упростить:
Оператор запятой
С помощью круглых скобок и оператора запятой мы можем стать оператором выражения для выполнения гибкого использования оператора запятой, который может поддерживать три проекта или сократить некоторые из более сложных ситуаций:
Однако приведенный выше код не рекомендуется использовать в стандартной спецификации. ESLint предупредит вас о преобразовании этой строки в нотацию if/else. Конечно, вы также можете изменить спецификацию ESLint, чтобы отключить предупреждение, если вы (и команда участник) мне нравится этот способ письмаНе упрощайте ради простоты.
switch/case
Имея дело со сложными суждениями, состоящими из нескольких ветвей, большинство людей предпочитают использовать switch в качестве альтернативы длинному if/else Что вы думаете о следующем способе написания?
К сожалению, кажется, что оператор switch не намного лучше, чем if/else.Единственное, что я хочу подчеркнуть, в приведенном выше примере все места, связанные с ключевым словом суждения (такие как switch, case, &&, это код- высокая яркая область), почти все они существуют в первых двух словах в начале каждой строки Пока что switch лучше, чем if/else с точки зрения сложности поиска условий суждения, хотя это преимущество будет варьироваться в зависимости от As увеличивается количество ветвей суждения, оно постепенно расходуется (а жаль).
На самом деле есть еще одно место, о котором мне жаль: оператор switch нельзя использовать с оператором короткого замыкания.
В конце концов, это немного неудобно, поскольку использование проверки if увеличивает отступ.Теперь давайте посмотрим на более краткий способ мышления.
Отделение данных конфигурации от бизнес-логики
Нет никаких предварительных условий для разделения данных конфигурации и бизнес-логики (далее именуемого разделением логики конфигурации), и, как и тернарное выражение короткого замыкания, вы можете начать использовать его в своем коде в любое время. логики конфигурации обычно необходимо определить конфигурацию данных для хранения объекта и определитьflagВ качестве ключа конфигурации значением конфигурации может быть любой тип значения, такой как функция, массив и т. д. В месте, где выполняется логика, необходимо только сопоставить условие оценки сflagСравнивая, вы можете получить метод бизнес-логики при текущих условиях суждения:
У вас есть светлое чувство?
В приведенном выше фрагменте кода мы разделяем конфигурацию данных каждого состояния и код, который выполняет бизнес-логику на определенном уровне, что делает длину кода намного короче.С помощью оператора запятой мы можем одновременно выполнять функции бизнес-логики и возвращает оценку изображения пользователя для магазина.
Если вы не хотите быть столь радикальным, возможно, следующий код будет хорошей практикой:
Более гибкая конфигурация данных
В предыдущем разделе для конфигурации данных использовались объекты.Если есть одно сожаление, то есть, хотя значение атрибута может быть любого типа, сам атрибут может быть только строкового типа, что делает его невозможным для нас в некоторых сценариях. Хорошо играть роль разделения конфигурационной логики.Представьте себе следующий сценарий: В конце каждого месяца продавец будет выбирать фанатичных фанатов (с уровнем любви больше или равным 100), чтобы отправить сообщение «Спасибо " и дают купон на 10 юаней, обычные фанаты (оценка 0-100)) отправляют сообщение "спасибо", черные фанаты (оценка меньше 0) отправляют "извините" и дают купон на 10 юаней.
Подождите, показатель привлекательности переменный!
Очевидно, что мы не можем использовать объекты для обработки таких данных (пока я не сумасшедший), например:
Пьянящий, так сложно использовать if/else? Плохая новость: может быть, да.
Однако я должен подчеркнуть, чтоЕсли условие суждения достаточно сложна——Например, продавцы не только дают купоны, но и отправляют QQ красные бриллианты/зеленые бриллианты/желтые бриллианты/… кучу подарков, которые нужно оценивать по разным оценкам фанатов.——Использование if/else по-прежнему будет сталкиваются с нами в первую очередь такие проблемы, как путаница кода, упомянутая в разделе.
Итак, хорошая новость заключается в том, что использование разделения конфигурационной логики может справиться с более сложными и запутанными сценариями (и вы тоже должны это делать). Помните легкое сожаление, о котором мы только что упомянули, что «сами свойства могут быть только строками»? Теперь нам придется исправить это! Взгляните на следующий код:
Использование Map для конфигурации данных — отличный способ написать, но если вы должны быть совместимы с IE, вы должны рассмотреть возможность использования других структур данных вместо Map:
Все различные стили кодирования, которые мы упоминали в двух подразделах выше, следуют концепции создания «конфигурации» на шаг впереди суждения.В реальном бизнесе вы также можете попытаться смешать логическое разделение конфигурации и общие условия суждения.Настраивать ли ведущую оценку или оценивать ведущую конфигурацию.
послесловие
В этой статье в основном представлены несколько способов замены if/else в распространенных сценариях, таких как тринокулярный оператор + запятая, использование массива object/Map/double для разделения данных конфигурации и бизнес-логики, хотя идея обработки бизнес-логики — это то же самое, но фактическое ощущение написания каждого метода отличается, что лучше, а что хуже, пожалуйста, внимательно попробуйте.
Наконец, если эта статья может натолкнуть вас на размышления о коде,это не могло быть лучше, Если есть какие-либо неуместности в тексте, просьба указать и добавить в комментариях.
производительность кода
Я на самом деле не изучал производительность цены на все виды письма, заинтересованные друзья могут попытаться копать 👍