EG
Не скажу, что это охренеть как эргономично, но лучше, чем поднимать полноценный шедулер, да.
Size: a a a
2020 January 06
AZ
Mongo такой финт ушами не так давно делала, например.
тогда остаешься на старой версии и если она тебя не устраивает понемногу ищешь альтернативы.
Все еще лучше, чем делать альтернативу с самого начала
Все еще лучше, чем делать альтернативу с самого начала
EG
тогда остаешься на старой версии и если она тебя не устраивает понемногу ищешь альтернативы.
Все еще лучше, чем делать альтернативу с самого начала
Все еще лучше, чем делать альтернативу с самого начала
Нет, не лучше. Мигрировать огромную кодовую базу сложнее, чем потихоньку растить маленькую.
EG
Мы в Я. через это очень болезненно для Mongo проходили.
AZ
Нет, не лучше. Мигрировать огромную кодовую базу сложнее, чем потихоньку растить маленькую.
Ты в худшем случае остаешься в том же состоянии
AZ
короче это как преждевременная оптимизация
AZ
только преждевременное избавление от зависимостей
EG
Ты в худшем случае остаешься в том же состоянии
Нет, в худшем случае в старой версии найдут баг / уязвимость / она перестанет быть с чем-то совместимой, и тебе всё равно придётся всё мигрировать, только быстро.
AZ
Нет, в худшем случае в старой версии найдут баг / уязвимость / она перестанет быть с чем-то совместимой, и тебе всё равно придётся всё мигрировать, только быстро.
а так ты выйдешь на рынок на 3 месяца позже
AZ
лучше 3 месяца быть дырявым чем релизиться на 3 месяца позже
DF
Кстати да
EG
лучше 3 месяца быть дырявым чем релизиться на 3 месяца позже
s/3 месяца/год+/
Мигрировать большую кодовую базу сложнее, чем маленькую.
Мигрировать большую кодовую базу сложнее, чем маленькую.
AZ
s/3 месяца/год+/
Мигрировать большую кодовую базу сложнее, чем маленькую.
Мигрировать большую кодовую базу сложнее, чем маленькую.
у тебя _тот же объем работ_
AZ
какой год блин
AZ
либо ты сначала пишешь свое токио а потом пишешь на нем код
AZ
или сначала пишешь код, а потом пишешь (возможно) свое токио
AZ
"свое токио" в обоих случаях писать одинаково
EG
Нет, конечно.
В моём варианте:
1. Ты тратишь N времени на разработку своей библиотеки.
2. Ты тратишь M времени на разработку своего кода.
В твоём:
1. Ты тратишь M времени на разработку своего кода.
2. Ты тратишь N времени на разработку своей библиотеки.
3. Ты тратишь ещё R времени на миграцию своего кода на новую библиотеку.
В моём варианте:
1. Ты тратишь N времени на разработку своей библиотеки.
2. Ты тратишь M времени на разработку своего кода.
В твоём:
1. Ты тратишь M времени на разработку своего кода.
2. Ты тратишь N времени на разработку своей библиотеки.
3. Ты тратишь ещё R времени на миграцию своего кода на новую библиотеку.
AZ
Нет, конечно.
В моём варианте:
1. Ты тратишь N времени на разработку своей библиотеки.
2. Ты тратишь M времени на разработку своего кода.
В твоём:
1. Ты тратишь M времени на разработку своего кода.
2. Ты тратишь N времени на разработку своей библиотеки.
3. Ты тратишь ещё R времени на миграцию своего кода на новую библиотеку.
В моём варианте:
1. Ты тратишь N времени на разработку своей библиотеки.
2. Ты тратишь M времени на разработку своего кода.
В твоём:
1. Ты тратишь M времени на разработку своего кода.
2. Ты тратишь N времени на разработку своей библиотеки.
3. Ты тратишь ещё R времени на миграцию своего кода на новую библиотеку.
эмм, нет. Просто на шаге 2 ты делаешь такое же апи как было у той библиотеки
AZ
и ничего не мигрируешь