Автор/Знание: Три отражения в моем теле
Примеры рефакторинга в нескольких бизнес-сценариях
Порядок запроса
В этом сценарии в первую очередь сложность бизнеса определяет сложность кода. Сначала давайте возьмем простой пример того, что возможно во front и Node:
У нас есть четыре функции A, B, C и D, которые запрашивают данные (функция реализует себя), C зависит от результата B, D зависит от результата ABC и, наконец, выводит результат D.
Пример ошибки
Хотя этот код намеренно написан таким образом, его действительно видели некоторые новички. Этот код по-прежнему дает правильный результат, но он уродлив и вызывает ад обратных вызовов. Если люди не проводят рефакторинг позже и все еще существуют зависимости запросов, они должны продолжать вызывать вложенные вызовы. Производительность настолько плоха, что не учитывается, что A и B могут быть параллельными.
Вот введение в самый примитивный обратный вызов... В середине вы можете просмотреть эволюцию всего ES2015+, обратный вызов (async.js) --> Promise --> генератор + co --> async + await. На самом деле, это постоянное упрощение и улучшение нашей способности контролировать асинхронность с уровня нативной грамматики.
Ниже приведено окончательное решение, предоставляемое непосредственно на текущем этапе: на основе Promise + async/await.
правильный пример
Мы немного переосмысливаем приведенные выше задачи, выпрямляя зависимую логическую последовательность. И с последним синтаксисом.
использоватьPromise.allкомбинироватьasync/awaitВ форме параллелизма и сериализации метод написания является кратким и обеспечивает самое быстрое решение в соответствии с требованиями примера. Решена проблема бесконечной вложенности. Это оптимизация, которую мы можем сделать, следуя эволюции самого языка.
Но не только это. Мы классифицируем проблему, извлекая зависящие от порядка запросы от B и C к отдельным функциям. Пусть разбираются со своей логикой. Мы упомянем об этом позже.
пытать, если еще
Могут существовать следующие проблемы
слишком много вложенности
Логическая избыточность обработки
Не заниматься защитным программированием (обработка ошибок)
Давайте возьмем пример кода напрямую. Это метод получения цвета фона. Однако с постоянным изменением бизнеса появляется все больше и больше источников цвета фона. При обработке некоторого делового персонала это может быть так:
Пример ошибки
Я считаю, что это очень болезненно, когда вы читаете приведенный выше код, в принципе невозможно сразу понять, какая ветка в конечном итоге войдет. Таким образом, исходя из следующих двух принципов
Разумное извлечение в функции
Возврат приоритета ошибки
С базовой версией рефакторинга:
правильный пример
Вы можете увидеть всю логику, которая была реорганизована. Он разделен на три функции, причем подметоды имеют дело с логикой соответствующего уровня соответственно, а основной метод отвечает за планирование. Все стало ясно с первого взгляда.
Конечно, после того, как мы провели рефакторинг на основе вышеизложенных принципов, есть ли проблемы с этим кодом? Есть конечно. Как видите, все три наши функции зависят от глобальных переменных. Сама функция не является чистой. Если это глобальная проблема, устранить ее все равно непросто.
Мы можем изменить его, чтобы он стал чистой функцией, чтобы упростить понимание и тестирование этого фрагмента кода.
Возьмем в качестве примера модификацию функции: мы превратили глобальную переменную в параметр, и нужно только передать глобальную переменную при вызове, но таким образом мы получаем чистую функцию.
Почему здесь подчеркивается этот момент?На самом деле, одна из самых основных проблем функционального программирования — это чистые функции. Только тогда вход и выход могут быть наблюдаемыми, а вход должен иметь выход. Только так в системе будет все меньше и меньше нечистых функций. Сделайте код более легким для тестирования.
Конечно, если мы думаем с точки зрения реконструкции, мы также должны обратить внимание на этот момент:
Логика здесь установит последние совпавшие данные в bgColor. (Мы все знаем, что find indexOf и т. д. в основном сопоставлялись в прошлом.) Действительно ли это требование бизнеса?
Можно видеть, что процесс написания/рефакторинга бизнес-кода на самом деле является еще одним улучшением бизнес-логики и понимания бизнеса. Будь то дизайн извлечения в функцию или сначала возврат ошибок, это действительно может решить такую проблему: вы можете понять подробную логику определенной области, не читая всю картину, что делает код легким для понимания и модификации.
... Даже после такого рефакторинга код здесь все еще имеет место для дальнейшей оптимизации, такой как наименования функций и параметров, полные тестовые примеры и т. д., ограниченные объемом статьи, и пока не будут объясняться существование.
Другие возможные проблемы в каком-то коде
-
Логика связана на уровне представления.
a === 'a' && b ==='b' && c==='c' && d ==='d'? <div>...</div>:null Повторное использование компонентов, повторное использование функций, отсутствие инкапсуляции, дублирование кода.
Функции не монолитны, и на одну функцию возлагается слишком много обязанностей. И эти обязанности никак не связаны между собой, но все они сцеплены в одном блоке.
Список параметров сбивает с толку, есть защитное программирование, а ошибки не обрабатываются (ошибки интерфейса, тайм-ауты, повторные отправки и т. д.).
Волшебные числа, волшебные строки и никакого описания.
Плохие структуры данных/неправильное именование (на самом деле приведенный выше пример кода также существует)
Умственная подготовка к оптимизированному коду
Прежде всего, почему вы говорите, что вам нужно оптимизировать код?
техническое преследование.
Компания требует, чтобы система использовалась онлайн. Есть пользователи, которые его используют, но если вы не напишете его хорошо, на самом деле пострадаете вы сами.
В командной работе, если я плохо пишу, другие члены команды тоже плохо пишут, и от меня страдает порочный круг.
Итерируйте быстро. В систему необходимо постоянно добавлять новые функции. Для этого нужно написать хороший код.
Мнения других, я боюсь, что другие подумают, что мои технические способности плохие... хххх....
У вас будут следующие требования:
Простая для понимания архитектура системы
Легко понять жизненный цикл и поток выполнения системы
Легко понять, что делает каждая функция
Легко понять, как вызываются и передаются функции (ввод и вывод).
Легко понять значение переменных, значение выражений.
Легко расширить...
В конце концов, это фактически сводится к написанию кода, который должен быть чистым кодом, который легко понять/модифицировать/проверить. (На самом деле здесь в большинстве случаев подразумевается условие совместной работы персонала, поэтому код необходимо писать хорошо, не переинкапсулируя его, чтобы другие члены команды не могли его понять (конечно, если некоторые у людей не хватает опыта, значит это Его собственные проблемы, ему надо усиливаться.))
несколько советов
Четче понять бизнес и подумать о возможных изменениях. Подумайте и спроектируйте четко, прежде чем сделать это.
Ознакомьтесь с некоторыми проектами с открытым исходным кодом и лучшими отраслевыми практиками, чтобы понять, что такое хороший код, а что — плохой.
Истеблишмент понимает, что, хотя код предназначен для запуска на компьютере, в конечном итоге его должен прочитать человек. Не только без ошибок, ментальные модели вроде этой.
Создайте модель мышления, в которой бизнес так же важен, как и качество кода. Избегайте кода, который должен быть написан таким образом из-за времени.
Поймите, что сам обзор кода может быть в состоянии найти и указать некоторые проблемы, но окончательная реализация все еще зависит от вас. Это не может стать форматом, но должно быть интегрировано в ваше собственное мышление.
Используйте принцип «сначала ошибка». Насколько это возможно, сначала дайте ошибке вернуться, чтобы позже вы получили чистый код. (При написании кода необходимо учитывать не только прямые, но и обратные суждения)
Разумно разделить на независимые функции. Очистить ввод и вывод, обработку ошибок и другую обработку внутри функции. (Например, в некоторых сценариях действительно будет много логических суждений. В первую очередь нужно подумать о том, можно ли классифицировать и дробить предложения внутри суждения)
Для суждения и объединения нескольких состояний можно использовать комбинированную таблицу состояний (таблицу карт), конечный автомат и другие режимы.
Узнайте о шаблонах проектирования и рефакторинге.
Рефакторинг! ! Пока вы думаете, что с местом что-то не так, не откладывайте на потом. Часто никогда больше.
Заканчивать
Говоря о том, что может чувствовать себя резко остановленным. В этой статье мы сначала используем два конкретных примера оптимизированного кода в качестве введения, чтобы каждый мог понять некоторые идеи оптимизации бизнес-кода. После этого перечислены некоторые другие возможные ошибки, а также мысленная подготовка и теоретические рекомендации по оптимизации кода. На самом деле, я надеюсь, что каждый сможет найти проблемы в бизнесе, а потом подумать, как их решить, ведь так много сказано, умеешь ли ты хорошо писать код? все еще зависит от себя