Команда, к которой я принадлежу на работе, планирует поменять структуру пользовательского интерфейса, которую мы в настоящее время используем, Om, на другую, перекадрировать. Основная причина перестановки заключается в том, что Om больше не поддерживается, и мы создали простое подтверждение концепции в перефрейме, которое кажется многообещающим.
В дополнение к неподдерживаемой платформе, которую мы используем в настоящее время, нашКод также нуждается в рефакторинге. Большая часть кода пользовательского интерфейса находится в одном большом файле (~ 3 тыс. Строк).
Мой предпочтительный подход заключается в том, чтобы сначала завершить рефакторинг для существующего кода Om и разбить большой файл на множество маленьких файлов, чтобы сделать вещиболее управляемым, а также реструктурировать файлы в более интуитивную файловую структуру. После этого мы переписали бы код пользовательского интерфейса, используя re-frame.
Мой коллега предпочел бы пропустить рефакторинг / реструктуризацию и написать код пользовательского интерфейса в re-frame.
Моя мысльВо-первых, процесс рефакторинга заключается в следующем:
- Мы сможем идентифицировать мертвый код и удалить его
- Имеем более мелкие, более организованные файлы, которые было бы легче преобразовать для использованияновая структура
- Извлечение общего кода, который будет повторно использоваться в коде повторного фрейма, поэтому у нас есть одна копия этого общего кода, которая будет одновременно использоваться в Production кодом Om и кодом повторного фрейма какон разрабатывается
- Уменьшите риск неудачи проекта, выполняя одну вещь за раз (сначала рефакторинг, а затем обмен фреймворка пользовательского интерфейса)
Мой мыслительный процесс моего коллеги, желающего пропуститьРефакторинг заключается в том, что мы:
- Экономим время и усилия, не рефакторинг кода, который будет выброшен
- Воспользуйтесь преимуществами этогосейчас у нас затишье между крупными проектами, чтобы завершить обмен фреймворком UI, прежде чем мы, в конце концов, снова будем заняты, и у нас не будет времени для решения большой технической проблемы. возможно медленнее, но менее рискованно. Хотя подход моего коллеги может быть более быстрым, пока дела идут гладко, он кажется более рискованным и будет сложнее проверить, что мы полностью воспроизвели устаревшие функциональные возможности в новом коде.
Любой совет?