Какие моменты стоит учесть при рефакторинге проекта?

Question

[Фёдор]

Здравствуйте! Попал в проект. Есть CRM написанная ещё на 5 версии РНР. Которой пользуются уже реальные клиенты. Перед командой стоит задача переписать с процедурного стиля на ООП + используя функционал 8 версии РНР, для последующего развития и поддержки проекта. Функционал в 99% случаях останется тот, же. Учитывая масштаб проекта, хотел спросить у более опытных программистов, что стоит учесть и иметь ввиду, чтобы не потерять в производительности и быстродействии при написании на ООП стиль? Ну и чтобы не накосячить особо.

Comments

[Dmitry Bay]

переписать

[Дмитрий]

Да это уже не рефакторинг, а с нуля писать получается. Как минимум нужны будут ui тесты. Если морда не поменяется, то только такие тесты и могут помочь.

[Фёдор]

Дмитрий, Тестирование будет, но позже. Сейчас главное переписать на ООП стиль.(с)

Кроме ui тестов какие ещё можете дать рекомендации?

[Дмитрий]

Фёдор, попробуйте фреймворк какой нибудь использовать, должно по проще быть, выписать все старые роуты, переделать на новые красивые, так как скорее всего в старом коде куча гет параметров. Ну а дальше кусками и сделать по тихому.
Если там уже какие то шаблоны есть то повезло, если нет, то сначала надо будет выдрать весь фронт

[SymphoGraph]

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

[Фёдор]

Дмитрий, В этом и идиотизм, что надо чистом РНР писать, так как сейчас CRM шустро работает и боятся, господи, потери в производительности.

[Фёдор]

Роман Чубич, Возьму на заметку, чтобы при следующем созвоне использовать это, как аргумент, чтобы всё таки взять какой-нибудь готовый фрэймворк

[Adamos]

Фёдор, чистый РНР на типовом проекте в 2023 - это верный способ сделать поддержку и развитие в разы дороже, и только.

[Дмитрий]

Фёдор, если там хтмл в перемешку с кодом и с запросами в базу, это в любом скучает надо переписывать, шаблоны в будущем помогут фронтам, если вдруг начнут кнопки выше/ниже двигать или добавлять всякое. Я так понимаю оно уже после обновления пхп умерло

[Фёдор]

Adamos, Я это понимаю, поэтому буду топить за фрэймворк всё таки. Деньги все считать умеют.

[Фёдор]

Дмитрий, + ещё один аргумент в пользу фрэймворка.

[Одиночка Айс]

Adamos, самописная CRM такой типовой проект, ага)

[SymphoGraph]

Фёдор, а вот насчет фреймворка вопрос спорный.
В определённых ситуациях фреймворк тоже может стать топором в каше.
Тут всё зависит от бизнес-логики, которую требуется реализовать и от выбранной архитектуры.
И нужно всё взвесить:
это монолит? - тогда однозначно фреймворк.
Но если у вас в перспективе маячит много разных клиент-сервисов, всё становится не таким уж однозначным.

[Adamos]

Одиночка Айс, по моему опыту написания самописных CRM - да, внезапно, типовой.
Там куча бизнес-логики под капотом, но она требует написания вне зависимости от того, на чем написан сам сайт.
А буквально все остальное, вся обвязка между этой логикой, базой и пользователем - типовая настолько, что хоть CMS используй.

[Одиночка Айс]

Adamos, дак любая задача к этому сводится)

[Северное Сияние]

Фёдор,

В этом и идиотизм, что надо чистом РНР писать, так как сейчас CRM шустро работает и боятся, господи, потери в производительности.

Сейчас главное переписать на ООП стиль

без фрейморка у вас не получится ничего

а имя этой компании можно, интересно, что за дуболомы там работают?

Answer 1

[Adamos]

Если у вас пыховое приложение на древней версии, в нем стопудово куча дублирования кода и велосипедов там, где фреймворк предлагает готовое, отлаженное и стандартное.
Нет смысла переписывать велосипеды на ООП только для того, чтобы потом понять, что из них нужно только вычленить (и все равно во многом переписать) бизнес-логику, а все остальное надо просто выкинуть.
Кроме того, CRM - это куча однообразного контента и на фронте. Сразу перенести его на современный фрейм, в котором данные на бэке и фронте аккуратно синхронизируются, может опять-таки оказаться быстрее, чем мучить те велосипеды.
Ну, а если все сделано в худшем стиле и комком - вовсе оставить копролит и переписать с нуля шаг за шагом. Именно для последующего развития и поддержки.

Comments

[Фёдор]

Конкретно структуру проекта будем просматривать в пятницу. Уж тогда будет известно, что там да как. Но скорее всего там будет то, что вы описали. Да и к тому же, с паттернами можно навертеть так, что будет ещё хуже.