Эволюция проекта: от хаоса к нормальной архитектуре
Полгода назад я сделал первую версию CloudRate — платформы для оценки музыки российских андерграунд-исполнителей с SoundCloud
Тогда это был мой первый большой React-проект, и выглядел он… как обычно выглядят первые большие проекты 😄
— весь код в одной куче — глобальные стили конфликтовали друг с другом — почти отсутствовала структура — JavaScript без типизации — поддерживать новые фичи становилось все тяжелее
В какой-то момент я понял, что развивать проект дальше сложнее, чем переписать его заново.
Так появился CloudRate v2.
Что изменил: • переписал фронтенд на TypeScript • перешел на Feature-Sliced Design • добавил JWT auth + refresh token flow • сделал админ-панель • переработал UI • вынес логику в нормальную архитектуру • настроил production deploy
Самое интересное — во время переписывания начал намного лучше понимать, зачем вообще нужны архитектурные подходы. Раньше FSD, разделение ответственности и масштабируемость казались “переусложнением”. Теперь без этого уже сложно представить большой проект.
Сейчас продолжаю развивать CloudRate дальше — впереди рекомендации, верификация артистов и еще куча идей, и конечное же, релиз проекта.
CloudRate (Github): https://github.com/velniok/cloudratev CloudRate (Live Demo): https://cloudratev2.vercel.app
· 11.05
Как я понял ты изменил уже существующий код
Как думаешь, лучше было менять то, что есть, или пробовать создавать верную архитектуру с нуля, опираясь на уже написанный код?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 12.05
Сначала думал изменять существующий код, но в какой-то момент понял, что накопилось слишком много архитектурных проблем. Поэтому решил делать v2 с нуля, но опираясь на опыт v1 уже с пониманием, какие ошибки не хочу повторять.
Мне кажется, всё зависит от состояния проекта. Если проблемы локальные, то изменение существующего кода логичнее. Но когда архитектурный долг начинает мешать развитию продукта, иногда переписать оказывается дешевле и быстрее, чем постоянно чинить старое.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 12.05
Тоже верно
Мне кажется зависит от сферы работы
Если работаешь на заказчика - то его практически невозможно убедить в необходимости переписывания проекта) Другое дело когда работаешь в продукте, там такое ценят
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён