Реконструировать "дерьмовую гору"? Вы, вероятно, никогда не должны делать это!

Архитектура внешний интерфейс опрос
Реконструировать "дерьмовую гору"? Вы, вероятно, никогда не должны делать это!

предисловие

В недавнем прошлом я видел такое предложение на Zhihu: «Единственный способ контролировать Shishan — это не рефакторинг, абез рефакторинга".
Я думаю, это имеет смысл. Но вместо того, чтобы взять его за ориентир, был проведен полный рефакторинг всего проекта.

рефакторинг

Причины рефакторинга

В конце концов я решил провести рефакторинг, и причины рефакторинга были основаны на следующих аспектах.
Есть четыре причины:

  1. Поддержка лидера, готового платить стоимость и время
  2. ПроектПроект АполностьюcopyкПроект Б,а такжеПроект Биспользуется толькоПроект Асередина1/4функция
  3. Этот проект используется с другими проектамистек технологийРазница слишком велика, что делает невозможным объединение однотипных проектовАрхитектура проекта
  4. Проект находится в新增/修改функция, это очень больно, потому что код слишком старый

процесс рефакторинга

На самом деле, нельзя сказать, что это реконструкция».дерьмовая гора", больше похоже на переписывание"дерьмовая гора".

  • Организуйте и разберите нужные страницы на задачи.
  • Перестроить нижний слой всего проекта, отказаться от непредставленных библиотек, переписать маршрутизацию, инкапсуляцию запросов, инструменты utils, файловую структуру, прокси, ....
  • Переписать страницу за страницей с новой структурой

Рефакторинг онлайн

Когда весь проект рефакторен и запущен. Что-то пошло не так, ммм.... Список вопросов:

  1. Есть ссылка на страницу, которая не была отсортирована, в результате чего страница исчезла.
  2. иметь страницуtitleНаписал опечатку (продолжение темы)
  3. Существует интерфейс запроса данных для страницы, который должен бытьGET, и я тоже отправилGETзапрос, но старый тип запроса кодаPOSTПричина сбоя запроса интерфейса

PS: До того, как появилась проблема 3, я столкнулся с тем, что должно было бытьPOSTТип запроса интерфейсаGETЭта проблема. Но никогда не ожидалGETпоявится типPOSTзапрос интерфейса.

При возникновении проблемы 1 я добавляю страницу как можно скорее
Когда вы столкнетесь с проблемой 2, быстро исправьте опечатки
Когда я столкнулся с проблемой 3, я быстро изменил ее
Но проблем было так много, что при наличии более серьезных проблем система была неприемлема, я решительно откатывал код

Я застрял здесь сейчас, проблема была решена, но я не решаюсь выйти в интернет, потому что я много раз запрашивал страницу для вопроса 3 в тестовой среде, и проблема не возникала. Я обеспокоен тем, что будут другие необнаруженные ошибки.

Меня не волнует сама проблема, но почему я не решаюсь выйти в интернет после того, как проблема возникла.
В итоге делаются следующие выводы:

  1. Руководители надеются, что у проекта не возникнет проблемплавное переключение
  2. Продукт уже онлайнплавная работа, если есть какие-то проблемы с рефакторингом, сложно принять
  3. По сравнению с новыми продуктами пользователиbugменьшая терпимость к внезапному появлению
  4. не испытано
  5. Нет пошагового онлайна, что приводит к централизованному вспышке проблем

Суммировать

Чтобы обеспечить наш рефакторингбез сюрпризовзавершение, нам необходимо прояснить следующие вопросы:

  • Нужно ли его рефакторить?
  • Зачем проводить рефакторинг?
  • Как это должно быть рефакторинг?

Нужно ли рефакторить

Если бы я понял эту истину раньше, я бы не стал ее опрометчиво реконструировать! !

if (项目过于庞大) {
    return 千万不要重构!!
}

if (大块的代码你搞不明白是做什么用的) {
    return 千万不要重构!!
}

if (你在该公司待不到 1 年) {
    return 不需要重构
}

if (你们需要为 KPI 服务 && 重构对 KPI 无益) {
    return 不需要重构
}

if (你的领导不希望你重构) {
    return 不需要重构
}

return 你大概率不需要重构

В большинстве случаев рядовые разработчики не задумываются о рефакторинге.
Когда вы думаете о рефакторинге, вы должны тщательно рассмотреть следующие аспекты:

  • Выгодно ли это для компании
    • В большинстве случаев рефакторинг имеет мало пользы для компании, потому что трудно обеспечить, чтобы"Дерьмовая гора 1.0"прогресс"Дерьмовая гора 2.0"
  • Выгодно ли это самому себе
    • В большинстве случаев польза от рефакторинга намного меньше, чем затраченное время.получить новые знания,Закрепить старые знания
  • Пропорциональны ли затраты и выгоды
    • В большинстве случаев затраты и выгоды от рефакторинга не пропорциональны.
  • Как обеспечить последующий эффект
    • Спецификации оговариваются заранее и гарантируютсяВо время реконструкции + В последующем техническом обслуживанииСтрого соблюдать положения спецификации

