Пацаны, такой вопрос. Сейчас буду работать над проектом, кодовую базу уже

видел. Она небольшая, но качество... скажем "можно лучше". После моих замечаний и требований к проекту, я предложил его переписать, так как это даже много времени не займет, но встал вопрос к выбору технологий. Как минимум с точки зрения последующего удобства.

Т.е. важно иметь возможность его переписывать по кускам, т.е. условный Nest.js, вроде как, не подойдет. Учитывая что тестов нет, я думал вообще отказаться от рефакторинга, пока всевозможные интеграционные тесты не напишу, но потребность будет и чем раньше начать — тем проще будет закончить.

Как бы вы поступили?

Забыл уточнить — писал пхпшник на ноде, будто на пхп. Т.е. просто оформить всё в сервисы и контроллеры не выйдет.

Ну без кода сложно представить что там за динозавр)

Увы, код показать не могу))

Экстрасенсы все в отпуске ясновидящих у нас нету

Ну я и не про совет как сделать, а выбор подхода что делать.

Ну основная проблема в переносе на нест я так думаю может быть di неста, но можно поиграться с провайдерами, через useclass и тд

Да, спасибо, попробую на этих выходных

Я бы начала перевёл всё на тайпскрипт если его нет. Потом бы двигался в сторону DI чтобы и тесты норм писать и связанного кода не было, т.к. всё будет завязано на реализациях. А потом пофиг что - хоть експрес хоть нест. Главный вопрос - какие проблемы решает переписывание?

А как там доменный слой организован и как он будет в переписанном приложении организован?

Интересно, в какой части приложения проблемы и как они будут решены в переписанном варианте?

Для проблемы начинаются тогда, когда я за 2 часа не могу понять что куда импортируется и зачем это нужно. Главное решить эту проблему))

ну тогда это будет написать новое а не переписать

Так напишешь под себя, а другой придёт и скажет не могу разобраться за 2 часа, надо переписать

Если проблема только в этом, то может и не трогать?

Так я за более-менее стандартный подход. Взять тот же Nest.js — если был на дргом таком проекте, то и с этим разберешься быстро. А сейчас из-за такой сложности каждый таск будет длинной в вечность, как минимум до написания интеграционных тестов.

Думал не трогать вообще, может и не буду. Но нужно менять подход внутри проекта. (Касаемо связанности модулей и т.д.)

Хз что такое стандартный подход. Вопрос, каким образом организована бизнес логика в приложении? Проблемы, наверное в этом же?

А может не нужно? Кажется ты ещё не постиг дзен "работает - не трогай" Одно дело если проект не выполняет (выполняет с дорогими ошибками) возложенные на него задачи, и другое дело просто плохой код Этот проект больше к какому варианту относится? Вообще я за рефакторинг, если что. Но именно за рефакторинг, а не за переписывание - последнее далеко не всегда бывает оправдано

А ты какой подход будешь использовать в переписанном приложении?

"Работает — не трогай" — девиз всего времени разработки. Тут же желание переписать проект (не с нуля, а отрефакторить по максимуму) вызвано и запросом бизнеса. Просто когда начну внедрять новые фичи, кодовая база будет увеличиваться и изменить что-то будет сложнее. Сейчас там 6к строк кода и это сделать можно за неделю.

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

Составь список 1. Проблема 2. Решение 3. Плюсы от решения 4. Что будет если не решить проблему Щас как-то сумбурно. Команде мб предоставишь список, они фидбэк дадут

А бизнес слой как организуешь?

Его может без изменений оставлю, пока в процессы не вникну, хотя бы

А когда вникнешь, как будешь организовывать?

Зависит от количества новых фич.