D
А таких приложения два
Size: a a a
2019 December 06
D
Нам дали карт бланш, нет ресурса - нанимайте
D
Команда с 6 человек разрослась до 11 и нас все еще мало
D
И за год наняли всего 5 человек, просто наш кейс это большой продукт (точнее их несколько), а ресурса не так много. Возможно у тебя проще ситуация была
d
у нас постоянный поток задач от кучи других команд и небольшая команда (в среднем около 5 человек). Просто мы смогли нормально объяснить продактам что если мы не выделим время на апгрейд то дальше будет хуже и тяжелее с новыми задачами. Так же у нас и по рефакторингу - 20% времени команды у нас выделено под наиболее важный рефакторинг.
2019 December 07
D
у нас постоянный поток задач от кучи других команд и небольшая команда (в среднем около 5 человек). Просто мы смогли нормально объяснить продактам что если мы не выделим время на апгрейд то дальше будет хуже и тяжелее с новыми задачами. Так же у нас и по рефакторингу - 20% времени команды у нас выделено под наиболее важный рефакторинг.
Так мы тоже смогли обьяснить и даже делали, но бизнесовых фич очень много
D
Плюс новые продукты
d
ну да, их всегда много, точнее никогда нет им конца и все очень важные. Но как выше писал - если не выделять на рефакторинг то чем дальше тем дольше каждая новая фича будет делаться
D
ну да, их всегда много, точнее никогда нет им конца и все очень важные. Но как выше писал - если не выделять на рефакторинг то чем дальше тем дольше каждая новая фича будет делаться
Ну мы так и делали, просто там легаси очень много
D
Как переписать кодовую базу одного большого продукта написанного за 4 года и запустить еще 5 новых продуктов?
d
сильно зависит от конкретного случая. Сейчас идеальный вариант если продукты относительно независимы - встраивать новые продукты через кастом элементы (если надо в общее приложение офк). Старый по частям переписывать, самое основное
D
сильно зависит от конкретного случая. Сейчас идеальный вариант если продукты относительно независимы - встраивать новые продукты через кастом элементы (если надо в общее приложение офк). Старый по частям переписывать, самое основное
Примерно так и делаем, просто у нас есть прослойка большая в виде связующего звена между продуктами, сейчас ее допишем и уже несколько человек сразу начнет переписывать легаси
D
Я бы вместо гибрида предложил бы микрофронтенд использовать все же
D
(как мы и сделали)
AM
Ребят всем привет! У нас тут спор возник по поводу миграции приложения с первого ангуляра на последний: ребята из гугла рекомендуют ngUpgrade, некоторые коллеги изолировать их друг от друга с помощью iframe-ов. У кого какой опыт был, можете поделиться опытом? Приложение уровня тырпрайз и кода написанного куча, соответсвенно миграция планируется последовательная
На holyjs в мае 19 года говорили, как можно изолировать фреймворки при помощи веб-компонентов. Послушайте это выступление, может быть, станет лучшей альтернативой ngUpgrade
d
там надо смотреть по конкретному случаю. Если новые фичи сильно завязаны на имеющийся код (сервисный например), то с кастом элементами будет тяжко (нет прямого доступа к легаси сервисам) и тут гибрид будет лучше
d
хтя эт не ток про новые, но и про старые, если не получается выделить большие куски компонентов/сервисов и сильная связность
D
На holyjs в мае 19 года говорили, как можно изолировать фреймворки при помощи веб-компонентов. Послушайте это выступление, может быть, станет лучшей альтернативой ngUpgrade
Плюсую
AM
По сути получается, что вы пишете новое приложение, а в какой-то момент просто переключаетесь на новую версию. Без последствий обычного использования гибридов, когда возникает проблема выпиливания всего старого.