Фактически CMS предыдущего поколения типа WordPress, Kentico работают через server-side rendering: на бекенде есть шаблоны страниц или компонентов, которые рендерят нам HTML на сервере на каждый запрос.
С ними проблема в том, что бекенд пишется на другом языке и шаблонизаторе, чем фронтенд, а в случае чуть более сложных компонентов (например, фильтров таблиц, визардов и прочего) приходиться дублировать логику отображения на беке и фронте. Как правило для эффективной работы в таком формате надо либо иметь фуллстек разработчика либо собирать команду бек-фронт.
С переходом на headless CMS и server-side rendering - обе эти проблемы уходят. Достаточно нормального фронтендера и мы имеем единую кодовую базу для отображения - всем проще.
Нет, речь шла про производительность работы сервиса. Как вы верно заметили, следует различать термины "рефакторинг" и "оптимизация". Оптимизация часто приводит к усложнению кода, что в свою очередь противоречит целям рефакторинга. Тут речь как раз шла про кейсы, когда целью задачи в первую очередь ставится рефакторинг, но во время этого процесса также улучшается производительность. Вот несколько подобных кейсов: 1) Если в процессе рефакторинга упростилась схема БД. Например, убрались лишние связи и в запросе стало меньше джойнов/подзапросов. 2) Если в процессе рефакторинга был затронут код, отвечающий за работу с БД. И оказалось, что выполняются ненужные подзаросы/джойны или тянутся лишние данные. Поэтому вместе с упрощением кода получилось ускорить его работу. 3) Если в процессе рефакторинга убрали функциональность, которая по факту уже давно не использовалась. Либо сильно упростили логику работу какой-то функциональности. 4) В статье упоминалось, что скилл команды со временем растет, поэтому в процессе рефакторинга какой-то функциональности разработчики могут в том числе применить оптимизацию, которая не усложнит код (а возможно даже упростит его). В C# большое кол-во различных коллекций. Бывает, что стоит заюзать более подходящую коллекцию и производительность возрастет в несколько раз 5) Для того, чтобы правильно отрефакторить, нужно внимательно просканировать текущий код, понять его работу. Во время этого процесса можно найти проблемы с производительностью и исправить их вместе с рефакторингом
Но конечно, если в проекте есть проблемы с производительностью, то правильнее создать отдельные задачи на оптимизацию (и не называть это рефакторингом).
Да, есть такое. Legacy тоже бывает разный: недавно пришел клиент с системой на мейнфреймах, например. C другой стороны чаще это просто не последний .NET, и достаточно объемный и иногда запутанный код.
Хочу также сделать более подробную статью про реализации подходов в Next.js на основе нашего опыта - напишите в комменте, что вам интересно
Фактически CMS предыдущего поколения типа WordPress, Kentico работают через server-side rendering: на бекенде есть шаблоны страниц или компонентов, которые рендерят нам HTML на сервере на каждый запрос.
С ними проблема в том, что бекенд пишется на другом языке и шаблонизаторе, чем фронтенд, а в случае чуть более сложных компонентов (например, фильтров таблиц, визардов и прочего) приходиться дублировать логику отображения на беке и фронте. Как правило для эффективной работы в таком формате надо либо иметь фуллстек разработчика либо собирать команду бек-фронт.
С переходом на headless CMS и server-side rendering - обе эти проблемы уходят. Достаточно нормального фронтендера и мы имеем единую кодовую базу для отображения - всем проще.
Нет, речь шла про производительность работы сервиса.
Как вы верно заметили, следует различать термины "рефакторинг" и "оптимизация". Оптимизация часто приводит к усложнению кода, что в свою очередь противоречит целям рефакторинга. Тут речь как раз шла про кейсы, когда целью задачи в первую очередь ставится рефакторинг, но во время этого процесса также улучшается производительность. Вот несколько подобных кейсов:
1) Если в процессе рефакторинга упростилась схема БД. Например, убрались лишние связи и в запросе стало меньше джойнов/подзапросов.
2) Если в процессе рефакторинга был затронут код, отвечающий за работу с БД. И оказалось, что выполняются ненужные подзаросы/джойны или тянутся лишние данные. Поэтому вместе с упрощением кода получилось ускорить его работу.
3) Если в процессе рефакторинга убрали функциональность, которая по факту уже давно не использовалась. Либо сильно упростили логику работу какой-то функциональности.
4) В статье упоминалось, что скилл команды со временем растет, поэтому в процессе рефакторинга какой-то функциональности разработчики могут в том числе применить оптимизацию, которая не усложнит код (а возможно даже упростит его). В C# большое кол-во различных коллекций. Бывает, что стоит заюзать более подходящую коллекцию и производительность возрастет в несколько раз
5) Для того, чтобы правильно отрефакторить, нужно внимательно просканировать текущий код, понять его работу. Во время этого процесса можно найти проблемы с производительностью и исправить их вместе с рефакторингом
Но конечно, если в проекте есть проблемы с производительностью, то правильнее создать отдельные задачи на оптимизацию (и не называть это рефакторингом).
:)
Мы же разработчики - нам иногда же просто хочется покопаться в чем-то и что-то запрогать :)
Для бизнес логики, да, хранимки - это моветон. Но для ETL и агрегации данных, вполне нормальное решение.
Да, бывает, что есть уже готовый техстек, котором надо следовать. Но нам везет: к нам часто приходят, чтобы этот стек как раз создать.
Это больше на мир фронтенда похоже. Там каждые пару месяцов какой-то актуальный фреймворк объявляется legacy и все надо переписывать :)
Да, есть такое. Legacy тоже бывает разный: недавно пришел клиент с системой на мейнфреймах, например. C другой стороны чаще это просто не последний .NET, и достаточно объемный и иногда запутанный код.
Спасибо за ссылку - пригодиться!