Дорога реконструкции передней части Koala PC
@(рефакторинг)[компонентный|разделенный]
РефакторингЭто неизбежная работа в непрерывном функциональном процессе итерации продукта. так называемый重构, заключается в оптимизации и корректировке внутренней реализации без изменения ввода и вывода программы, то есть в обеспечении существующих функций. Каждый разработчик за свою карьеру в той или иной степени занимался рефакторингом. Это может варьироваться от переписывания функциональной функции или бизнес-компонента до рефакторинга сложного функционального модуля или рефакторинга всего сайта.
Рефакторинг требует определенных затрат и усилий, особенно если есть различные исторические проблемы (использовались старые фреймворки или инструменты), и перемешана различная бизнес-логика (некоторая функциональная логика может быть даже не понятна заказчику), и важные функциональные модули с плохая читабельность и ремонтопригодность, типа страницы заказа Коалы, не двигаются, и каждый раз при итерации функции есть желание врезаться в стену, а работы много.И есть определенные риски. Конечно, длительная боль хуже, чем кратковременная, в долгосрочной перспективе реконструкция обязательна.
зачем рефакторить
- Неразумный дизайн или отсутствие дизайна вообще: первоначальный метод реализации нецелесообразен, или режим разработки без разделения модулей и извлечения компонентов, а также разработка стекирования чистой бизнес-логики приведет к неиспользуемым функциям, избыточному коду и неблагоприятному обслуживанию.
- Связь структуры страницы и реализации функций: файл скрипта перемешан с различными html-структурами, а производительность и поведение не разделены, что сильно снижает читабельность и ремонтопригодность кода. (Не скажу, что скрипт входа на одну страницу старой версии Коалы больше 2000 строк, плачь~).
- Код трудно понять: На странице нет четкой функции входа, а отношения вызовов функций хаотичны.Будь то изменение ошибок или итерация новых функций, эффективность разработки низкая перед лицом непонятного кода.
- Код, вызывающий проблемы с производительностью: Если неразумный метод реализации или большое количество бесполезного избыточного кода вызывает явные проблемы с производительностью, его необходимо немедленно реорганизовать и оптимизировать.
- Обновление фреймворка или библиотеки классов: Фронтенд-техфреймворк меняется с каждым днем, рефакторинг тоже задействован при выборе или исключении сторонних библиотек, не подходящих для проектов.
при рефакторинге
На самом деле рефакторинг можно сделать в любое время. Когда вы чувствуете, что код становится менее читабельным, повторно используемым и ремонтопригодным, вам следует сознательно провести рефакторинг. В большинстве проектов следующие моменты времени для рефакторинга были бы разумными:
- Во время итерации функции: при добавлении функции обнаруживается, что первоначальный дизайн не соответствует новым требованиям, и может быть рассмотрен рефакторинг, при проектировании функциональных компонентов интерфейсы могут быть зарезервированы для возможных будущих требований;
- При исправлении ошибок: после того, как ошибка возникла, вам нужно подумать о том, не является ли это проблемой, вызванной необоснованным кодированием, а не просто решить ошибку (конечно, если есть серьезные онлайн-ошибки, первоочередной задачей является их исправление в реальном времени). Когда появляется возможность, можно четко выстроить бизнес-логику, а бэкенд использовать для изменения интерфейса при необходимости;
- Стадия обзора кода: эта стадия часто ближе ко времени тестирования, но если это явно необоснованная идея реализации, лучше перепроектировать и реализовать задержку; если достаточно раннего обдумывания, такая ситуация обычно не возникает, и большинство из них для Когда другие люди просматривают его, они находят его непонятным и плохо читаемым, что также нуждается в дальнейшей доработке и переписывании.
Конечно, когда нужно срочно, рефакторинг не подходит.
сделать рефакторинг
Возьмем в качестве примера одностраничный рефакторинг Koala.
При любой реконструкции вы должны иметь полное представление о существующей бизнес-логике, оценить влияние и возможные риски реконструкции, а также перечислить основные функциональные точки (которые также можно использовать в качестве контрольных регрессионных точек для обеспечения качества), чтобы гарантировать, что будет без проблем после реконструкции Функциональные упущения, без изменений существующего функционала.
Как понять существующую бизнес-логику?
- Процесс на стартовой линии (какая-то особая логика, сложно моделируемая)
- Сравните с существующим интерактивным черновиком (непрерывная итерация функций, может не найти полный интерактивный черновик)
- Прочитайте существующий код (лучший способ полностью понять бизнес-логику, но отнимает много времени)
- Спросите у предыдущего застройщика (если ушли, узнайте, есть ли акт приема-передачи и т.д.)
Разделение функционального модуля
После полного понимания бизнес-логики функция может быть разделена, а повторно используемая, независимая от функции бизнес-логика может быть извлечена как компонент или общий шаблон, и необходимо учитывать взаимодействие между компонентами. После разделения несколько человек могут развиваться параллельно, и можно согласовать интерфейс для внешних вызывающих компонентов.
Ниже представлено разделение функциональных модулей на странице заказа:
В соответствии с полем синхронизации orderType определите, является ли это обычным товарным заказом или заказом на пополнение счета, и инициализируйте соответствующие компоненты; в соответствии с информацией о синхронизации асинхронно получите информацию о заказе (включая информацию о товаре и информацию о расчетах); если это обычный товарный заказ, сервер будет. Пользователь выбирает адрес для разделения заказа и возвращает информацию о товаре и расчетах после разделения заказа. После разделения по функциям компоненты и их отношения вложенности выглядят следующим образом:
Структура одностраничного каталога:
javascript
|——components
| |——address/address.js //地址控件
| |——checkcode/checkcode.js //验证码控件
|——page/order
| |——order_confirm.js //入口脚本
| |——components
| | |——confirmGoods.js+html //确认商品信息
| | |——settlement.js+html //结算信息
| | |——exchangeCoupon.js+html //兑换优惠券
| | |——rechargeInfo.js+html //账号充值
| | |——invoiceInfo.js+html //发票信息
| | |——invoice.js+html //设置发票
| | |——bean.html //考拉豆抵扣
| | |——feeList.html //运费税费列表
| | |——gift.html //赠品信息
| | |——useCoupon.js+html //使用优惠券
| | |——submitCB.js //提交回调
| |——widget
| | |——popCoupon.js //弹窗领券после рефакторинга
- Четкая запись, четкие отношения вызова, легко найти
- Реализация функции не связана со структурой, а читабельность улучшена.
- После компонентизации это способствует функциональному повторному использованию
- Улучшение опыта кодирования, обслуживание и итерация функций больше не мучают o (^ ▽ ^) o
last
Рефакторинг никогда не бывает разовым действием, это то, что нам нужно делать постоянно. После многократного сопровождения и непрерывной функциональной итерации в коде будет более или менее место для оптимизации, поэтому, когда вы видите что-то, что нецелесообразно или заслуживает рефакторинга, действуйте и оптимизируйте, не ждите, пока стоимость рефакторинга станет выше. Сделайте это снова, когда ты старше, потому что будет больнее, не спрашивай меня, откуда я знаю.