Зачем проводить рефакторинг

Когда система стабильно работает на линии, рефакторинг всегда должен иметь вескую причину, и причина не может быть"为了扩展性、维护性", ресурсы, потребляемые крупномасштабным рефакторингом, не могут быть обеспечены всего двумя короткими предложениями.
Вы должны учитывать это только в том случае, если у вас серьезные недостатки хотя бы в одном из следующих пунктов:

  • Неадекватная производительность
    • Существующий код не работает гладко на линии и не гарантирует удобство работы пользователя.
  • Расширяемость
    • Существующий код в принципе не может быть расширен, и его трудно доделать, когда появятся новые требования.
  • стоимость технического обслуживания
    • Существующий код имеет фатальные недостатки в обслуживании, что вызывает всплеск потребности вашей команды в рефакторинге.

иначе:

  • Никто другой не может точно оценить вашу рабочую нагрузку перед рефакторингом
  • При рефакторинге другие люди не могут принять после проблемы
  • После рефакторинга другие не знают о преимуществах рефакторинга

а также:

  • KPI завершен

как провести рефакторинг

рефакторинг ужеплавная работапроекты, мы не можем оставить период времени, полностью зарезервированный для рефакторинга, который долженПотребности бизнесашаг за шагом, иПотребности бизнесаспереди,потребности НИОКРпозади.

Наш рефакторинг следует как минимум следующим принципам:
Перед рефакторингом обеспечить совместимость проекта, обеспечить полное понимание кода, обеспечить разделение задач и обеспечить установление спецификаций;
При рефакторинге гарантированно не повлияетПотребности бизнесаРазработать и обеспечить пошаговое онлайн;
После рефакторинга обеспечьте полное покрытие тестами и поддерживайте строгое соответствие спецификациям.

Это сделано для того, чтобы не появляться в процессе рефакторинга.сюрприз,здесьсюрпризэто нейтральное слово, в вашем процессе рефакторинга не должно бытьсюрприз, для лучшего или худшего.

Перед рефакторингом

Перед рефакторингом проекта мы должны:

  • Для того, чтобы обеспечить рефакторинг проектасовместимостьпровести исследование
  • Для того, чтобы обеспечить рефакторинг проектабежать стабильноУглубленное чтение кода
  • Чтобы обеспечить своевременность проекта,время реконструкцииделать точные оценки
  • Уточните масштаб обновленных модулей онлайн-процессов, чтобы избежать слишком большого или слишком малого количества онлайн-модулей одновременно.
  • Разработать рефакторинг проектаСтандарты кодирования
  • Подготовьте новое доменное имя и новый склад, чтобы облегчить пошаговый запуск проекта

Рефакторинг

При рефакторинге проекта мы должны:

  • Обеспечение согласованности страниц и функциональной согласованности до и после рефакторинга
  • Разумно организуйте время, чтобы оно не повлияло на разработку бизнес-требований.
  • Делайте модульные тесты
  • Выходите в интернет шаг за шагом
  • Пройдите онлайн-тест

после рефакторинга

После рефакторинга проекта мы должны:

  • Обеспечьте тестирование с полным охватом, чтобы избежать появления непроверенного кода, появления неожиданностей.bug
  • для сформулированныхТехнические характеристикиПроведите техническое обслуживание проекта, чтобы избежать"Дерьмовая гора 1.0"прогресс"Дерьмовая гора 2.0"

Суммировать

Проблемы в этом рефакторинге являются относительно классическими проблемами, представляющими типичные проблемы в жизненном цикле рефакторинга всего проекта.

Проблема 1: ненужный рефакторинг

В конечном счете, этот рефакторинг все равно является ненужным рефакторингом, в результате рефакторинга пользы никакой, а куча проблем.
Скрытые преимущества:

  • В последующих обновлениях один и тот же контент, используемый в одной и той же сцене, может быть извлечен единообразно дляnpm
  • После того как новые одноклассники присоединятся к работе, они смогут быстрее приступить ко всем проектам в этом сценарии.

Вопрос 2: Используйте метод написания всех текстов и выхода в интернет одновременно.

Преимущества написания всех из них и выхода в интернет одновременно:

  • Нет необходимости в новом доменном имени, новом складе для промежуточной замены

слабость это:

  • В результате тест каждого модуля недостаточно детализирован, что позволяет игнорировать некоторые проблемы.
  • Вызывает массовые взрывы проблем, что может привести к перепадам настроения, вызывающим цепную реакцию.

Проблема 3: Модули отсутствуют

Коллекция используемых модулей недостаточно детализирована, что приводит к отсутствию модулей при выходе в онлайн.

Проблема 4: Недостаточное понимание страницы

Из-за недостаточного понимания страницы при тестировании пропускаются некоторые фоновые записи, что приводит к проблемам.