IK
да и с любым компонентным фреймворком
Size: a a a
2020 March 05
IK
вы работаете изолированно в контексте компонента, а как они будут собраны в иерархию становится реально только в рантайме
VN
В react все ок, косяк в коде - не компилится
IK
Не обязательно (хотелось бы мне чтобы это было так). Речь идет только о типе сущности, но часто компоненты полагаются не только на тип, но и на конкретное состояние сущности )
IK
(я ни в коем случае не говорю что вы не правы)
LA
Развернутый ответ.
Начну с контекста (мало ли, вдруг кто-то из читающих не в теме что за хрен с горы отвечает)
У меня была 7 лет своя компания, поэтому я понимаю позиции бизнеса, сейчас я Senior Frontend Engineer в GitLab. 85% нашего кода - это jquery + bootstrap + HAML. Это больно, это тяжело поддерживать, нам приходится мейнтейнить некоторые библиотеки, которые уже заброшены создателями.
Начнем с кратких ответов на озвученные вопросы.
1. Как объяснить менеджеру, что нужно переписать всё приложение на современный стек технологий?
Предоставить ему понимание не только выгод от этого процесса, но и рисков, которые он несет. Поскольку риски почти всегда проекто-специфичны чужой опыт почти наверянка будет для вас бесполезен чуть более чем полностью, поэтому все "вот статья" являются оценкой сферических коней в вакууме, слабо применимыми к вашему конкретному проекту
2. Можно ли как-то измерить ценность от смены фреймворка?
Для конечного пользователя - нет. Потому что пользователь желает функциональности и ему все-равно что под капотом - почтовые голуби, магия или JQuery. Для бизнеса - да, если у вас есть скрам и правильные стори-пойнты (когда технический долг и баги не имеют сторипойнтов), то переход на новый фреймворк должен привести к увеличению velocity команды (сколько пойнтов команда закрывает в спринт).
Ок, вы скажете, но ведь вначале пока будем переезжать скорость вообще упадет почти до нуля? Про это мы сейчас поговорим чуть ниже
3. Возможно вы знаете какие-нибудь статьи о том как принимать решения о миграции?
Честно говоря не знаю, но и не уверен, что такие статьи вовсе нужны. Это классическая задача об инвестициях в производство и решается она просто, о чем мы поговорим ниже.
Теперь о болях:
1. Для создания простого компонента необходимо большое количество boilerplate-кода
Для решения этого точно не нужен фреймворк. Любая штука для кодогенерации + чу-чуть времени выйлет дешевле
2. Приходится поддерживать постоянно ломающиеся кастомные решения
Здесь аргумент принят и логичен
3. Задачи выполняются долго, а когда выполняются остается большой хвост из багов, которые никто не отловил.
Здесь у меня возникает вопрос - почему вы считаете что переход на новый фреймворк решит проблему "большого хвоста из багов которые никто не отловил" - увы и ах, фреймворк сам багов не ловит
Теперь по-поводу главного ответа на "стоит ли это делать и когда нужно делать". Ответ "когда" банален до ужаса - когда это имеет экономический смысл. Мы бы могли сейчас застопорить всю разработку гитлаба и переписать все на Vue (мы прибыльны, у нас позитивный кешфлоу, представьте насколько бы это ускорило разработку фронта в будущем), но в масштабах грядущего IPO/Direct listing в этом году - это было бы самоубийство в глазах инвесторов.
Стоит ли делать? Здесь поможет только эксперимент. Самое правильное решение - взять задачу, которую хорошо можно изолировать от существующей системы или наиболее проблемный кусок существующей системы. Разбить эту задачу на два этапа - "подготовительный" - вам понадобится написать какое-то количества кода допустим для взаимодействия legacy-приложения и какой-вы-фреймворк-возьмете и брать его в оценку задачи неверно, и "реализация" - когда вы реализовываете этот кусок на новом фреймворке. Дальше вы смотрите на результат, и отвечаете на вопросы, насколько это удовлетворяет вашим потребностям в скорости.
Фактически, ваше решение предлает продукт оунеру прийти в казино и всё поставить на чёрное. Естественно, его эта идея немного... нервирует. Предложите ему небольшой риск в рамках 1-2 спринтов, который он может принять даже если ставка не сыграет. Вы же получите конкретные метрики.
НЕСОМНЕННО эффект будет ниже, чем если бы "все сразу" было переписано, но важно что все это понимают. И 10 денег потраченные в течение 10 спринтов гораздо выгоднее чем 100 денег потраченные в один спринт.
Начну с контекста (мало ли, вдруг кто-то из читающих не в теме что за хрен с горы отвечает)
У меня была 7 лет своя компания, поэтому я понимаю позиции бизнеса, сейчас я Senior Frontend Engineer в GitLab. 85% нашего кода - это jquery + bootstrap + HAML. Это больно, это тяжело поддерживать, нам приходится мейнтейнить некоторые библиотеки, которые уже заброшены создателями.
Начнем с кратких ответов на озвученные вопросы.
1. Как объяснить менеджеру, что нужно переписать всё приложение на современный стек технологий?
Предоставить ему понимание не только выгод от этого процесса, но и рисков, которые он несет. Поскольку риски почти всегда проекто-специфичны чужой опыт почти наверянка будет для вас бесполезен чуть более чем полностью, поэтому все "вот статья" являются оценкой сферических коней в вакууме, слабо применимыми к вашему конкретному проекту
2. Можно ли как-то измерить ценность от смены фреймворка?
Для конечного пользователя - нет. Потому что пользователь желает функциональности и ему все-равно что под капотом - почтовые голуби, магия или JQuery. Для бизнеса - да, если у вас есть скрам и правильные стори-пойнты (когда технический долг и баги не имеют сторипойнтов), то переход на новый фреймворк должен привести к увеличению velocity команды (сколько пойнтов команда закрывает в спринт).
Ок, вы скажете, но ведь вначале пока будем переезжать скорость вообще упадет почти до нуля? Про это мы сейчас поговорим чуть ниже
3. Возможно вы знаете какие-нибудь статьи о том как принимать решения о миграции?
Честно говоря не знаю, но и не уверен, что такие статьи вовсе нужны. Это классическая задача об инвестициях в производство и решается она просто, о чем мы поговорим ниже.
Теперь о болях:
1. Для создания простого компонента необходимо большое количество boilerplate-кода
Для решения этого точно не нужен фреймворк. Любая штука для кодогенерации + чу-чуть времени выйлет дешевле
2. Приходится поддерживать постоянно ломающиеся кастомные решения
Здесь аргумент принят и логичен
3. Задачи выполняются долго, а когда выполняются остается большой хвост из багов, которые никто не отловил.
Здесь у меня возникает вопрос - почему вы считаете что переход на новый фреймворк решит проблему "большого хвоста из багов которые никто не отловил" - увы и ах, фреймворк сам багов не ловит
Теперь по-поводу главного ответа на "стоит ли это делать и когда нужно делать". Ответ "когда" банален до ужаса - когда это имеет экономический смысл. Мы бы могли сейчас застопорить всю разработку гитлаба и переписать все на Vue (мы прибыльны, у нас позитивный кешфлоу, представьте насколько бы это ускорило разработку фронта в будущем), но в масштабах грядущего IPO/Direct listing в этом году - это было бы самоубийство в глазах инвесторов.
Стоит ли делать? Здесь поможет только эксперимент. Самое правильное решение - взять задачу, которую хорошо можно изолировать от существующей системы или наиболее проблемный кусок существующей системы. Разбить эту задачу на два этапа - "подготовительный" - вам понадобится написать какое-то количества кода допустим для взаимодействия legacy-приложения и какой-вы-фреймворк-возьмете и брать его в оценку задачи неверно, и "реализация" - когда вы реализовываете этот кусок на новом фреймворке. Дальше вы смотрите на результат, и отвечаете на вопросы, насколько это удовлетворяет вашим потребностям в скорости.
Фактически, ваше решение предлает продукт оунеру прийти в казино и всё поставить на чёрное. Естественно, его эта идея немного... нервирует. Предложите ему небольшой риск в рамках 1-2 спринтов, который он может принять даже если ставка не сыграет. Вы же получите конкретные метрики.
НЕСОМНЕННО эффект будет ниже, чем если бы "все сразу" было переписано, но важно что все это понимают. И 10 денег потраченные в течение 10 спринтов гораздо выгоднее чем 100 денег потраченные в один спринт.
Необходимо ли обо всем этом думать каждому программисту каждый рабочий день?
Возьмем среднестатистического разработчика, которому работодатель платит 10 денег в час работы (при этом работодатель может продавать эту же работу заказчику за фиксу, для разработчика это вообще не важно). У него есть Trello/Jira/Youtrack и план на работы на пару лет вперед (это в идеальном мире, но все же предположим). Для работания работы разработчику требуются ресурсы - помимо материальных - внимание, концентрация, настроение, объем мыслетоплива. Когда разработчик сосредоточен на задаче - он максимально качественен (не путать с продуктивен, это может быть не так) в ее решении. Когда параллельно он думает о бизнес-ценности, о том, как обосновать что-то менеджеру, как найти данные о корелляции объема типизированного кода и кол-ва багов - его качество стремительно падает. Теперь давайте посмотрим на его доход: ниже качество -> ниже объем выполненной работы -> ниже доход. Если мы вводим "правильные" сторипоинты, то получаем примерно следующую картину: задача оценена в 2 часа, выполняется за 4, на выявление и корректировку багов и техдолга тратится 20 часов на протяжении последующих 3х недель (все цифры условны, любое совпадение с реальными данными случайно). Т.е. разработчик зарабатывает не 10 денег в час, а 0.83 деньги в час, что как-то не айс выходит.
Возьмем среднестатистического разработчика, которому работодатель платит 10 денег в час работы (при этом работодатель может продавать эту же работу заказчику за фиксу, для разработчика это вообще не важно). У него есть Trello/Jira/Youtrack и план на работы на пару лет вперед (это в идеальном мире, но все же предположим). Для работания работы разработчику требуются ресурсы - помимо материальных - внимание, концентрация, настроение, объем мыслетоплива. Когда разработчик сосредоточен на задаче - он максимально качественен (не путать с продуктивен, это может быть не так) в ее решении. Когда параллельно он думает о бизнес-ценности, о том, как обосновать что-то менеджеру, как найти данные о корелляции объема типизированного кода и кол-ва багов - его качество стремительно падает. Теперь давайте посмотрим на его доход: ниже качество -> ниже объем выполненной работы -> ниже доход. Если мы вводим "правильные" сторипоинты, то получаем примерно следующую картину: задача оценена в 2 часа, выполняется за 4, на выявление и корректировку багов и техдолга тратится 20 часов на протяжении последующих 3х недель (все цифры условны, любое совпадение с реальными данными случайно). Т.е. разработчик зарабатывает не 10 денег в час, а 0.83 деньги в час, что как-то не айс выходит.
IK
Разработчик все-так же зарабатывает 10 денег в час. То что баги не оцениваются в сторипойнтах не значит что за них не платят )
LA
Разработчик все-так же зарабатывает 10 денег в час. То что баги не оцениваются в сторипойнтах не значит что за них не платят )
чорд, в каких же разных мирах мы живем 🤷♂️
IK
Я не знаю ни одной компании где было бы по-иному
LA
мне кажется, что переезд на новую технологию зависит по большей части от упоротости (в хорошем смысле слова) разработчиков. Согласно формуле оценки времени проекта по Бобуку-Бацеку этот переезд можно осуществить за 2 недели. Поскольку нужно это, по большей части, именно разработчикам - им работать с проектом, и если они не могут решить эту задачу на jQuery, но могут на React, то тут уже у бизнеса возникают вопросы квалификации разработчиков. Да, в отдельных случаях есть профит чисто технически - от перехода на новый фреймворк улучшается перфоманс, как пример это показывал Илья в своем докладе - обзоре Vue3, но по большей части это про удобство разработчиков, а не для бизнеса
A
Привет, можно ли создать поиск по сайту на базе firebase ?
ИР
мне кажется, что переезд на новую технологию зависит по большей части от упоротости (в хорошем смысле слова) разработчиков. Согласно формуле оценки времени проекта по Бобуку-Бацеку этот переезд можно осуществить за 2 недели. Поскольку нужно это, по большей части, именно разработчикам - им работать с проектом, и если они не могут решить эту задачу на jQuery, но могут на React, то тут уже у бизнеса возникают вопросы квалификации разработчиков. Да, в отдельных случаях есть профит чисто технически - от перехода на новый фреймворк улучшается перфоманс, как пример это показывал Илья в своем докладе - обзоре Vue3, но по большей части это про удобство разработчиков, а не для бизнеса
А разве Бизнесу не лучше будет искать React/Vue/Angular разработчиков на свои проекты?
JQuery сейчас никто не хочет учить и разбираться в нем
JQuery сейчас никто не хочет учить и разбираться в нем
LA
А разве Бизнесу не лучше будет искать React/Vue/Angular разработчиков на свои проекты?
JQuery сейчас никто не хочет учить и разбираться в нем
JQuery сейчас никто не хочет учить и разбираться в нем
ну вот есть гитлаб и кого им искать - Vue-разработчиков, jQuery-разработчиков или просто разработчиков, хорошо знающих сам язык?
OR
Развернутый ответ.
Начну с контекста (мало ли, вдруг кто-то из читающих не в теме что за хрен с горы отвечает)
У меня была 7 лет своя компания, поэтому я понимаю позиции бизнеса, сейчас я Senior Frontend Engineer в GitLab. 85% нашего кода - это jquery + bootstrap + HAML. Это больно, это тяжело поддерживать, нам приходится мейнтейнить некоторые библиотеки, которые уже заброшены создателями.
Начнем с кратких ответов на озвученные вопросы.
1. Как объяснить менеджеру, что нужно переписать всё приложение на современный стек технологий?
Предоставить ему понимание не только выгод от этого процесса, но и рисков, которые он несет. Поскольку риски почти всегда проекто-специфичны чужой опыт почти наверянка будет для вас бесполезен чуть более чем полностью, поэтому все "вот статья" являются оценкой сферических коней в вакууме, слабо применимыми к вашему конкретному проекту
2. Можно ли как-то измерить ценность от смены фреймворка?
Для конечного пользователя - нет. Потому что пользователь желает функциональности и ему все-равно что под капотом - почтовые голуби, магия или JQuery. Для бизнеса - да, если у вас есть скрам и правильные стори-пойнты (когда технический долг и баги не имеют сторипойнтов), то переход на новый фреймворк должен привести к увеличению velocity команды (сколько пойнтов команда закрывает в спринт).
Ок, вы скажете, но ведь вначале пока будем переезжать скорость вообще упадет почти до нуля? Про это мы сейчас поговорим чуть ниже
3. Возможно вы знаете какие-нибудь статьи о том как принимать решения о миграции?
Честно говоря не знаю, но и не уверен, что такие статьи вовсе нужны. Это классическая задача об инвестициях в производство и решается она просто, о чем мы поговорим ниже.
Теперь о болях:
1. Для создания простого компонента необходимо большое количество boilerplate-кода
Для решения этого точно не нужен фреймворк. Любая штука для кодогенерации + чу-чуть времени выйлет дешевле
2. Приходится поддерживать постоянно ломающиеся кастомные решения
Здесь аргумент принят и логичен
3. Задачи выполняются долго, а когда выполняются остается большой хвост из багов, которые никто не отловил.
Здесь у меня возникает вопрос - почему вы считаете что переход на новый фреймворк решит проблему "большого хвоста из багов которые никто не отловил" - увы и ах, фреймворк сам багов не ловит
Теперь по-поводу главного ответа на "стоит ли это делать и когда нужно делать". Ответ "когда" банален до ужаса - когда это имеет экономический смысл. Мы бы могли сейчас застопорить всю разработку гитлаба и переписать все на Vue (мы прибыльны, у нас позитивный кешфлоу, представьте насколько бы это ускорило разработку фронта в будущем), но в масштабах грядущего IPO/Direct listing в этом году - это было бы самоубийство в глазах инвесторов.
Стоит ли делать? Здесь поможет только эксперимент. Самое правильное решение - взять задачу, которую хорошо можно изолировать от существующей системы или наиболее проблемный кусок существующей системы. Разбить эту задачу на два этапа - "подготовительный" - вам понадобится написать какое-то количества кода допустим для взаимодействия legacy-приложения и какой-вы-фреймворк-возьмете и брать его в оценку задачи неверно, и "реализация" - когда вы реализовываете этот кусок на новом фреймворке. Дальше вы смотрите на результат, и отвечаете на вопросы, насколько это удовлетворяет вашим потребностям в скорости.
Фактически, ваше решение предлает продукт оунеру прийти в казино и всё поставить на чёрное. Естественно, его эта идея немного... нервирует. Предложите ему небольшой риск в рамках 1-2 спринтов, который он может принять даже если ставка не сыграет. Вы же получите конкретные метрики.
НЕСОМНЕННО эффект будет ниже, чем если бы "все сразу" было переписано, но важно что все это понимают. И 10 денег потраченные в течение 10 спринтов гораздо выгоднее чем 100 денег потраченные в один спринт.
Начну с контекста (мало ли, вдруг кто-то из читающих не в теме что за хрен с горы отвечает)
У меня была 7 лет своя компания, поэтому я понимаю позиции бизнеса, сейчас я Senior Frontend Engineer в GitLab. 85% нашего кода - это jquery + bootstrap + HAML. Это больно, это тяжело поддерживать, нам приходится мейнтейнить некоторые библиотеки, которые уже заброшены создателями.
Начнем с кратких ответов на озвученные вопросы.
1. Как объяснить менеджеру, что нужно переписать всё приложение на современный стек технологий?
Предоставить ему понимание не только выгод от этого процесса, но и рисков, которые он несет. Поскольку риски почти всегда проекто-специфичны чужой опыт почти наверянка будет для вас бесполезен чуть более чем полностью, поэтому все "вот статья" являются оценкой сферических коней в вакууме, слабо применимыми к вашему конкретному проекту
2. Можно ли как-то измерить ценность от смены фреймворка?
Для конечного пользователя - нет. Потому что пользователь желает функциональности и ему все-равно что под капотом - почтовые голуби, магия или JQuery. Для бизнеса - да, если у вас есть скрам и правильные стори-пойнты (когда технический долг и баги не имеют сторипойнтов), то переход на новый фреймворк должен привести к увеличению velocity команды (сколько пойнтов команда закрывает в спринт).
Ок, вы скажете, но ведь вначале пока будем переезжать скорость вообще упадет почти до нуля? Про это мы сейчас поговорим чуть ниже
3. Возможно вы знаете какие-нибудь статьи о том как принимать решения о миграции?
Честно говоря не знаю, но и не уверен, что такие статьи вовсе нужны. Это классическая задача об инвестициях в производство и решается она просто, о чем мы поговорим ниже.
Теперь о болях:
1. Для создания простого компонента необходимо большое количество boilerplate-кода
Для решения этого точно не нужен фреймворк. Любая штука для кодогенерации + чу-чуть времени выйлет дешевле
2. Приходится поддерживать постоянно ломающиеся кастомные решения
Здесь аргумент принят и логичен
3. Задачи выполняются долго, а когда выполняются остается большой хвост из багов, которые никто не отловил.
Здесь у меня возникает вопрос - почему вы считаете что переход на новый фреймворк решит проблему "большого хвоста из багов которые никто не отловил" - увы и ах, фреймворк сам багов не ловит
Теперь по-поводу главного ответа на "стоит ли это делать и когда нужно делать". Ответ "когда" банален до ужаса - когда это имеет экономический смысл. Мы бы могли сейчас застопорить всю разработку гитлаба и переписать все на Vue (мы прибыльны, у нас позитивный кешфлоу, представьте насколько бы это ускорило разработку фронта в будущем), но в масштабах грядущего IPO/Direct listing в этом году - это было бы самоубийство в глазах инвесторов.
Стоит ли делать? Здесь поможет только эксперимент. Самое правильное решение - взять задачу, которую хорошо можно изолировать от существующей системы или наиболее проблемный кусок существующей системы. Разбить эту задачу на два этапа - "подготовительный" - вам понадобится написать какое-то количества кода допустим для взаимодействия legacy-приложения и какой-вы-фреймворк-возьмете и брать его в оценку задачи неверно, и "реализация" - когда вы реализовываете этот кусок на новом фреймворке. Дальше вы смотрите на результат, и отвечаете на вопросы, насколько это удовлетворяет вашим потребностям в скорости.
Фактически, ваше решение предлает продукт оунеру прийти в казино и всё поставить на чёрное. Естественно, его эта идея немного... нервирует. Предложите ему небольшой риск в рамках 1-2 спринтов, который он может принять даже если ставка не сыграет. Вы же получите конкретные метрики.
НЕСОМНЕННО эффект будет ниже, чем если бы "все сразу" было переписано, но важно что все это понимают. И 10 денег потраченные в течение 10 спринтов гораздо выгоднее чем 100 денег потраченные в один спринт.
Сохранил. Спасибо.
IK
GitLab не требует обязательного знания ни Вью ни JQuery (:
V
GitLab не требует обязательного знания ни Вью ни JQuery (:
Бекендеры пишут фронт и фронтендеры бек?
LA
Интересно какие же затраты? Мы читаем код чаще чем пишем. Типизированный код намного легче и быстрее понять. Мое мнение что нетипизированный код увеличивает временные затраты, на его вычитывание, на правку багов рефакторинга на проде
нетипизированный код, как и любое решение, требующее низкой ментальной нагрузки, создается быстрее и продается быстрее. Баги могут выявляться на протяжении лет после запуска продукта, а сейчас бизнесу важно его продать, неважно кому - заказчику или инвесторам
IK
Бекендеры пишут фронт и фронтендеры бек?
Нет
OR
нетипизированный код, как и любое решение, требующее низкой ментальной нагрузки, создается быстрее и продается быстрее. Баги могут выявляться на протяжении лет после запуска продукта, а сейчас бизнесу важно его продать, неважно кому - заказчику или инвесторам
Ну, мне кажется, если привыкнуть, то на типизации ты будешь не сильно медленнее работать.
LA
Нет
лукавишь 😉 на позиции синьор фронтенд ты работаешь с Ruby том числе 😊