AD
Привет, ребят, подскажите - как можно на Linux запустить в фоне одной коммандой 2 процесса:
npm run process1и
npm run process2
?
npm run process1и
npm run process2
?
Size: a a a
2020 March 04
IS
Привет, ребят, подскажите - как можно на Linux запустить в фоне одной коммандой 2 процесса:
При помощи амперсанда -
command1 & command2 для параллельного запуска и два амперсанда для последовательного выполнения командS
Господа, а кто меня просветит. Вот я импортирую к себе компоненты
А в antd/index.ts там целая куча импортов, в общем-то весь Ant. Вот я думаю, это все в бандл мне попадет или только Form?
import { Form } from "antd";А в antd/index.ts там целая куча импортов, в общем-то весь Ant. Вот я думаю, это все в бандл мне попадет или только Form?
Насколько я помню есть antd/es/form и при сборке для прода шейкинг уберёт лишнее
2020 March 05
OP
Всем привет, у меня скорее менеджерский вопрос.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
IK
Все правильно PO делает
IK
Переписывание на современный стек - задача с огромным количеством неизвестных переменных
IK
Дальше, с чего вы взяли что внедрение типизации уменьшит количество багов?
IK
С удовольствием посмотрю на исследование :)
IK
Всем привет, у меня скорее менеджерский вопрос.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
Я сейчас вернусь к компьютеру и напишу что делать
IK
Ведь по сути гитлаб в той же ситуации - у нас куча легаси
OP
Я сейчас вернусь к компьютеру и напишу что делать
Спасибо большое, я немного в тупике
IK
Программистам естественно хочется работать с современным стеком
IK
Всегда :)
IK
И всегда хочется все переписать потому что теперь то точно известен объем задач
OP
Дальше, с чего вы взяли что внедрение типизации уменьшит количество багов?
Я понимаю, что это звучит не серьезно. Но часто вижу ситуации, где наличие типизации не позволило бы разработчику написать определенный код, но сейчас он может его написать и ломает в последствии прод.
IK
Я понимаю, что это звучит не серьезно. Но часто вижу ситуации, где наличие типизации не позволило бы разработчику написать определенный код, но сейчас он может его написать и ломает в последствии прод.
Но вы забываете о затратах на содержание типизации
OP
Но вы забываете о затратах на содержание типизации
Вы правы и это был бы существенный недостаток для нашей команды, но у нас сейчас ещё и ручное тестирование, что увеличивает время на задачу. И любая мера по ускорению получения фидбэка по поводу кода разработчика, кажется ускоряет процесс в целом.
B
Всем привет, у меня скорее менеджерский вопрос.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
Можно внедрять типизацию и новый стек по кускам. Эффект второй системы никто не отменял
B
И тем более не очень понятно как вы целиком хотите рефакторить весь легаси без автотестов. Начать стоит именно с тестов, хотя бы на свежий код
IK
Всем привет, у меня скорее менеджерский вопрос.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
Вопросы:
1. Как объяснить менеджеру, что нужно переписать все приложение на современный стэк технологий?
2. Возможно ли как измерить ценность от смены фреймворка для конечного пользователя продукта?
3. Возможно, вы знаете какие-нибудь статьи о том, как принимать решения о миграции с менеджерской точки зрения? Я нахожу в интернете только материалы про технические преимущества в миграции на тот или иной стэк технологий.
Контекст:
Работаю фронтендщиком в продукте, по скраму, в команде с еще не сформированными процессами.
Фронтенд в этом продукте - это легаси SPA, написанный не текущей командой разработчиков, и у него есть некоторые проблемы:
1. Он написан на JQuery, со всеми вытекающими
2. При проектировании проекта не предвидели объема функционала, который необходим сейчас
3. Торопились, когда писали, в связи с чем применили не самые хорошие архитектурные подходы.
Из-за этих проблем наша команда сейчас испытывает следующие боли:
1. Для создания простого компонента необходимо большое количество boilerplate кода
2. Приходится поддерживать постоянно ломающиеся кастомные решения типичных фронтедерских задач.
3. Задачи выполняются долго, а когда выполнятся оставляют большой хвост из багов, которые никто не отловил.
Командой разработки пришли к выводу, что это симптомы того, что нужен рефакторинг и миграции на современный стэк технологий.
Проблема возникла в коммуникации с Product Owner, он не против миграции, но его в первую очередь интересует ценность, которую получит пользователь конечного продукта. И просит привести КАКИЕ-НИБУДЬ статистические показатели, по которым он сможет принять решение:
1. Стоит ли это делать?
2. Когда это нужно делать?
Очевидные ответы в духе:
1. Меньше кода нужно написать => Быстрее делается задача => Увеличивается Time To Market
2. Внедрение типизации => меньше багов на продакшене
Были отвергнуты как слишком не конкретные.
Развернутый ответ.
Начну с контекста (мало ли, вдруг кто-то из читающих не в теме что за хрен с горы отвечает)
У меня была 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 денег потраченные в один спринт.